December 2003 - cypherpunks-legacy

Re: Test case for RSA t-shirts
by jim bell 17 Dec '03

17 Dec '03

At 12:33 AM 4/2/96 -0800, Jeff Weinstein wrote: >Dave Del Torto wrote: >> >> At 1:08 pm 3/30/96, Raph Levien wrote: >> > While we're on the subject, I called Sam Capino's office regarding my >> >CJR for this t-shirt, and he said they were still waiting for a response >> >from the NSA. I think my next move will be a letter asking exactly when >> >I can expect a response, and whether there's anything I can do to compel >> >a response, It was originally filed (in October) as a 15-day expedited >> >review. >> >> FYI, PRZ mentioned to me last night that the CJR on the OCR-able book of >> PGP source is still pending. The "15 days" has stretched into about a year >> in that case, if I don't have my dates/the facts wrong. Bob Prior at MIT >> would know. I'm trying to figure out what the difference is (legal) between a "book" an an "OCR-able" book. FAIK, all fonts are OCR-able, simply with widely varying degrees of difficulty. A fixed-spacing, non-microspace justified typewriter font is probably one of the easiest ones to OCR. Did the export license application for this "OCR-able" book say that "It's an OCR-able" book, or did they just include a copy of that book on paper?

1 0

[MagicMoney] Passwords of various PGP keys.
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

I played with Magic Money recently. I wondered: Where are the passwords of the various PGP keys stored? Now, suppose you want to use this system for serious use: What, if any, are the critical files that must be protected from outsiders to prevent tempering (altering without the owner's ability to quickly discover the manipulation) with the system data? Is is necessary to encrypt the whole client directory when you don't use it? Ditto, for the server? JFA PGP key at: http://w3.citenet.net/users/jf_avon Jean-Francois Avon <jf_avon(a)citenet.net> ID:C58ADD0D 96/03/01 fingerprint: 52 96 45 E8 20 5A 8A 5E F8 7C C8 6F AE FE F8 91 Unsollicited commercial e-mail will be proofread at a rate of 165 $ U.S. per hours. Any sender of unsollicited commercial e-mail will be considered as to have accepted the above ment- ionned terms.

1 0

Treasure of Sierra Madres?
by cpunk＠remail.ecafe.org 17 Dec '03

17 Dec '03

"The scent of riches wafting from cyberspace is overpowering." Free CSI Report Explores Threats to Secure Electronic Commerce San Francisco, April 2 -- The drive toward Internet commerce is unstoppable. But how serious are the security threats associated with it? And how effective are the proposed solutions? Computer Security Iinstitute's "Special Report on Electronic Commerce Security: Treasure of Sierra Madres?" offers a comprehensive look at the risks, threats and vulnerabilities of Internet-based transactions. Will the profits justify the risk? What lessons can be drawn from recent revelations such as the vetting of Netscape, the robbing of Citibank, the ransacking of the Netcom and the Kocher "timing attack?" This latest "CSI Special Report" contains insightful answers from a broad range of experts including Dr. Gene Spafford of Computers, Operations, Audit, Security and Technology (COAST), Donn B. Parker of SRI International, Dan Farmer, co-author of SATAN, and Mack Hicks, Vice President of Bank of America. "The scent of riches wafting from cyberspace is overpowering," comments Richard Power, CSI editor and author of the report. "The risk of failing to go on-line is perceived as greater than the risk of failing to go on-line securely. But recent revelations about vulnerabilities in Java and Netscape highlight how much still needs to be done." The 19-page study includes practical tools such as electronic commerce security checklists and sample electronic commerce policies. To obtain a free copy of CSI's "Special Report on Electronic Commerce Security" email your mailing address to prapalus(a)mfi.com, phone 415-905-2310, or fax 415-905-2218. Computer Security Institute (CSI) is the industry's leading international membership organization specifically serving the information security professional. Established in 1974, CSI has members worldwide and provides a wide variety of information and educational programs to assist practitioners in protecting the information assets of corporations and governmental organizations. --

1 0

Video retraces as a source of entropy...
by Deranged Mutant 17 Dec '03

17 Dec '03

Quickie blurb on using video card retraces as a source of entropy... I've done some brief testing in the last couple of days on using the timing drift between video retrace events as a source of randomness. It seems comparable to truerand() spinners that check the system's timer ticks [which makes me leary of relying on it since it has similar strange attractors when plotted in a noise sphere, but that's another post...]. Assuming one trusts truerand spinners, this method could have some advantages over a 'pure software' method, since the video controller (and other hardware controllers which could be adapted to this) runs in 'parallel' [although it's liable to the samefluctuations in current or memory-access and other interfaces with the main system, or possibly tempest attacks for the paranoid...]. In pseudo-C: int retrace(void) { // test for video retrace #ifdef __MSDOS__ return (port[0x3da] & 8); // Some VGA, maybe EGA cards #else // your OS here #endif } [..] x = 0; while (!retrace()) x++; I've tested it as standalone routines (in Pascal and assembler) as well as a hook to the DOS idle in the background [See note about strange atteactors above]. It also seems to work while in Windows (but not OS/2?!), which is an advantage over using the system's microsecond timer alarm (which Win3 takes over). Comments? (other than "truerand is an oxymoron"....) Rob. --- Send a blank message with the subject "send pgp-key" to <WlkngOwl(a)unix.asb.com> for a copy of my PGP key.

1 0

Re: Witch Hunts
by jim bell 17 Dec '03

17 Dec '03

At 08:55 PM 4/1/96 EST, Dr. Dimitri Vulis wrote: >Bruce Zambini <jlasser(a)rwd.goucher.edu> writes: >> On Sun, 31 Mar 1996 JonWienke(a)aol.com wrote: >> > Unicorn = Detweiler = Agent Provocateur >> >> Well, I won't say it's impossible. > >Don't you get the hint -- Unicorn == Sir Lancelot == Lance. Hey, I never thought of that! I guess my knowledge of early English mythology is a bit weak. Jim Bell jimbell(a)pacifier.com

1 0

Pathfinder Survey
by survey＠pathfinder.com 17 Dec '03

17 Dec '03

Dear Pathfinder Member: Will you help us on a very important project? You are one of a representative group of Pathfinder members that we are asking to take part in a special survey. The answers you provide us with will help us make Pathfinder a pleasurable experience for its users. Our survey is available online (you can cut and paste the URL into your browser) at: http://pathfinder.com/poll Please take a few minutes and complete the questionnaire now. Your answers will be treated in the strictest confidence. Since you are part of a small, carefully selected sample, your response is very important to the success of our study. Thank you very much for your help. Sincerely yours, Gina Monaco Market Research Manager

1 0

Majordomo and anon.penet.fi
by Mark M. 17 Dec '03

17 Dec '03

In case anyone is interested, I have written a patch for Majordomo 1.93 that will automatically convert an address of the form "anXXXXX(a)anon.penet.fi" to "naXXXXX(a)anon.penet.fi". I have tested the code I used to patch up Majordomo, but I haven't verified that it actually works within Majordomo. *** majordomo.pl.orig Sat Jan 7 12:34:27 1995 --- majordomo.pl Tue Apr 2 23:24:15 1996 *************** *** 81,86 **** --- 81,91 ---- $ReplyTo = $array{'apparently-from'} unless $ReplyTo; join(", ", &main'ParseAddrs($ReplyTo)) if $ReplyTo; + if ($ReplyTo =~ '^(an).*\(a)anon\.penet\.fi') + { + $anonid = substr($ReplyTo, 2); + $ReplyTo = "na$anonid"; + } $ReplyTo; } -- Mark =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= markm(a)voicenet.com | finger -l for PGP key 0xf9b22ba5 http://www.voicenet.com/~markm/ | bd24d08e3cbb53472054fa56002258d5 "The concept of normalcy is just a conspiracy of the majority" -me

1 0

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

17 Dec '03

From: me(a)muddcs.cs.hmc.edu (Michael Elkins) > I've written a Unix e-mail client which contains support for PGP/MIME and > also a front end for mixmaster. Right now I basically reap all the "bad" > code before I distribute it (at _least_ 50% of my testers are outside the > US). However, this has been annoying for those users because they want > to be able to use the PGP support (so do I!). So, what I'm wondering is > what the laws are regarding snail-mailing source code to these people. > The actually pgp/remailer stuff isn't more than a few pages of code, which > could easily be transcribed or scanned in with OCR software. Would I > have to get a "license for export" in order to send the code outside the > US? Let me first point out that this procedure is not as easy as it sounds. Phil Karn has an interesting description of what happened when he actually tried to do this, as part of his suit to try to export the Applied Cryptography source code on disk. It is at <URL: http://www.qualcomm.com/people/pkarn/export/karndecl.html >. This is something that people have talked about for a long time, and it is interesting to see what happened when he tried it: 5. I began by first photocopying, on a standard office photocopier, the 18 pages containing the Triple DES source code listing from Part V of the Book. This took about 5 minutes. Second, I scanned in the 18 sheets on a Macintosh Quadra 610 computer system equipped with an HP ScanJet II flatbed scanner and Omnipage Professional optical character recognition (OCR) software. The computer, scanner, and software are all readily available through normal consumer computer supply channels. The total scanning process took about one and a half hours. About an hour of this time was spent learning to use the scanning system and conducting trial runs, as I had only used it briefly some time ago. The actual scan of the 18 pages took about 15-20 minutes. Third, I transferred the resulting machine-readable file from the Macintosh to my own personal computer and brought it up under GNU EMACS, a popular and widely available text editing program that I have used for many years. In EMACS I compared, by eye, the scanned file displayed on my screen against the printed listing in the Book. I began correcting the scanner's many errors, such as mistaking the digit '0' for the letter 'O' or mistaking the vertical bar '|' for the letter 'I'. 6. After manually correcting those errors noticed through visual comparison with the Book, I invoked the "C" language compiler on the (partially) corrected file. The compiler immediately pointed out additional errors I had overlooked in my visual inspection so I could also correct them by reference to the Book. I also noticed several errors in the listing printed in the Book. However, the programmer's intentions were obvious from the context of each error and were easily fixed. About fifty minutes later, I successfully compiled the file without error. 7. The fourth step was to write a small test program to execute the DES code with the test vectors given at the end of the source code listing. This trivial program took less than 5 minutes to write. Unfortunately, the test did not succeed, meaning that at least one error went undetected by the compiler in either the code as printed in the Book or as scanned. Scrutinizing the code more closely, I quickly found another error in the printed version that was easily corrected. However, it still did not produce correct results. After about an hour of searching, I finally located the error in a list of numbers in a table -- another error in the printed version. By reference to the DES algorithm description in the first part of the Book, which includes the correct numbers in tabular form, I found and corrected the error. 8. At this point the test finally succeeded, so I knew I had a correct program. As you can see, it took a long time. Part of the problem was that the printed copy of the code was apparently simply wrong. Presumably if you printed it this would not be the case. Also, your code is shorter than the 18 pages that Phil had to work with. Still OCR may not be that well adapted to source code. Most texts use ( a lot more than {, and the OCR may not pick out that kind of difference well. I will also note, parenthetically, that it is a credit to Phil that he was obviously being very honest and above-board in describing what he had to go through, possibly to his (and our) own detriment. If the process of turning the book into the floppy were easier and did not appear to require so much expertise, the government's case might have been weakened. Your bigger question is about the legalities of it, and that is harder to answer. There is a continuum of cases. At one end we can say that it is apparently legal to discuss cryptographic algorithms with foreigners. This happens all the time at international conferences. As long as the material isn't classified, you can talk about the technical issues. At the other end, it is at present definitely illegal to export a working cryptographic device. In between there is a gray area. Currently it appears that exporting cryptographic source code in machine readable form on magnetic media is illegal, at least pending some resolution of the Karn suit. Probably exporting it in other ways, such as by email, would be treated the same. My guess is that exporting in machine readable form on paper, such as by a bar code, would also be equivalent. There is a little more effort involved in scanning it in, but if the bar code has good redundancy and is reliable, it is not much more. The next step is printed source code. There are fonts (or other tricks, such as per-line checksums) which can be used to make scanning this in relatively reliable. I don't have enough experience to know how good it can get. But let's suppose it were practically error-free. By the reasoning above, this would also be restricted. OCR'ing the text, if it can really be done mechanically and automatically (which is clearly not the case with the technology that Phil Karn had access to) is not much different from getting it on a floppy. Yet we know that at least in the case of Applied Cryptography the book, export permission was granted. So at least in some cases, printed source code can be exported. I understand that the PGP source code book is in an OCR friendly font. It would be interesting to hear whether Phil's experience above is actually made easier with the PGP source code book. I think the bottom line is that the government will restrict any method which makes it significantly easier for a foreigner to get working source code than by typing it in from a book by hand. (BTW, Phil's lawyer did have two secretaries do that. It took under 3 hours, although presumably the code was subject to some of two same printing errors that Phil had to fix in his test.) So my guess is that technically you could get in trouble by doing what you propose. I'm not a lawyer though - Hal

1 0

Re: Chaumian ecash without RSA
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

>> 2: Nobody except the bank can verify that a coin has face validity. At 04:55 PM 4/2/96 +0100, D.A. Wagner wrote: > I claim that statement 2 is also true of Digicash's protocol as well. > > Recall that Digicash is using an *online clearing* protocol-- so you > can't tell whether a coin is valid without consulting the bank. > Consulting the bank is absolutely necessary to prevent double spending. Suppose Alice generates an unsigned coin, blinds it, and shows Bob the usigned, blinded coin. Bob then has the bank sign it, and gives the signature to Alice. If we use RSA to sign the coin, Alice now knows she has a valid coin, because she can verify the coin herself without needing to show it to the bank. So Bob has paid Alice some money, and nobody can double spend the coin, because Alice, and only Alice, knows the blinding factor. So Alice does *not* need to check with the bank. Alice cannot do this with your protocol, so we cannot have payee anonymity with your protocol. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

2 1

Re: software with "hooks" for crypto
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

At 02:31 PM 4/2/96 -0800, Michael Elkins 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? Evidently you are under the impression that we are still governed in accordance with the rule of law. Since the legislation in question was intended to prohibit gun running, it naturally contains no such thing. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0