December 2003 - cypherpunks-legacy

gnutar + pgp filter mode
by William Hayward 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The gnu tar archiver allows to use an arbitrary compression program (option --use-compress-program=PROG). This works well with pgp if a small wrapper is used: #!/bin/csh -fb if ("$1" == "-d") then exec pgp -d -f else exec pgp -e -f endif The only problem is that this doesn't work well for larger amounts of data, because pgp reads in all data before starting with its work. Perhaps a future release of pgp will have a real filter mode. Hadmut BTW: Does this "crypto-hook" cause export restrictions to apply on gtar ? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMV/0tmc1jG5vDiNxAQFtAAP/TMuYeYf5q7k1Y8DrBjb6XFKYYFANH3RH FvThWq1BUgI+unH97EZkNkCzZJYT5qmLGk3+JLufCAw/o9YR7jKcldm2LNYJ96t2 BDcSGDF3qx/IUzQBa5NV+gUerNRVSwA3LzkTbXufOxYH0cB3KNcsx3B0bE1rEDa/ GCcJ1L6T+2s= =FMiZ -----END PGP SIGNATURE-----

1 0

"Dead beef" attack against PGP's key management
by Raph Levien 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This post is signed by a forged key for Phil Zimmermann. I forged the key this morning. The key has the same user id and visible key id as an old key for Phil Zimmermann, which he has since revoked. I should stress that this attack does not in any way weaken the security of PGP's message formats. However, it does expose a problem in the user interface of its key management. Namely, it is fairly easy to forge a key that looks very similar to an existing key. In fact, the only way to distinguish between real and forged keys in general is by the fingerprint and keysize together. My purpose in posting this is to demonstrate that such forgeries are possible. The lesson is: please do not use the key id alone to identify keys. Another reason for the public posting of this forgery is to goad the PGP development team into improving the user interface in PGP 3.0, so as to make the detection of such a forgery much easier, if not routine. Derek Atkins has assured me that PGP 3.0 will include a cryptographic hash of the key, for use as a key id. If implemented properly, such a facility would address this attack. I am not the first to propose this attack. According to Derek Atkins, Paul Leyland first proposed the attack two years ago. Also, Greg Rose successfully mounted a similar attack six months ago, creating a key with user id 0xDEADBEEF, thereby giving rise to the name. The pseudocode for the attack is as follows: choose random 512 bit prime p choose random 480 odd x q = x * ((0xdeadbeef * (p * x) ^ -1) mod 2^32) do {q += 2^32} while q composite The above bit of pseudocode replaces the original selection of p and q, which are normally just random 512 bit primes. Without having done detailed analysis, I believe that the resulting forged keys are just as good as ordinary PGP keys. Further, the modified key generation is almost as fast as ordinary PGP key generation, and I think I could speed it up a bit more. The attack took me a few hours to design and code. Any good programmer familiar with PGP could duplicate it easily. One practical application of this attack is to implement a certain degree of "stealth." Since PGP includes the key id in encrypted messages, it is in most cases possible to identify the recipients of encrypted messages. However, if a lot of people generated keys with the same key id, then it would not be possible to tell from the encrypted message which one was the intended recipient. Here's the public key I forged, which can be used to check the signature of this message: Key for user ID: Philip R. Zimmermann <prz(a)acm.org> 1024-bit key, Key ID FF67F70B, created 1992/07/22 Also known as: Philip R. Zimmermann <prz(a)sage.cgd.ucar.edu> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAyptNMAAAAEEALRhS3ZCFKLPNF/fZeluh/rNfpgZ5a0ddTBtxJ+1yLIkVurb HWFFBsrmnA4hU4MhlA8DS/f2gnS0v3zyQ78JOY1SBIJrLdaIPIrh0ZTAZXWoQWDe Qknm1ZgyLkIRJlt5aDLp+iLJ5sc+LSO5N/DtrL+Htc5MF0AVAWtzPhz/Z/cLAAUR tCJQaGlsaXAgUi4gWmltbWVybWFubiA8cHJ6QGFjbS5vcmc+iQCVAwUQMWAremtz Phz/Z/cLAQE//AP/bg9gMOuiBYkFCiyarJ/DIARWDf7e4bWFJloXAyPeBXCITDIw tuHRJ41yFqnlLmdcuVhXQf/xrH248JyWpHqqED6eOU/PnBHo9IR6H0Fts+O3I+vk tOYRjuTJy+6JV0s/8VN/Sgh8y6Jm2FGhhzhCp6KHNcTHpUud6iGScaEs/CG0LFBo aWxpcCBSLiBaaW1tZXJtYW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+ =Z1mf - -----END PGP PUBLIC KEY BLOCK----- Raph Levien -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMWA2pGtzPhz/Z/cLAQELEQP/fam4tHS8TlMy7SFoUZvC0C4q0ID9Ze5W rY2D++df4UtAFDITGs4lQqzeq6YCqk51oT8gZAACK6D6UlFgr5roIbgwa74Fxso1 B5mquC9axlOlxZJI1PuK+NflBJqCokuQGtG95ER6vbm4n4RACW43In9SAatIvduN JfBSLYrAr14= =V5U6 -----END PGP SIGNATURE-----

1 0

Re: Electronic locksmiths are watching you (Belgium's ban onPGP)
by jim bell 17 Dec '03

17 Dec '03

At 02:56 PM 4/1/96 -0500, Black Unicorn wrote: > >Following my new policy on Jim Bell posts, the below represents my new >form of reply. These 'terse' replies should cut down on bandwidth and >still serve as some basic protection to the list readership as to the >mis and dis-information which eminates in quantity from Mr. Bell's >account. Those parties interested in a more detailed discussion, aside >of course Mr. Bell, should ask for clarification where they feel it >necessary and I will then expound on my points. What you _really_ ought to do is to cut down your responses to ZERO, especially on material that was not sent to you. Until you're willing to talk intelligently about what you believe, you're just wasting peoples' time. Jim Bell jimbell(a)pacifier.com

1 0

Re: "Random Sequence"
by rollo＠artvark.com 17 Dec '03

17 Dec '03

>At 07:25 AM 3/31/96 -0700, Rollo Silver wrote: >>The paper "On the Effective Definition of 'Random Sequence'", by Michael >>Levin, Marvin Minsky, and Roland Silver can be viewed (and downloaded, and >>printed) from my website <http://www.artvark.com/artvark>. > >Rollo, > > I read the paper and it's nice work -- but it departs from current >definitions of random sequences in that it assumes you specify the countable >set of machines trying to test for non-randomness first and then generate a >sequence to fool that set of machines. Current definitions of randomness >assume an infinite set of testing machines, often limited to polynomial time >and space, and a sequence generator that must defeat them all without >knowing anything about them. Such sequences are, in a sense, "more random" >than the ones your paper dealt with -- I believe. Did I miss something? * It's a bit anachronistic to say in 1996 that a paper written 30 years earlier "departs from current definitions of random sequences." The authors may have been brilliant, but they weren't prescient. <g> I can't imagine how a computer could be smart enough to defeat an infinite set of guessing machines without knowing ANYTHING about them. In fact, what's wrong with this argument: call the "fooling" machine Frank, and one of the "guessing" machine Gert. You say that Frank doesn't need to know anything about Gert. Let me suppose however that Gert DOES know about Frank. In that case, Gert can simulate Frank and "guess" his output, thus foiling Frank's attempts to fool Gert! Maybe it's the "polynomial time & space". That restricts the guesser-domain considerably, compared with our very weak requirement that the guessers can be any Turing machines whatever -- as long as the set of them is effectively calculable. BTW, is the set of ALL finite automata effectively calculable? I suspect maybe so. If so, by essentially the argument given in the paper, there is a computer (Turing machine) that can fool them ALL. I hope it's okay to cc this note to coderpunks. It's not about coding per se, but it may shed some light on what "randomness" means, and on "computable randomness", which sounds appropriate for coderpunks to me. ------------------------------------------------------------------------ Rollo Silver | The CDA means | Artvark / PO Box 219 505-586-0197 | lost jobs and | San Cristobal, NM 87564 USA rollo(a)artvark.com | dead teenagers | http://www.artvark.com/artvark/

1 0

Re: A MODEST PROPOSAL (fwd)
by Bill Stewart 17 Dec '03

17 Dec '03

This happens any time anybody signs up with an an######(a)anon.penet.fi address. Ideally, someone could, in their copious spare time, hack majordomo to automatically translate all subscription requests of that form to na######(a)anon.penet.fi ; as an alternative, if majordomo has some sort of subscription blocking list an*(a)anon.penet.fi belongs on it. At 07:35 PM 3/30/96 -0800, Sandy wrote: >has anyone had the sort of problem mentioned below? >From: E. ALLEN SMITH <EALLENSMITH(a)ocelot.Rutgers.EDU> >To: sandfort(a)crl.com >Subject: Re: A MODEST PROPOSAL >From: IN%"sandfort(a)crl.com" "Sandy Sandfort" 26-MAR-1996 16:57:18.92 >>Wilco. I'm collecting names for an addendum now. > Thanks. Incidentally, I recently had a problem with posting to >the cypherpunks list; it consisted of the message getting sent to anon.penet.fi >instead. This looks like someone trying to find out anon.penet.fi anon IDs; >however, it wouldn't work due to the password requirement. Have you heard >anything about this? #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 pager 408-787-1281 1995: Chat rooms, espresso, and Linux 1996: Exon, melatonin, and Java.

1 0

RE: Java flaw is in bytecode verifier
by Steve Gibbons 17 Dec '03

17 Dec '03

In Article: <199604020006.QAA21649(a)jobe.shell.portal.com>, Hal <hfinney(a)shell.portal.com> wrote: # From http://java.sun.com/sfaq/960327.html: # > Researchers at Princeton recently found an implementation bug in the Java # > bytecode Verifier. The Verifier is a part of Java's runtime system which # > certifies that applets downloaded over the Internet adhere to Java's # > language safety rules. Through a sophisticated attack, a malicious applet # > can exploit this bug to delete a file or do other damage. # This is one of the more worrisome places for a bug to exist. Much of # Java's security rests in the claim that it can screen for and detect bad # bytecode sequences. This screening code is extremely critical for Java # security and I am surprised to see that it was implemented in a flawed # manner. # I've been writing Java quite a bit in the last couple of weeks, and I # find that I have crashed my browser, whether Netscape or appletviewer, # many times. Granted some of my code has been pretty buggy, but it's # still not supposed to crash the browser. Obviously some of the runtime # checks are not being done properly. I had expected that the bug would # be in these areas, something like the stack overflows that we have seen # cause problems in the past. A simple error in the bytecode verifier # (if that is what this really is) seems like a more fundamental security # flaw. # The researchers have still not released full details on the bug, although # they had planned to do so by the end of March. Maybe they are waiting # for the fix to be distributed. As I keep saying (multiple times, in multiple forums) "Java is still in Beta-Test." Sun acks/grocks this, although Netscape ships most of their production-level browsers with Java enabled by default. The primary reason for releasing beta software is to catch any discrepancies between the documented behaviour and the implimented behaviour of a product. Bugs WILL be found in beta testing. To reiterate: "If you insist on being on the bleeding edge, you WILL bleed." This has been a test of the emergency reality-check service. Had this been a real reality-check, the software in question would be labeled "golden" and you would be provided with a "support(a)foo.bar.com" email address to contact for your product. Again this is only a test, and is (as such) non flamable. Any party that might take offense to this message should re-read the contents of the message, and either A) re-evaluate their perception of it, or B) re-evaluate their practices. -- Steve(a)AZTech.Net

1 0

Ecash Article in ID
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

This is a resend, but my subject didn't match the content in the last send { Found an interesting article on Ecash in Industrial (Internatioal) Design. / What is Money / Karrie Jacobs ID March/April 96 } _______________________ Regards, Those who would have nothing to do with thorns must never attempt to gather flowers. Joseph Reagle http://farnsworth.mit.edu/~reagle/home.html reagle(a)mit.edu 0C 69 D4 E8 F2 70 24 33 B4 5E 5E EC 35 E6 FB 88

1 0

Cypherpunks investigated, FOIA?
by Declan B. McCullagh 17 Dec '03

17 Dec '03

>From sgs(a)well.com: Have the cypherpunks requested data on whether they are being investigated by the same agencies under the FOIA individually or as a group listed by that name? If so, what are the results, if any, so far? Does anyone know if this has been done? The FOIA, that is. -Declan

1 0

Re: software with "hooks" for crypto
by John Deters 17 Dec '03

17 Dec '03

At 02:31 PM 4/2/96 -0800, you wrote: >Hello all, > >I'm trying to figure out exactly what the laws are regarding the export of >software which contains "hooks" for PGP. In various forms, I've heard >that it's not the ITAR which prevents this, but more a "suggestion" by >the NSA that we "shouldn't do it." Does anyone have any pointers to >real legislation/laws regarding this? There are a number of "PGP Helpers" (If this is Tuesday, it must be PGP) out there. These are other PGP front end applications such as Private Idaho, PGPShell and others that do NOT include PGP, nor do they contain any encryption code within them. These applications are all billed as "freely exportable". If your software does not contain any encryption code, such that it simply "invokes" the users separately-obtained-and-installed copy of PGP, you are not in violation of ITAR. It sounds like this is what you're doing with your "hooks for PGP". I would recommend you visit a couple of these helper application sites and check out what their authors say about the exportability of their code. You might ask them if they have encountered any legal difficulties because their code is advertised as freely exportable. Private Idaho is available at www.eskimo.com/~joelm and (rats) you'll have to hunt PGPShell down yourself. If you actually include the RSA algorithms, the IDEA algorithm, or any "cryptographic" code in your software, then yes, you could get in trouble for exporting it. Again, remember that I'm not a lawyer and that any legal advice you get from anyone on the net is worth exactly what you pay for it. -j, is anyone else finding it harder to say the "Pledge of Allegiance" to this country these days? -- J. Deters >From our _1996_Conflict_of_Interest_Statement_, re: our No Gift policy: "If you receive any alcoholic beverages, for example, a bottle of wine, you must give the gift to your location Human Resources Manager." This memo is from the Senior V.P. of Human Resources. +---------------------------------------------------------+ | NET: jad(a)dsddhc.com (work) jad(a)pclink.com (home) | | PSTN: 1 612 375 3116 (work) 1 612 894 8507 (home) | | ICBM: 44^58'33"N by 93^16'42"W Elev. ~=290m (work) | | PGP Key ID: 768 / 15FFA875 | +---------------------------------------------------------+

2 1

ssh won the Sampo Data Security Prize!
by Kauto Huopio 17 Dec '03

17 Dec '03

The local TV news just announced that Tatu Ylonen won the Sampo Insurance Company's Data Security Prize 1996. Ssh will have a lot of good publicity here in Finland.. --Kauto *********************** Kauto Huopio (Kauto.Huopio(a)lut.fi) ****************** *Mail: Kauto Huopio, Laserkatu 3 CD 363, FIN-53850 Lappeenranta, Finland * *Tel : +358-53-4126573, GSM(mobile): +358-40-5008774 * *****************************************************************************

1 0