December 2003 - cypherpunks-legacy

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

Press Release on Response to Microsoft Internet Announcements
by Rich Graves 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I just posted the following from stanford.edu; it probably won't be approved and propagated in time, though. By the way, alt.internet.media-coverage, to which someone pointed me, is explicitly *not* for press releases. I do not plan to utter the string "cypherpunks(a)toad.com" because I think there's enough noise here already (some from me). Apologies to sameer for being presumptuous, but I did say "hope," and I also think tomorrow would be a really good time to document the .PWL file bugs... - -rich - ---------- Forwarded message ---------- Date: Wed, 06 Dec 1995 14:39:23 -0800 From: Rich Graves <w95netbugs(a)aol.com> Newgroups: misc.news.internet.announce, misc.news.internet.discuss Subject: Info on Microsoft Internet Announcements Thursday, December 7, 1995 Please reply, if necessary, to the address in the current FAQ, because I very seldom actually log on to America "On Line." Before forwarding this along, please check whether this has already been done; and let me know after the fact. As has already been announced in the print press, Bill Gates, who works at a large software company, will hold a press conference tomorrow, December 7th (a date with some historical significance), to announce Microsoft's Internet strategy. For information on Microsoft-sponsored marketing events in your area, please see http://www.microsoft.com/events/ Approximately fifteen minutes after Mr. Gates begins speaking (anyone have the exact schedule? please phone me), we hope to release very significant updates to the following Internet sites: http://www.c2.org/hackmsoft/ [information on a few security problems with Microsoft products] http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html [canon URL; multiple DNS-load-balancing SPARCServers] http://www-dccs.stanford.edu/NetConsult/Win95Net/faq.html [use this mirror of the above if you have an old DNS server that barfs on the www-leland lbnamed tricks] news.answers, comp.answers, comp.protocols.tcp-ip.ibmpc, and several higher-traffic groups will receive a text rendering of the above. This will be the first approved and rtfm-archived posting; the news-answers folks got back to me last week. gopher://quixote.stanford.edu/1m/win95netbugs will get a text rendering of the above, and contains relevant messages from an email discussion list. An email autoresponder to be named later (finger llurch(a)elaine.stanford.edu in the morning). The various archives on http://www.hks.net/ have additional information for the technically minded. A PGP-signed copy of this announcement is available on request, but I don't want to confuse the unwashed masses unnecessarily. - -rich "A day that will live in infamy" -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMMYaz43DXUbM57SdAQEeDQP/a8ZccX4fpMbKCNa6Cllii0qWI6A8oUKH 30fdoGl1HvlgWVhsB0paVLsQS8tQGsVt/MzKJLasTsnKuYVJCmdgmXcj9nEE9YIY SxBEDn6yGno2ey7G1lXJSkeVAjB8o/fX+kZXGNKfOGKgNqjIl12jHbW7NX1bsIKi wQl/s4uikQs= =6Z1M -----END PGP SIGNATURE-----

1 0

Responding to Exon -- technology is not enough
by Bill.Humphries＠msn.fullfeed.com 17 Dec '03

17 Dec '03

Jason Burrell <jburrell(a)crl.com> writes: >*Sigh*. Are we really ready to go back to UUCP? It looks like we'll have >to. That is, if someone doesn't set up a couple cryptographically enhanced >subnets first, or come up with some better idea. Interesting prospect, >actually. Fine for the tiny subset of Net users who understand crypto enough to use it on a daily basis. I'm not one of people either. This crypto isn't user friendly stuff. Before you propose such as solution, better make sure people can use this stuff. >Anyone wish to comment on the prospect of a double blind server, set >outside U.S. borders, that can act as an interface to the rest of the >world, perhaps encrypting or stego'ing the data transfered between it and >the user? Basically, an anonymous remailer that acts as a cross between >an NNTP, POP3, and SMTP servers. How are you going to pitch this technology to all the people with AOL and Microsoft Network accounts who barely understand the net? These are the people who need exposure to all the uncensored expression they can get. Instead of figuring out how to build a new treehouse that excludes Exon and Hyde, how about fighting the damned bill in the courts? bill.humphries(a)msn.fullfeed.com | WisCon 20: Two Decades of Feminism & SF http://www.cs.wisc.edu/wiscon/ | Ursula K. Le Guin: Guest of Honor

3 2

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

[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

Still more on the Digicash protocol
by daw＠guaymas.CS.Berkeley.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Ian & I were talking about the Digicash protocol some more. Hal has pointed out that payments & deposits with a wildcard in the payment_hdr should NOT be sent in the clear, since they can be stolen by any passive eavesdropper. Ian has pointed out the same problem with cancellations: the payer_code should NOT be sent in the clear, since any passive eavesdropper can grab this info and steal the corresponding payment. Sadly, the current Digicash client DOES send those items in the clear (without even warning users to avoid wildcards). Why? Anyhow, the obvious solution is encryption. Our new observation is that encrypting deposits & cancellations with the mint's public key is not enough to solve the problem. To see this, recall how the public key encryption works: a session key for a bulk cipher is encrypted under the public key, and the data (e.g. userhdr, payment_hdr, coins, ...) is encrypted under the bulk cipher. Digicash hasn't told us yet what bulk cipher they use, but let's assume for concreteness they use RC4. Now I'm an attacker -- I want to modify userhdr.userID -- and then the mint will accept the payment and deposit the coins into the wrong account. But this is just easy for an active attacker -- I just flip bits in the ciphertext! (Presumably I can guess fairly well what plaintext value is expected for the userhdr.userID field.) This is just a corollary of my Pet Peeve for protocol designers: Don't use encryption when you want message authentication; with encryption, you should only count on confidentiality! Ok, so you mention that maybe Digicash uses DES-CBC or somesuch instead of a stream cipher like RC4. I'll briefly note that while the attack isn't so trivial anymore, DES-CBC ciphertext is not tamper-proof -- again, encryption does not provide message authentication. Another nitpick from your friendly neighborhood techno-geek. I noticed that signatures (when used) don't cover the headers. Since the mint uses header information to make important decisions (e.g. the userhdr.userID field specifies who's account a deposit should go to), shouldn't this be signed, just as a matter of ordinary everyday paranoia? While I'm ranting, let me also remind you of a problem Ian discovered earlier through reverse-engineering: the payment & deposit messages aren't encrypted, and they send payee (e.g. shop) identity payer's and payee's banks payer's currency-of-choice amount of money transferred description of the product time of payment in the clear, accessible to any passive eavesdropper. With traffic analysis, if payers use the default TCP connection, all this information about them can be compiled. If I target a payer, I'll probably be able to record all his transactions (unless he's using remailers or pipenet). If I sit outside a small business, I can compile a dossier on its buying habits. Worse still, anonymity for the shop is worse with Digicash than with real cash. If I pay you real cash on a secluded street, you're fairly anonymous. If I pay you Digicash over the Internet, any passive eavesdropper could be recording your identy and the whole transaction. Blech. So Digicash's product does all sorts of neat crypto to provide you with anonymity from the bank, but doesn't do much to provide anonymity from eavesdroppers on the Internet. This is exactly backwards from how I'd prioritize -- I'll trust my bank to keep me private long before I'll trust messages sent in the clear over the Internet (on a virtual postcard) for all to see! Blech. So, what should Digicash be doing to remedy these problems? * always set up an encrypted, authenticated connection before sending any messages in the Digicash protocol. (Yes, this means shops will need to have certificates if you want to avoid a man-in-the-middle attack. So be it. Most online shops will be using SSL, and thus have a certificate anyhow. You can safely punt on the authentication between customer <-> shop if you're not worried about active attacks.) * add a big warning to the documentation: users should not use wildcards in payments (unless they know the dangers & are encrypting with e.g. PGP). * sign the header stuff too. * continue specifying the protocol at a deeper level, like you promised (and throw in source for security-critical modules too, eh? :-) - --- [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 iQBFAwUBMMYgtioZzwIn1bdtAQHx9QF+J6qWEqWcsaoVOUQ3i9qaVF8MgYdztCLg 9si9YDnjqPnFEsGTHYBjZXB8/TpOfiZe =cBGu -----END PGP SIGNATURE-----

1 0

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: NIST GAK export meeting, short version
by Bill Stewart 17 Dec '03

17 Dec '03

At 07:11 AM 12/6/95 -0400, pfarrell(a)netcom.com wrote: >They claimed it was needed so that they can serve a court order >that is SECRET. .... >The main area that they claimed was for FISA orders. Maybe this is just an artifact of Pat's wording, but this sounds like there may be classified court orders other than FISA? > Plus, since you have to be a US citizen to get a clearence, > how can there be approved foreign escrow agents? By deals with the foreign governments, presumably reciprocal. The US would allow export of software using the escrow keys for Banque du Commerce et Credit Internationale - Paris, if the bank and the French spooks signed an agreement for escrow access, and in return the US would probably agree to give the French access to some US-escrowed keys (with proper requests, of course.) >And the usual, why in hell would a competent spy use >crypto escrowed in the US? Competent spies appear to be a surprisingly small fraction of even government-employed espionage personnel, or maybe long-term espionage is just inherently difficult the Soviet Empire, Nazi Germany, and WWII Britain had all identified most of the spy rings operating against them. Philip Agee's article on how to identify the CIA agents in a US embassy may have surprised the CIA, but wouldn't have given any significant new information to the KGB. (They might have been surprised he'd _say_ it...) And amateurs and newcomers to the business aren't always that good. Also, maybe a spy would be using GAKed crypto to avoid attracting attention. Much of espionage, especially emerging economic espionage, primarily uses open-source information; there's nothing too secret about sending the latest SAIC want-ads from EE Times back home, but the CIA may learn what targets you're watching by watching enough of your traffic to guess at your filtering criteria. And sometimes you're just stuck on the Beltway and have to use your car phone to say you'll be a bit late dropping off the secret plans. #-- # 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: Secret Clearance (was: re: NIST GAK export meeting, sv)
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:00 PM 12/5/95 -0500, Pete Loshin <pete(a)loshin.com> wrote: >The point is, if you want to keep your organization's systems secure, >you need some mechanism to do so. Security clearance is one way; >banks and other financial institutions do other things (like finger prints, >background checks, etc.) ... >My big question is, do any of the companies providing Internet services, >or Internet software, or digital commerce services/software, employ >any of these security mechanisms on their employees? Few, if any, other than companies already in the military business; secret clearances are _expensive_, usually take a long time to get, and the military only gives them to people who need them. Normally, to get clearances for your employees, you need to have a security bureaucracy to also get clearance for handling classified material in your building, though perhaps they'd make other arrangements so the cleared escrow agent could take the master keys down to the local FBI office to unlock somebody's correspondence. Commercial companies are more likely to use bonding services to insure themselves against employee theft, though they also do things like talking to previous employers, and for sensitive positions some companies check criminal records. Many companies will run a TRW-or-equivalent credit check on applicants to see if there are major outstanding problems (though somehow the Mafia seldom reports bad gambling debts to TRW :-), and some companies pretend they're doing drug tests to check for people with expensive habits. #-- # 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