December 2003 - cypherpunks-legacy

Re: Whom can you trust with your keys -- government version
by Peter Trei 18 Dec '03

18 Dec '03

> From: Hal Abelson <hal(a)martigny.ai.mit.edu> > Date: Thu, 12 Dec 1996 15:29:25 -0500 > To: cypherpunks(a)toad.com > Subject: Whom can you trust with your keys -- government version > Reply-to: hal(a)MIT.EDU > -----BEGIN PGP SIGNED MESSAGE----- > > > The Commerce Department draft crypto export regulations (see > http://www.steptoe.com/commerce.htm) include the following stipulation > on Key Recovery Agents: > > > Evidence of an individual's suitability and trustworthiness [to > act as a key recovery agent] shall include: > > (i) Information indicating that the individual(s): > > (A) Has no criminal convictions of any kind or > pending criminal charges of any kind; > > (B) Has not breached fiduciary > responsibilities (e.g., has not violated any > surety or performance bonds); and > > (C) Has favorable results of a credit check; > or, > > (ii) Information that the individual(s) has an active > U.S. government security clearance of Secret or higher > issued or updated within the last five years. > > It's nice to know that we can trust ex-cons, frauds, and deadbeats to > hold our keys, provided that they have obtained a Secret clearance. Sorry, but you're mistaken. There is an implied AND between (i) and (ii), not an OR. Curiously, it looks like I may be eligible to run an GAK service. Peter Trei trei(a)process.com

1 0

ASM vs portable code [WAS: Re: Java DES breaker?]
by Peter Trei 18 Dec '03

18 Dec '03

Ray Arachelian <sunder(a)brainlink.com> wrote: > On Wed, 11 Dec 1996, Dr.Dimitri Vulis KOTM wrote: > > > I happen to have a Sparc 20 box and a Linux box and a SCO box, and ActiveX > > won't work on any of those. I also work with a bunch of other equipment > > that's much faster than a PC, but doesn't run browsers. (Most of it is not > > connected to the 'net for security reasons, but that's besides the point.) > > Right, and Active X, if those machies were on the web, would not be > supported. > > > If Bill's client is sure to run the platforms that MS IE runs on, then this is > > not a consideration. > > Correct, however there is one thing you have forgotten... (next paragraph) > > > Interpreted FORTH bytestream (which is what Java is) may be "doing quite well" > > when drawing GUI gizmos and widgets, but it can't get anywhere near the > > performance of hand-optimizer assembler that you can stick into ActiveX. > > While ActiveX does support hand optmized assembler, there are Java > JustInTime compilers which take JVM bytecodes and turn'em into raw > assembler. They aren't hand optimized, they are natively compiled code, > but they are native code non the less. A good optimizing compiler may > not be 100% as cool and as fast as hand optmized code, BUT it'll be > almost as fast. And Java will run on just about EVERY platform out there. > And that is a bigger, more important point than a 10%-25% increase in > power over non-optimized code. > > Besides, I'm not arguing AGAINST an ActiveX client, there's no reason > why there can't be both Java and ActiveX clients out there since there is > both a compatibilty issue and a speed increase with ActiveX. While I'm reluctant to ever find myself in the same corner as Vulis, he has a point. As one of the few folks on this list who actually writes code, I say that hand-optimized assembler will beat machine generated code every time. I have figures to back me up. As some of you know, I've been working on a DES key recovery tool. I'm have both portable C and x86 assembler versions. They are currently identical, except that the guts of the DES round is written in "C" in one, and hand-optimized Pentium assembler in the other. For this test, I modified the code to cut out the delays associated with incrementing the key schedule, leaving the most of the crunching in the DES decryption. Both versions were compiled under Visual C++ 4.0, with Optimizations set to 'Maximize speed', and inlines to 'any suitable', and run on a 90MHz Digital Celebris 590 under WinNT 3.51. Averaging several runs: "C": 102,300 crypts/sec ASM: 238,000 crypts/sec With Java, it's possible to add native code methods to the interpreter, though this requires extra work by the user - it's harder than 'click on this link to run my reely kool applet'. This violates the Java sandbox, and requires the user to make trust decisions on the methods they are adding. ActiveX lets you add and run native code with a click, but again involves trust decisions. My philosophy is 'the more the merrier'. I'd like to see people work on DES Key Recovery on a large number of platforms - we just need to standardize on the input and output formats. Peter Trei trei(a)process.com Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

4 3

Credentials without Identity--Racey Bits
by nobody＠cypherpunks.ca 18 Dec '03

18 Dec '03

At 05:30 AM 12/13/96 -0500, Jill heatedly wrote: :So white Boyz Club excludes women to, is that correct? By definition, you steaming dreamboat. Drop me a note, kitten. XXOO Snookums

1 0

ASM vs portable code [WAS: Re: Java DES breaker?]
by Peter Trei 18 Dec '03

18 Dec '03

Sorry if this is a repeat - I got a rather opaque 'delivery failure' message when I first sent it. - pt Ray Arachelian <sunder(a)brainlink.com> wrote: > On Wed, 11 Dec 1996, Dr.Dimitri Vulis KOTM wrote: > > > I happen to have a Sparc 20 box and a Linux box and a SCO box, and ActiveX > > won't work on any of those. I also work with a bunch of other equipment > > that's much faster than a PC, but doesn't run browsers. (Most of it is not > > connected to the 'net for security reasons, but that's besides the point.) > > Right, and Active X, if those machies were on the web, would not be > supported. > > > If Bill's client is sure to run the platforms that MS IE runs on, then this is > > not a consideration. > > Correct, however there is one thing you have forgotten... (next paragraph) > > > Interpreted FORTH bytestream (which is what Java is) may be "doing quite well" > > when drawing GUI gizmos and widgets, but it can't get anywhere near the > > performance of hand-optimizer assembler that you can stick into ActiveX. > > While ActiveX does support hand optmized assembler, there are Java > JustInTime compilers which take JVM bytecodes and turn'em into raw > assembler. They aren't hand optimized, they are natively compiled code, > but they are native code non the less. A good optimizing compiler may > not be 100% as cool and as fast as hand optmized code, BUT it'll be > almost as fast. And Java will run on just about EVERY platform out there. > And that is a bigger, more important point than a 10%-25% increase in > power over non-optimized code. > > Besides, I'm not arguing AGAINST an ActiveX client, there's no reason > why there can't be both Java and ActiveX clients out there since there is > both a compatibilty issue and a speed increase with ActiveX. While I'm reluctant to ever find myself in the same corner as Vulis, he has a point. As one of the few folks on this list who actually writes code, I say that hand-optimized assembler will beat machine generated code every time. I have figures to back me up. As some of you know, I've been working on a DES key recovery tool. I'm have both portable C and x86 assembler versions. They are currently identical, except that the guts of the DES round is written in "C" in one, and hand-optimized Pentium assembler in the other. For this test, I modified the code to cut out the delays associated with incrementing the key schedule (this is not in assembler yet, and slows down the assembler version about 30%), leaving the of the crunching in the DES decryption. Both versions were compiled under Visual C++ 4.0, with Optimizations set to 'Maximize speed', and inlines to 'any suitable', and run on a 90MHz Digital Celebris 590 under WinNT 3.51. Averaging several runs: "C": 102,300 crypts/sec ASM: 238,000 crypts/sec With Java, it's possible to add native code methods to the interpreter, though it requires extra work by the user - it's harder than 'click on this link to run my reely kool applet'. This violates the Java sandbox, and requires the user to make trust decisions on the methods they are adding. ActiveX lets you add and run native code with a click, but again involves trust decisions. My philosophy is 'the more the merrier'. I'd like to see able to people work on DES Key Recovery on a large number of platforms and modes - we just need to standardize on the input and output formats. Peter Trei trei(a)process.com

2 1

ITARs effects
by Adam Shostack 18 Dec '03

18 Dec '03

I cross posted the ITAR proposed rev pointers to Firewalls. In addition to an entertaining rant, Marcus posted this: ----- Forwarded message from Marcus J. Ranum ----- >From mjr(a)mail.clark.net Thu Dec 12 17:38:57 1996 Message-Id: <199612122240.RAA10556(a)mail.clark.net> Comments: Authenticated sender is <mjr(a)mail.clark.net.> From: "Marcus J. Ranum" <mjr(a)mail.clark.net> Organization: V-ONE Corp Baltimore office To: adam(a)homeport.org Date: Thu, 12 Dec 1996 17:42:00 +0000 Subject: that doc.... Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42a) You posted a pointer to that document. It was quite interesting. I see that the feds are making INDIVIDUALS responsible for ENFORCING export laws!!! Read carefully: (9) Export of encryption software. The export of encryption source code and object code software controlled for EI reasons under ECCN 5D002 on the Commerce Control List (see Supplement No. 1 to part 774 of the EAR) includes downloading or causing the downloading, of such software to locations (including electronic bulletin boards and Internet file transfer protocol and World Wide Web sites) outside the U.S., and making such software available for transfer outside the United States, over radio, electromagnetic, photo optical, or photoelectric communications facilities accessible to persons outside the United States, including transfers from electronic bulletin boards and Internet file transfer protocol and World Wide Web sites, or any cryptographic software subject to controls under this regulation unless the person making software available takes precautions as adequate to prevent unauthorized transfer of such code outside the United States. This provision applies both to the uploading and downloading of such software. For purposes of this paragraph, the following shall constitute adequate precautions to prevent unauthorized transfer: This implies that putting something up for FTP == export. Holy shit. mjr. ----- Marcus J. Ranum, Chief Scientist, V-ONE Corporation Work: http://www.v-one.com Personal: http://www.clark.net/pub/mjr "I'll have time to be laid back when I'm laid out on a slab" ----- End of forwarded message from Marcus J. Ranum -----

6 7

Re: Elliptic curves--hot stuff here
by nobody＠cypherpunks.ca 18 Dec '03

18 Dec '03

At 05:18 AM 12/13/96 -0500, my baby, Jill, wrote: :Please tell the faggots to stop being so sexist. : :Jill : OK, all you faggots stop being so sexist. :Just what is it about these queers that makes them hate women so much :anyway? Are they jealous of us sexy women because their boyfriends :may want us? Oh, yea, and all you sexy hot AOL chicks stop turning on all the queers' boyfriends. P.S.: Jill, come up and see me sometime. I'm ready to start over if you are. XXOO Snookums

1 0

RSA Laboratories seeks contributions for the "next generation" of PKCS
by John Gilmore 18 Dec '03

18 Dec '03

From: Ray Sidney <ray(a)RSA.COM> To: "'e-payment(a)bellcore.com'" <e-payment(a)bellcore.com>, "'firewalls(a)greatcircle.com'" <firewalls(a)greatcircle.com>, "'ietf-otp(a)bellcore.com'" <ietf-otp(a)bellcore.com>, "'ietf-pkix(a)tandem.com'" <ietf-pkix(a)tandem.com>, "'ipsec(a)ans.net'" <ipsec(a)ans.net>, "'www-security(a)ns2.rutgers.edu'" <www-security(a)ns2.rutgers.edu> To: "'rsa-licensees(a)rsa.com'" <rsa-licensees(a)RSA.COM>, "'swan-dev(a)rsa.com'" <swan-dev(a)RSA.COM>, "'smime-dev(a)rsa.com'" <smime-dev(a)RSA.COM> Subject: RSA Laboratories seeks contributions for the "next generation" of PKCS Date: Fri, 13 Dec 1996 10:07:47 -0800 Comments and suggestions are invited for the next generation of the Public-Key Cryptography Standards, the intervendor specifications developed starting in 1991 by RSA Laboratories in conjunction with industry and universities. The Public-Key Cryptography Standards were established to provide a catalyst for interoperable security based on public-key cryptographic techniques, and they have become the basis for many formal standards and are implemented widely. With several years' experience and review, and with many new developments in cryptography since 1991, it is now time to update PKCS. Suggestions are invited in the following areas: * improvements to the current suite of standards * contributions for new standards, including standards for transport and local storage of personal information such as private keys and certificates, and standards for platform-independent cryptographic programming interfaces PKCS documents are low-level standards stating precisely how one may accomplish specific cryptographic or cryptography-related tasks. Most are concerned with specifying byte-level recipes (often in ASN.1) for formatting various types of data (such as a block which is to be RSA-encrypted), rather than making general security-related recommendations ("An RSA modulus should be at least XXX bits long."). RSA Laboratories is actively soliciting suggestions and contributions for the "next generation" of PKCS from now until the end of April 1997. If you have written up a document detailing extensions you've made to an existing PKCS, and you feel that others could benefit from the use of your extensions, then we'd like to see your document. If you have an idea for a new PKCS, we'd like to hear that, too. And if you have something somewhere in between, send it along; of course, detailed, well-developed contributions are generally preferred. Suggestions should be sent either to the pkcs-tng(a)rsa.com mailing list (you can subscribe to this list by sending email with "subscribe pkcs-tng" in the message body to majordomo(a)rsa.com; unsubscribe with "unsubscribe pkcs-tng") or to pkcs-editor(a)rsa.com, whichever is deemed more appropriate. Current PKCS documents are: PKCS #1: RSA Encryption Standard. PKCS #3: Diffie-Hellman Key-Agreement Standard. PKCS #5: Password-Based Encryption Standard. PKCS #6: Extended-Certificate Syntax Standard. PKCS #7: Cryptographics Message Syntax Standard. PKCS #8: Private-Key Information Syntax Standard. PKCS #9: Selected Attribute Types. PKCS #10: Certificate Request Syntax Standard. PKCS #11: Cryptographic Token Interface Standard (CRYPOKI). The above documents are available from RSADSI's web site, and links to them may be found at http://www.rsa.com/rsalabs/pubs/PKCS/. All contributions received shall be examined, and, if appropriate, a workshop (or several workshops) shall be held to further determine the content of the "next generation" of PKCS.

1 0

Enigma
by nobody＠cypherpunks.ca 18 Dec '03

18 Dec '03

Tim C. Mayonnaise, a product of anal birth, appeared with a coathanger through his head. /\_./o__ Tim C. Mayonnaise (/^/(_^^' ._.(_.)_

1 0

ITAR -> EAR; loss of First Amendment Rights.
by Peter Trei 18 Dec '03

18 Dec '03

Reading the proposed new rules, what disturbs me most deeply is the statement: - start quote - 16. Section 734.7 is amended by revising paragraph (b) to read as follows: 734.7 Published information and software. * * * * * (b) Software and information is published when it is available for general distribution either for free or at a price that does not exceed the cost of reproduction and distribution. See Supplement No. 1 to this part, Questions G(1) through G(3). Note that encryption software controlled under ECCN 5D002 for "EI" reasons on the Commerce Control List (refer to Supplement No. 1 to part 774 of the EAR) remain subject to the EAR even when publicly available. Accordingly, such encryption software in both source code and object code remains subject to the EAR even if published in a book or any other writing or media. - end quote - It appears that we will now have the unique situation that a book which contains cryptographic info or source code will be illegal to export or sell to a non-citizen, without getting export permission. I am not aware of any prior time when the government attempted to claim that printed material, freely available in bookstores and newsstands to US citizens, became contraband when sold or given to a non-citizen. Who's responsible for enforcing this? The vendor? The clerk at Barnes & Noble? The publisher? If the latter, how many publishers will take the risk of printing books with crypto information? Will Wiley pull "Applied Cryptography" from the shelves? This doesn't just chill free speech, it dunks it in liquid helium. It's difficult to think of clearer case of prior restraint. ----------------- Peter Trei trei(a)process.com Disclaimer: I am not speaking for my employer.

3 2

Would you send money to Gary Rasmussen ?
by peter.allan＠aeat.co.uk 18 Dec '03

18 Dec '03

Gary Rasmussen (RagyR(a)aol.com) replies to me as below: Have people got a view on the second question ? I've had no contact with Gary before and he may very well be honest; but there's proper trust and there's stupidity. > Hi Peter, > > > I'm looking for Kahn's book. Have you an acccurate price now? > > A lot of copies (about 100) have been sold since .... > > > > (And is there anyone I'd know who'd suggest I send you money ?!) > > Good question, but very hard to answer since I don't know who you > know. Can tell you that I operate Classical Crypto Books primarily as > a service for other members of the ACA. Two possible references are > the current and past ACA presidents: > > jimg(a)mentat.com (Jim Gillogly, ACA President 1996-1998) > 75542.1003(a)CompuServe.COM (Randy Nichols, ACA President 1994-1996) > > Operating CCB is not my main occupation (by day I'm a scientist working > for MIT's Lincoln Lab). Can also say proudly that in 1.5 years of operating > CCB I haven't had any complaints. > > Please let me know if you have other questions or would like a complete > copy of the CCB catalog. > > Best Wishes, > Gary Rasmussen > Classical Crypto Books

1 0