December 2003 - cypherpunks-legacy

ZiffWire article on PGP 2.6 (fwd)
by Michael Johnson 17 Dec '03

17 Dec '03

I asked Philip Zimmermann what he thought of the ZiffWire article on PGP, and this is what he said: ---------- Forwarded message ---------- Date: Thu, 7 Jul 1994 22:29:24 -0700 (MDT) From: Philip Zimmermann <prz(a)acm.org> To: Michael Johnson <mpj(a)csn.org> Subject: ZiffWire article on PGP 2.6 (fwd) Forwarded message: >From columbine!prz Thu Jul 7 20:58:25 1994 Date: Thu, 07 Jul 1994 20:55:20 -0700 (MDT) From: Philip Zimmermann <prz(a)acm.org> Subject: ZiffWire article on PGP 2.6 To: cypherpunks(a)toad.com (Cypherpunks) Cc: prz(a)pascal.acm.org Reply-To: Philip Zimmermann <prz(a)pascal.acm.org> Message-Id: <m0qM65x-0002vqC(a)maalox.ppgs.com> X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Transfer-Encoding: 7BIT Content-Length: 2943 I would like to correct a misleading assertion that appeared in an article dated 5 July, attributed to "PC Week via INDIVIDUAL, Inc" that came from ZiffWire. The apparent author of the article is Eamonn Sullivan. I think it was posted on the Cypherpunks mailing list. The article concerns Pretty Good Privacy, version 2.6, distributed by MIT. The misleading and damaging paragraphs follow: > MIT and RSA's distribution of PGP Version 2.6 is an attempt to short- >circuit PGP's popularity. After Sept. 1, 1994, PGP 2.6 will no longer work >with documents and keys generated and encrypted by older versions of PGP, >and it is licensed for use only in the United States. > > The release is already causing upheaval, since its public-key format is >different than in prior versions, and numerous public-key repositories will >have to be updated. > >[07-05-94 at 17:19 EDT, Copyright 1994, ZiffWire, File: c0705185.2zf] This assertion is erroneous and damaging to PGP's reputation. PGP 2.6 will always be able to read messages, signatures, and keys from older versions, even after September 1st. The older versions will not be able to read messages, signatures and keys produced by PGP 2.6 after September 1st. This is an entirely different situation. There is every reason for people to switch to PGP 2.6, because it will be able to handle both data formats, while the older versions will not. Until September, the new PGP will continue to produce the old format that can be read by older versions, but will start producing the new format after that date. This delay allows time for everyone to obtain the new version of PGP, so that they will not be affected by the change. Key servers will still be able to carry the keys made in the old format, because PGP 2.6 will still read them with no problems. The assertion made in the article has it backwards, which would indeed be bad if PGP were to start behaving that way. If it did, I wouldn't use it myself. I call upon ZiffWire and PC Week to issue a correction to this error. Also, note that any export restrictions on PGP 2.6 are imposed by the US government. This does not imply that MIT or myself agree with these restrictions. We just comply with them. We do not impose additional licensing restrictions of our own on the use of PGP outside of the US, other than those restrictions that already apply inside the US. PGP may be subject to export controls. Anyone wishing to export it should first consult the State Department's Office of Defense Trade Controls. I developed PGP 2.6 to be released by MIT, and I think this new arrangement is a breakthrough in the legal status of PGP, of benefit to all PGP users. I urge all PGP users to switch to PGP 2.6, and abandon earlier versions. The widespread replacement of the old versions with this new version of PGP fits in with future plans for the creation of a PGP standard. Philip Zimmermann

1 0

Re: (fwd) Re: BSD random() - any good (source included)?
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

From: Jim choate <ravage(a)bga.com> Subject: (fwd) Re: BSD random() - any good (source included)? Jeezus fucking christ, you're just doing this to wind me up, aren't you? Any more of these turn up in my mailbox and they get bounced straight back to you. I have to pay by the minute for this connection. Keep it up and you'll pay too, believe me. G

2 1

Re: Question: Key Distr. in realtimeo applications?
by kentborg＠world.std.com 17 Dec '03

17 Dec '03

There are two ways around the problem of a faked public key. 1) spread it widely enough that it is hard to fake the several lookups you might do before first using it (you gonna doctor every cypherpunk posting I see which includes a key? gotta have a good middle to not get caught sitting there) 2) have a single well known key sign a copy of the key you want to be accepted as legit--and if that is too busy a task for the very important single key holder, just sign a few keys (one for Oberlin, for example) and have *them* sign further keys (including a copy of their signed credentials). This signing of credentials can be extended indefinitely. (Apple uses this scheme with RSA coding in their forthcoming mail support for the Mac--or at least did, I have not played with the recent betas.) And these two approaches work together. If my keyring has dozens of keys from the same organization, all signed with the same organization key, it becomes very difficult to get me to accept a fake. (Assuming there is software support for easily doing this kind of checking, something I don't think is in PGP, etc.) Encryption of voice: same problems as other key authorization situations, but often easier. If I call my mother, I don't care what key she uses, I will recognize her voice, how she speaks, and what she appears to know--things that are not yet fakeable except by very good actors with lots of time to study their roles. One-time key, how to distribute to both participants: don't. Let each pick a random key and sent it to the other using the other's public key--no need to use the same key in both directions, in fact seems a bad idea. -kb, the Kent -- Kent Borg +1 (617) 776-6899 kentborg(a)world.std.com kentborg(a)aol.com Proud to claim 31:15 hours of TV viewing so far in 1994!

2 1

C-punks in print...
by Jim choate 17 Dec '03

17 Dec '03

Hi all, For those interested there is an article in the July 94 issue of Circuit Cellar Ink: The Computer Applications Journal on pp. 36. It specificaly mentions the c-punks and their position (ala Gilmore) on various issues of crypto and constitutional rights. Is a good article but shallow on technical details. It is intended more as a pump primer for those poor souls doing real-time control apps. I would say it is worth the time to read. Take care.

1 0

Announcement: PGS v0.99c
by ER CRAMER 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- PGS v0.99c is out there! This new version of PGS supports 8 bytes keyid's. This version will be able to run in a OS/2 DOS box. PGS v0.99c is available on the following site: wuarchive.wustl.edu:/pub/msdos_uploads/pgs/pgs099c.zip I hope that at the end of next week PGS v0.99c will be available at SimTel too... (oak.oakland.com:/SimTel/security/pgs099c.zip) Do not throw away 0.99b yet because we did the bugfix a bit fast because we want to have it ready before the hollidays... - -- ... If you outlaw Privacy, only Outlaws will have Privacy! Eelco Cramer <crame001(a)hio.tem.nhl.nl> ------ - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLh1SOYDAdPKe9hHLAQFkXAP/UTodjE7HqCGVZAazLAxdYrWcrVgMsYBa kPjn2litqpxZWusMjqTIS3+vHYHrEhXCzBexl69CEo1XQ46PNe1kbrbpwPxGCwzc uCryNVeZ+sOdpJOTAWmPmEYM151X2w7KEjI7vPMmgShQGjQlOBWR0PvQ3VOEd61U mUP6FCfW5HQ= =aEkc -----END PGP SIGNATURE-----

1 0

RE: "Cypherpunk" vs. "Cryptorebel"
by lefty＠apple.com 17 Dec '03

17 Dec '03

>On Wed, 6 Jul 1994, Lefty wrote: > >> >I like the label "cryptorebel" better than "cypherpunk". The word >> >"punk" just does not seem right, while "rebel" does. I do have a >> >certain attachment to "cypherpunk". Comments? >> >> If it weren't for nitpickers, we'd all be knee-deep in nits. > > There is too much "name recognition" in "cypherpunk" for it to be dropped >now...IMHO. A more serious problem with the name "cryptorebel", which did not immediately occur to me, is that crypto-whatever generally means "someone who denies being a 'whatever' but, in fact, is one". In the words of Inigo Montoya, "You keep using that word, but I don't think it means what _you_ think it does". -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

1 0

Curve Encrypt 1.1 Release
by W. Kinney 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Curve Encrypt 1.1, IDEA encryption for the Macintosh is now available. Curve Encrypt is a freeware drag-and-drop encryption application for the Macintosh. It uses IDEA cipher-feedback mode with a 255 character pass phrase, encrypts both the data and resource forks of files, and will encrypt the contents of a folder or volume in a single operation. Source code is provided, natch. CE is System 7 only. (Note that this program has nothing whatsoever to do with elliptic curve encryption methods, just so nobody gets confused...) NEW FOR 1.1 The following changes have been made for the 1.1 release: o Faster encryption and decryption. o Faster file wipes. o Department of Defense standard file wiping is now an option. o The "Use as default pass phrase" selection is no longer present. Instead, Curve Encrypt 1.1 uses keyfiles, a more reliable way to reuse pass phrases. oJCurve Encrypt now saves the creation and modification dates of files when they're encrypted, and restores them to their original values when a file is decrypted. o An incompatibility with the Super Boomerang utility has been fixed. Ftp Sites: ripem.msu.edu:pub/crypt/other/curve-encrypt-idea-for-mac/ This is an export controlled ftp site: read pub/crypt/GETTING_ACCESS for information. ftp.csn.org:/mpj/I_will_not_export/crypto_???????/curve_encrypt/ csn.org is also export-controlled: read /mpj/README for the characters to replace ???????. Address for support: Curve Software <kinney(a)bogart.colorado.edu> Copyright and Distribution: Curve Encrypt (c)1994 Curve Software. Permission is granted for distribution within the United States only, including products containing Curve Software copyrighted source. Export of this software is a Federal crime. Don't do it. Curve Encrypt is free. All releases are verified with PGP signatures. Public key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCPAiz+bEEAAAEEAMUbtdwYC1vY+s5559ERIvC1MT+Yaw3ozheaHcUciJe7cSAk k9TpAQd7iKukKnQe5kK1YtvYm0JP6fmNrcO8AmG5ukvcOlyuri618sjpXncpQ1cL 5xeV80f3JtmheGMnqAzTK8OyfJ7zRh1PhAZcT/vVzf+JGuCuVcJkEfxTVMrJABEB AAG0K0N1cnZlIFNvZnR3YXJlIDxraW5uZXlAYm9nYXJ0LmNvbG9yYWRvLmVkdT6J AJUCBRAuDZ3RwmQR/FNUyskBAd4wA/90tc6Fp0T3kSrmz0Vsbn+M7eND3fNp/XVy CW4xM6xzQK3ooRAjWBbnZbixTyhzlK33X2+EQGGYB5jWA5A+hgGOk3xYhApgBn+K rivF0xKJxNhR4CnsummIyXLn7UPXl0HrPvKszvSCVDhtky2Sy6jNKQcmN7vkFfY+ aAe8ox8944kAlQIFEC4CAaNLsloC2TxExQEBq2gD/2KeXbfrOC3i6FsTNNrODRI1 7i23XTMiquBWmRNheVIQV1dbNKB7DWawUNaykSZiGCEooW+HRKSv3iEGvQiBu1v1 1JB/7Id10a+bIpzCzzfGQ+RvbCCTt9+gACv3JpuXtBmcvIoHKAUpbuQhUd/vR17x 6U9tNhyEa4fdefHgmUsjiQCVAgUQLQSyUSA78To+806NAQECxQP/X5rfktz8h3Je DqX0c9IhobWL36vYGVvzqr8ViYkARMYI7Q4cKupHgDunO+Q+zKiSSsSFBlzlPe4f dg5hJ+eDOUircFRgz5Bu/CN1jAwPdElAHc4W12yiirTvq4HggR7j37aCPz1xsUmg zbKbiM6FI6SKTWK0faOoXoCCbGzA4v0= =IGUN - -----END PGP PUBLIC KEY BLOCK----- This key is also available from the key servers. Curve Software <kinney(a)bogart.colorado.edu> Cypherpunks write code! -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLhsNVMJkEfxTVMrJAQEFfgP+K7NRta8HUqhlegb1d0r9K/DD2mHqy7tv vKF50VVZordlKxLDryv7O5kpXIQK9iGKSZIyu42WL/L25qNJw5DpmSruNPk80ChK n1vOwzJLSXg4qOmPcVU9ejbxzrUy+j7FUOWC3+mBeOBB/oHYBiAISx3o+UHlLDYC 52leB7ozW8U= =B0E/ -----END PGP SIGNATURE-----

1 0

Re:
by lefty＠apple.com 17 Dec '03

17 Dec '03

>On Wed, 6 Jul 1994, Mike Markley wrote: >> can't be broken in a reasonable amount of time. I'm interested in what >> most of the people on this list would consider a reasonable amount of >> time though. > >NEVER is what I consider a reasonable amount of time. >I don't want my secure thoughts broken for public display >in my lifetime. Or any of my children's lifetime. Or there >children's lifetime. .......... You had better not have any "secure thoughts" then. "Forever" is enough time to break _any_ cipher. -- Lefty (lefty(a)apple.com) C:.M:.C:., D:.O:.D:.

2 1

Re: Question: Key Distr. in realtimeo applications?
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: Ideally, you want to pick up your crypto-phone, initiate a call to : another crypto-phone which you've never called before, and which was : possibly manufactured yesterday, and be able to exchange keys with it : in a secure fashion. But I can't think of any way to do this, without : opening yourself up to a man in the middle attack. The physical key exchange can be done by Diffie-Helman, but as you note it can be man-in-the-middled. I think what the STU sets do is to print the other guy's keyprint that was actually used on an LCD on the phone, and you read it back out to each other in voice mode. Of course, that can be m-i-t-m'd too but it's a damn sight harder... G

1 0

Re: (fwd) Re: BSD random() - any good (source included)
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 3:05 PM 07/08/94 -0500, Jim choate wrote: >Yes, I could do that if I were so inclined. I am not. Seems to me that just >Bottem line is that at this point there is no clear cut 'standard' that I >biggest problems w/ the list at this point is the range of expertise that >piss somebody off. The real question is whether it is worth the time to >reply to them (in general I hold it isn't) rather than just hitting 'd' >The bottem line is it was crypto related, was in reference to source code, Seeing how he is so fit for the job, and knows not only what we all need to see, but also what the bottem line is, I hereby nominate Jim for CypherGod, and urge him to, as his first action in that role, to pipe all of usenet through cypherpunks, because you Just Never Know when you might miss something that is crypto related, and after all, if you want to be crypto-savvy, you have to pay a little. -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel(a)sybase.com>

1 0