December 2003 - cypherpunks-legacy

Re: PGP 2.5 / PGP 2.6
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

>On Wed, 18 May 1994, Dave Otto wrote: > >MIT's press release on 2.6 also mentions bugs in 2.5 that have been >pointed out to them. I'm all for liberating 2.5 from MIT but we need to >fix the bugs in it that they fixed in (or are fixing in) 2.6. If this is done successfully, it might be a good idea to name it PGP 2.7 for obvious reasons.

1 0

FW: James Fallows on Clipper
by Blanc Weber 17 Dec '03

17 Dec '03

See The Atlantic Monthly June 1994 "Open Secrets"

1 0

Re: quantum Computing
by peb＠netcom.com 17 Dec '03

17 Dec '03

Seth Lloyd has an interesting paper, "A Potentially Realizable Quantum Computer", available at ftp.santafe.edu (I don't know the exact path). It is based on a cellular automata material that receives pulsed/phased array strobing light. It uses reversible logic so it dissipates little energy. As I understand the proposal assumes future materials and manufacturing abilities, although Lloyd says that quantum dots may be the right direction. As gtoal mentions, the P vs. NP question is speculative. My intuition is that the many worlds hypothesis will not be a holy grail of computation (because similar theories about faster than light communcation ended up not being useable due to very low level conservation rules). Then again, we may be surprised. Paul E. Baclace peb(a)netcom.com

1 0

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

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

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 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