- cypherpunks-legacy - lists.cpunks.org

Cyberia-L Archive [was Re: ERA_sur]
by Rich Graves 17 Dec '03

17 Dec '03

As somebody pointed out to me, Cyberia-L, like cypherpunks, is archived on http://www.hks.net/ and the public news server nntp.hks.net. Now send them some of the money you're going to make from the stock market. -rich

1 0

Civilizing Cyberspace (book note)
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Forward: Steven E. Miller, a member of the national board of directors of Computer Professionals for Social Responsibility, has published a new book, *Civilizing Cyberspace: Policy, Power and the Information Superhighway* (Addison Wesley, 1995, 413 pages). This is the best book I have seen on the public policy debates surrounding the information superhighway. It covers all aspects of this debate, including democracy, citizenship, community networks, privacy, intellectual property, competing models of the NII, universal service, equity, freedom of expression, protecting the public interest, encryption, and so on. Highly recommended for anyone interested in this subject, or for use as a text in classes. Gary Chapman, Coordinator, The 21st Century Project LBJ School of Public Affairs, University of Texas, Austin

1 0

Re: Solution for US/Foreign Software?
by jimbell＠pacifier.com 17 Dec '03

17 Dec '03

> >> I'm not saying they are a "bypass" of the laws. Rather, I'm saying that >> if the goal is to: >> >> 1. Let companies like Netscape make foreign sales. >> >> 2. Still comply with the letter of the law. > >It takes more than one or two people to coordinate an international effort. >Once more than a few people know about it, it becomes "company policy" or >"corporate objective", in which case, the NSA/DoS will eventually figure it >out and start levying heavy fines and jailing the individuals. You miss the point! There will be no "international effort"! Here are the steps: 1. Write a program limited to keysize, carefully constructed to isolate those portions of the program which define key size, GAKedness, etc. 2. Get it export approved. Export it. THEN 3. Announce that a "US-only" version of the same program is being released, and include the minimal component which replaces the limited software. Release it, only in the US of course! >The main point is that there is no such thing as the "letter of the law". >What they enforce is much broader than that, and how they enforce it is much >more subtle than clear-cut criminal prosecution. Therefore, you cannot just >use literal loop holes just because it's not clear, because the law they are >enforcing is not clear either. The system I describe doesn't even violate the spirit of the rules. If anything, it bends over backward to implement a foreign version of the software which ALREADY is export-approved at the time it was, um, upgraded. True, it's possible to sneak the extra component out of the country, but hey, it's also possible to sneak an entirely new program out of the country. I'm not suggesting that the company who writes the component takes it out, it'll happen regardless. If the order of the versions was reversed, the USG might complain that the export version was "too similar" to the domestic version. That's why you wait for the export approval before you write the domestic version.

4 3

Re: The "Future" Fallacy
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:24 AM 12/6/95, blancw(a)accessone.com wrote: >From: Duncan Frissell > >Bill Gates (like Mister Newt before him) committed what I call the Future >Fallacy in "The Road Ahead." Page 106. > >"Soon any child old enough to use a computer will be able to transmit coded >messages that no government on earth will find easy to decipher." >................................................... > > >Billg is an optimist. > >What's wrong with this picture, Duncan? I found nothing wrong or incorrect with the quote Duncan attributed to Bill Gates (I haven't read Gates' book). I couldn't understand Duncan's koan, shrugged, and moved on. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

6 6

[NOISE] Re: PGP
by Hroller Anonymous Remailer 17 Dec '03

17 Dec '03

> > you really ought to be more thoughtful about what and how you write on > > the cypherpunks list... ** Vast numbers of double spaces deleted ** > The how is referring to not double spacing isn't it. Sorry, > I've been up for the last couple of days and didn't even realize it. > What do you mean what I write about? He means that this is NOT alt.security.pgp - we are not here to teach you how to use a bloody C compiler or to summarise README notes for you. RTFM. > > anyway, the PGP code from MIT should compile on nearly all unix > > machines. i'm not sure it will compile with a g++ compiler though. all > > unix type machines should have uncompress, tar, (g)cc. just get the > > source from MIT. > > I am not an idiot. I must have downloaded PGP from about 20 million > different places. They are all either missing files, some times the > darn code won't compile, or when I "tar xvf" half of the files bring > up an error and the computer says it can not create the file. I'll try > the address that you've sent. Hopefully I will have better luck. You want help, but supply minimal information. Post your problem to the appropriate place - alt.security.pgp, and supply a bit of information - what version of the source are you trying to compile, what Unix platform, what version of the C compiler, etc. > In the persuit of constructing a stable cryptographic program > that uses PGP what features should be included. Obviously all of > the ones that PGP has and encrypting/decrypting e-mail but what else? ?

1 0

Re: latest librand source now av
by an116512＠anon.penet.fi 17 Dec '03

17 Dec '03

In .cypherpunks, Matt Blaze <mab(a)research.att.com> writes: >[Sorry if this is a duplicate; my machine had a bogus sendmail.cf >when I first sent this.] > >Souce code for the latest version of librand (a random >number package based on event interval variations) for >Unix-like machines is now available in: > ftp://ftp.research.att.com/dist/mab/librand.shar > >There are no restictions on use or distribution of this >code, which was written by Matt Blaze, Jack Lacy, and >Don Mitchell. > >-matt > why the FUCK would anyone want to use random number code from at&t, (and mister nescape GAK apologist himself)? this the code that was broken by french student for christs sakes. and tell us the truth about the restrictions, next time, bozo. asshole. cypherpunks write code themselvess!!! --****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION*** Your e-mail reply to this message WILL be *automatically* ANONYMIZED. Please, report inappropriate use to abuse(a)anon.penet.fi For information (incl. non-anon reply) write to help(a)anon.penet.fi If you have any problems, address them to admin(a)anon.penet.fi

2 1

Re: NIST GAK export meeting, short version
by Bill Stewart 17 Dec '03

17 Dec '03

At 11:26 PM 12/5/95 -0500, Futplex <futplex(a)pseudonym.com> wrote: >> and on the 64-bit issue, that the government is "not certain it will >> work." he says they "want to see it implemented and want to see ... >This answer sounds rather silly to me. Do they seriously doubt that the >escrow mechanism works (modulo MAB's observations about the LEAF), or expect >us to believe that they do ? Clinton Brooks' comments cited later by Pat >suggest a certain acceptance that enforcement will have its problems >(e.g. strong crypto tunnelling), but perhaps Greiveldinger somehow doesn't >officially share that view. Is there another interpretation of "working" >I'm missing here ? "Works" means a lot of things, even if you limit the discussion to official court warrants requested with honest affidavits. The code is supposed to discourage tampering, but suspects may still successfully disable GAK. Escrow agents are supposed to deliver the correct keys successfully without losing them (or storing them safely in the basement next to the cyclotron), and they may not always provide 7x24 access (or may charge extra for it, as well as charging for their lawyer's review of the warrant.) Or the escrow agents may be multinationals that store their files off-shore. Or the SECRET cleared escrow employee may have quit, making it more difficult to handle classified requests. #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 # Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences # on both sides of the road?

1 0

Re: Solution for US/Foreign Software?
by Bill Stewart 17 Dec '03

17 Dec '03

>>>1. Write a program with limited encryption (40 bit?), with the encryption >>>module in a file external to the main program. >>>2. Get export approval for this program. >>>3. Write a module which replaces the encryption file, increasing key size >>>to whatever you REALLY wanted in the first place. (128-bit IDEA, 2000-bit >>>PGP, etc.) >>>4. Ship that new module with the old software to US customers. >>>Naturally, that new module will "leak," so anybody who buys the old Tim May replied >>"Crypto hooks," basically the scheme you are proposing, were thought of by >>the authorities and are not a bypass of the crypto export laws. I had interpreted the suggestion differently - rather than a system with user-accessible crypto hooks, the manufacturer could ship a binary patch upgrade for US customers to install. The internal design would presumably have crypto hooks (i.e. subroutine calls); they can't ban that. Of course, if you follow this strategy, get export approval for version 1.0, and ship the US-only patch as 1.1, getting export approval for version 2.0 may be a shade more difficult... #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281 # Anybody notice that Microsoft's Wide Open Road ad has barbed-wire fences # on both sides of the road?

2 1

Re: Why Netscape employees should not leave
by Jeff Weinstein 17 Dec '03

17 Dec '03

Adam Shostack wrote: > This leaves us to ask, why GAK is such a big deal at NIST, if > CKE will get them most of what they want? First, they haven't > realized that CKE is most of what they want. Second, they're worried > about the extra 10%. Drug dealers and terrorists not using it. (This > points towords an eventual mandate for GAK, even if it starts out > voluntary. Many have noted this.) Third, they've invested so much > energy in the fight for GAK that they're emotionally tied to the idea, > and they can't say 'well this would be almost as good.' It also allows them to stall on increasing the clearly inadequate export key size of 40-bit, while they are working on "an alternate solution". Given the overwelming negative response from industry over GAK, it may be nothing other than a delaying action. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw(a)netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.

1 0

Re: Solution for US/Foreign Software?
by daw＠boston.CS.Berkeley.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <199512062229.RAA16714(a)universe.digex.net>, Scott Brickner <sjb(a)universe.digex.net> wrote: > > I agree. It does bring to mind an idea, though. Netscape builds an > exportable system by choosing a random 128 bit number and then just > including 88 bits of it in plaintext. > > This means one of two things. Either there's a field which holds the > "key", but the export version stores 88 bits plain + 40 bits cipher, > and knows this structure, or there's a field which holds the 128 bit > enciphered key, and a second field which holds the 88 bits of plaintext > key. > It's the former (in SSL v2.0). I looked into this, because the former version can be vulnerable to related-key attacks, if not done right. SSL v2.0 does it right. (In particular, SSL v2.0 hashes both the 88 bit salt + 40 bit secret to get all the cipher keys.) > > In the former, the patch would be more significant, but still possible. > You'd disable the "write the plain" part and extend the "decode the > cipher" part to decode all 128 bits --- probably just a loop test. > (And you'd have to change the cipher type from RC4-40 to RC4-128.) Or write a local proxy to convert from RC4-40-salted to RC4-128. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMMZCbSoZzwIn1bdtAQF9xAGAqkg5VzChucF3FasK2pYVxg1D5F3lsnSP CFWsp+MbXKqTe71iznBvtg246xWPLohe =XM3W -----END PGP SIGNATURE-----

1 0