December 2003 - cypherpunks-legacy

Re: NSA Cheif Counsel in Wired (Rebuttal) (fwd)
by Stanton McCandlish 17 Dec '03

17 Dec '03

Forwarded message: Subject: Re: NSA Cheif Counsel in Wired (Rebuttal) Date: Thu, 12 May 1994 14:26:52 -0700 (PDT) From: Jeff Davis <eagle(a)deeptht.armory.com> To: eff-activists(a)eff.org (eff-activists mailing list) -----BEGIN PGP SIGNED MESSAGE----- A little further along in the AP story on the record level of Clinton Administration wire taps, Micheal J. Sniffen states: In a section on surveillances completed in 1993, the report said the longest and most expensive federal eavesdropping was accomplished by a microphone placed inside a New Jersey lawyer's office in a racketeering case. The microphone actually operated 435 days, overhearing a total of 65 people, at a cost of $517,673. ...The government said in court, "the purpose of utilizing the law offices ... was to evade electronic surveillance by fraudulently creating the appearance that these were legally proper meetings." This microphone recorded conversations in the office, not the telephone. As I stated to Dr. Dorthy Denning of Georgetown University, escrowed encryption is unnecessary for surveillance. In addition to "bugs", intellegence agencies also provide long range listening technology to the enforcement agencies like the FBI and DEA. Organized criminals don't use the phone to discuss business, it can be tapped. This sort of blows a hole in Stuart Baker's arguments for escrowed encryption being necessary in law enforcement. The next time he offends someone with his tired trig joke, I would hope that he is ask to rebut this. As well as to estimate how many conversations and participants are actually involved in the given figure of 333 1993 "wiretaps." Long range listening was found to fall under federal "wiretap" rules in the Smalldone case in Denver during the summer of 1982. Try to FOIA that info. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLdKerV/ScHuGXWgVAQFziAQAuYTNTKjaqTWaOO3C42yKCWLM7+kU1gXp 4sGxHGQKfsDP333zLNA+ETGuVfs6si5YQVbsnlGVdS/v36oZp8bUj/8MgWYKLj66 1jRNf4mPl0Mb5LL7InrUwjKCqmOb/GLuHK7F0cHzZbsBE2FkmIqi27AcgJ/8nMxl lFiBbzWrBk4= =I+yV -----END PGP SIGNATURE----- -- PGP PUBLIC KEY via finger! JAFEFFM Speaking & Thinking For Myself! * eagle(a)deeptht.armory.com email info(a)eff.org * *** O U T L A W S On The E L E C T R O N I C F R O N T I E R **** ***** Committed to Free Public Internet Access for World Peace ***** -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 14 1994

1 0

Yet Another T-Shirt Proposal
by perry＠imsi.com 17 Dec '03

17 Dec '03

Should I ever run in to Stewart A. Baker, I want to be wearing a T-Shirt that says "I oppose Clipper because I'm a bitter guy who couldn't go to Woodstock". (Actually, something pithier would be nice, but you get the idea. Maybe "Mad at the NSA for making me do my Trig Homework"?) Perry

2 1

Re: Cypherpunks Goals: Bad debate drives out good debate
by Mike Markley 17 Dec '03

17 Dec '03

| | How about auto-moderation? I came up with this idea a while back for | automatically moderating mailing lists. Here's how it works: | | A newsgroup is set up as moderated, and the posts are emailed to the | moderator (as usual). The "moderator" is a mail-to-news gateway that | posts the articles if the author isn't on the disapproved list, and | also automatically cancels articles that don't have the right "approved" | header and aren't digitally signed by the moderator. | | If a person becomes a nuisance, people send their votes in to the | moderator-robot, and it tallies the votes. If within XXX days more thumbs | down votes are received than thumbs up votes, the person is placed on the | disapproved list. | | The main advantage is, it's fast and easy to set up. Comments? Sounds like a very easy scheme to break. Say I suddenly decide that I don't like your posts or Tim Mays posts. I can get you kicked off by using anonymous accounts to say that you're a nuisance. It seems to me that leaving the list open is better than trying to control it. An example of the danger of automation has already been shown on this list. Last week someone unsubscribed everybody using the automatic features of the remailer. I'd rather have access to all of the posts and make my own decisions about the contents rather than have a potential for one aggrevated individual take out some meaningful content because of a personal vendetta. Mike | | Ed Carp, N7EKG/VE3 ecarp(a)netcom.com 519/824-3307 | Finger ecarp(a)netcom.com for PGP 2.3a public key an88744(a)anon.penet.fi | If you want magic, let go of your armor. Magic is so much stronger than | steel! -- Richard Bach, "The Bridge Across Forever" | | ===================================================== Mike Markley <mmarkley(a)microsoft.com> I'm not a Microsoft spokesperson. All opinions expressed here are mine. ===================================================== |

3 2

Re: So PGP2.5 is becoming clearing...
by lefty＠apple.com 17 Dec '03

17 Dec '03

>> Given that to my knowledge no court, federal official, or other >> organization that counts recognises "freeman status" to my knowledge, >> it would seem to be a very small loss. > >What they certainly _do_ recognize, however, is that a person who _does_ >agree to the PGP 2.5 terms has affirmed that he _is_ a national person. >This could be used by a court to negate any subsequent denial by the >person that he is a subject of the United States of America or Canada. >The absence on one's record of such affirmations is a prerequisite for >freeman status. Given that this "freeman status" seems to exist only in your fevered imagination, who's to say what might or might not be a prerequisite for it? I'm finding this whole thread extremely silly. Are you actually attempting to suggest that if someone not currently a US citizen were to use PGP 2.5 he would somehow become a "subject" (whatever _that_ is) of the United States? This would undoubtedly come as exciting news to Haitian boat people and Chinese nationals jammed into the cargo holds of trawlers in San Francisco Bay. What, I wonder, do I have to do to qualify for "moonman status"? -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

dos app STACKER, passwd?
by steve willey 17 Dec '03

17 Dec '03

does anyone know how password protection for the dos compression utility stacker works? and more importantly how it can be cracked. i will pay 5 Ghost Marks for USEFUL info. thanks, steve

1 0

PGP 2.6 announcement
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

Does anyone have a copy of the announcement stating the PGP 2.6 would not accept message from previous versions of PGP after September 1, 1994? If so please send it to me. Thanks, Reuben Halper

1 0

Re: Caller ID info...
by fnerd＠smds.com 17 Dec '03

17 Dec '03

In this report... > Report and Order And Notice of Proposed Rulemaking of > March 29th, 1994 (CC Docket No. 91-281) ...FCC apparently decides that per-line blocking should be prohibited since people might forget to unblock it when calling 911. John Levine says, > In other words, per-line blocking is a bad idea because subscribers > are too dumb to unblock calls when they want to unblock them, although > they're not [too] dumb to block calls when they want to block them. To me the question is, why can't the phone company provide options for blocking-on-all-but-911-calls, and unlisted-except-for-911? More precisely, why can't the FCC allow for this simple possibility? The reasoning seems to be, "since we can't understand why people want this, we must prohibit its even being an option:" > > ...For the > > foregoing reasons, we find that a federal per line blocking > > requirement for interstate CPN based services, including caller > > ID, is not the best policy choice of those available to recognize > > the privacy interests of callers. Thus, carriers may not offer > > per line blocking as a privacy protection mechanism on interstate > > calls. "...We find" it "is not the best... thus, carriers may not offer" it. What about what the customers and consumer groups have found and fought for? What is wrong with letting this be decided on a regional, if not provider, if not local, if not personal level? Why must FCC impose least- common-denominator reduction of services? > > ...with comments due by May 18th. That's today. I'm faxing this ill-prepared complaint to 202-632-6975. > > Comments must reference the docket number (CC Docket No. 91-281). > > Send ten copies (yes, 10) to: > > > > Office of the Secretary > > Federal Communications Commission > > Washington DC 20554 -fnerd quote me - - - - - - - - - - - - - - - and i dreamed i was flying high up above my eyes could clearly see the statue of liberty sailing away to sea --Paul Simon -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

2 1

Re: Caller ID info...
by peb＠netcom.com 17 Dec '03

17 Dec '03

Strange reasoning. Why not use the "*70" style code that turns it off for one call, just as *70 disables call waiting for modem use? Paul E. Baclace peb(a)netcom.com

1 0

RESEND: PGP 2.5 mini-review
by schirado＠lab.cc.wmich.edu 17 Dec '03

17 Dec '03

[I sent this out before I learned of the Great List Crash, so I'm resending it now.] Having not seen any activity on the list for the last week or so (I hope everyone's busy writing code!), I figured I'd simultaneously check to see if the list still existed, and share some interesting excerpts from NEWFOR25.DOC, from the PGP 2.5 MIT-legit package. PGP 2.5 is apparently still written by Phil Zimmermann - at least, it purports to be - which in itself is a considerable relief to those of us who had no idea who was responsible. The source code is also available, as before, and I'm sure programmers the world over are even now poring through it in minute detail, looking for backdoors and such. I also expect we'll be hearing from them relatively soon, to tell us of the presence or absence of any suspicious code. Not being a programmer myself, I can only comment on a few aspects. First, there is this: [...] >[An] RSAREF limitation is that it cannot cope with keys longer than >1024 bits. PGP now prints a reasonably polite error message in such a >case. I recall someone mentioning at one point that increasing the size of a key beyond 1024 bits did not justify the increased computing time, but I do not recall the reason why. I believe the reasoning was not that it offered no additional security, but rather, that it was already difficult enough to crack 1K keys, and if you're really that worried about security, you should be tightening up in other areas, such as deciding who to trust and who not to, deciding what information to enter into the computer and what to keep in your head, or maybe making a homemade TEMPEST shield. :) I'd still like to see the math explained a little better, though. Also, has anyone found those references to elliptic-curve crypto? The original article is _An Implementation of Elliptic Curve Cryptosystems Over F-2-155_ , IEEE Journal on Selected Areas in Communications, Vol. 11, #5, June 1993 (page 804). (Schneier mentions that Next Computer's Fast Elliptic Encryption, FEE, uses elliptic curves, and is patented by R E Crandell, USP# 5,159,632,27 October 1992.) Also, look for works by Neal Koblitz. >Printed keyIDs have been incresed to 32 bits, as there were enough keys >out there that 24-bit keyIDs were no longer sufficiently unique. The >previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID. >For example, what was printed as A966DD now appears as C7A966DD. So even though the keyservers only have 5,000 or so registered users, there are enough people out there using PGP and NOT registering their keys with the servers that this extra bit of coding was necessary? Hmm. 24 bits gives us 16,777,216 unique ID's. 32 bits gives us 4,294,967,296. Are there really over 17 million PGP'ers out there, or is my math-impaired brain missing something painfully obvious? >PGP now enables clearsig by default. If you sign and ascii-armor a >text file, and do not encrypt it, it is clearsigned unless you ask >for this not to be done. Which would seem to indicate that PGP is mainly being used for e-mail! Goody! >[...] > >PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random >data in an attempt to force disk compressors to overwrite as much data as >possible. > >[...] > >The normal help files (pgp -h) are pgp.hlp or <language>.hlp, such as >fr.hlp. Now, there is a separate help file for pgp -k, called pgpkey.hlp, >or <language>key.hlp. No file is provided by default; PGP will use >its one-page internal help by default, but you can create such a file >at your site. > >PGP used to get confused if you had a keyring containing signatures from >you, but not your public key. (PGP can't use the signatures in this case. >Only signatures from keys in the keyring are counted.) PGP still can't use >the signatures, but prints better warning messages. Also, adding a key on >your secret key ring to your public keyring now asks if the key should be >considered ultimately-trusted. Prviously, you had to run pgp -ke to force >this check, which was non-obvious. > >[...] > >On Unix, PGP now figures out the resolution of the system clock at run >time for the purpose of computing the amount of entropy in keystroke >timings. This means that on many Unix machines, less typing should be >required to generate keys. (SunOS and Linux especially.) > >The small prime table used in generating keys has been enlarged, which >should speed up key generation somewhat. > >There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!) >when generating primes 2 bits over a multiple of the unit size (16 bits >on PC's, 32 bits on most larger computers), if the processor doesn't deal >with expressions like "1<<32" by producing a result of 1. In practice, >that corresponds to a key size of 64*x+4 bits. > >Code changes: > >At the request of Windows programmers, the PSTR() macro used to translate >string has been renamed to LANG(). > >The random-number code has been *thoroughly* cleaned up. So has the >IDEA code and the MD5 code. The MD5 code was developed from scratch and >is available for public use. So, all in all, PGP 2.5 would seem to be more than just a possible conspiracy by MIT/RSA/et. al., and more than just minor bug fixes that most people wouldn't care about. With the possible exceptions of the size limitations on keys, and whatever arcane pieces have been hacked out of the RSA code to comply with whatever demands they may have made, PGP 2.5 appears to be a legitimate upgrade, with more than a few bugfixes, both major and minor, as well as the all-important improved security (as far as can be seen). Comments? ** schirado(a)lab.cc.wmich.edu [O|o]bjectivist, Evil Capitalist(tm;-), s..O).... You hit the smurf! --More-- male, lesbian, polyamorous, @.../.".. You destroy the smurf! --More-- reader, atheist, Discordian, $$*...].. You feel cynical! free and natural sovereign individual the Frog Farm: e-mail frog-farm-request(a)blizzard.lcs.mit.edu (PGP available)

1 0

RE: Cryptosystems Journal
by Pat Farrell 17 Dec '03

17 Dec '03

> Does anyone know where one can read back issues > of CryptoSystems Journal? I was looking for > Volume 2 Number 2. I tried at several Univeristies > but they said only the Library of congress had it. Tony Patti is the publisher of Cryptosystems Journal. He is _not_ on the net, his old portal account has been closed. He is working hard on Volume 3. You can reach Tony via snail mail to: Tony Patti Editor, Cryptosystems Journal PO BOX 188 Newtown PA 18940-0188 USA Tony has been publishing the Journal for a while, complete with floppies. I know he has non-US subscribers. I wonder how he exports it. I have a copy of Volume 2 Number 1, and Volume 2 Number 2. But you'd have to be in the DC area to see it. If we get a DC-area meeting working in May, I can bring it for folks to look at. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0