December 2003 - cypherpunks-legacy

Re: Sen. Leahy's "impeccable cyberspace credentials"
by jim bell 17 Dec '03

17 Dec '03

At 09:50 AM 8/26/96 -0700, Declan McCullagh wrote: >---------- Forwarded message ---------- >Date: Mon, 26 Aug 1996 12:23:57 -0400 >From: Jonah Seiger <jseiger(a)cdt.org> >To: Declan McCullagh <declan(a)eff.org> >Cc: shabbir(a)vtw.org, fight-censorship(a)vorlon.mit.edu, brock(a)well.com, > telstar(a)wired.com >Subject: Re: INFO: Democratic convention chats online! Be there! (8/25/96) >Declan: >In a world where we have very few real friends, I simply don't understand >what you are trying to accomplish. It's fine (and healthy) to raise >concerns about the particular positions a member of Congress takes (hell, I >don't agree with everything Leahy does), but to simply dismiss Leahy as a >'no friend of the Net' is naive and counterproductive. > >Look at the record. Leahy is hands down the strongest supporter of the Net >in Congress. Period. No other Member (including our small but growing >handful of other friends like Burns, White, Wyden, Cox, Eshoo, etc) has >been a more forceful or consistent advocate for your causes for as long as >Leahy has. What exactly do you want? Perhaps we should elect you to >Congress and see how well you can do. Leahy's crypto bill sucked, bigtime. The portion of the bill criminalizing the use of encryption that had the effect of thwarting a government investigation is classic, "foot in the door" creeping government manipulation. I was particularly disgusted to notice that a number of the traditional net-freedom organizations rushed to announce that they were in favor of that bill, without even a few days of analysis, and did not retract or even restrict that support when a more careful study (specifically, that of Peter Junger) showed how seriously flawed it was. Indeed, I never saw another analysis that purported to defend Leahy's bill, despite the fact that it would have been the responsibility of any organization which claimed support of it to prepare one. I believe that it is particularly suspicious that these bills come into existance without even cursory "vetting" on the Internet. Both the Leahy bill and even the Burns crypto bill popped into public view without any indication of how they were written, or any public input on their intent and scope. Perhaps this "take it or leave it" practice is old hat to politicians, but frankly I'm disgusted at politicians' presumption that they can prepare a law with no identifiable input from the public. I am similarly disgusted at any organization (even if, ostensibly, acting in support of "net freedom") that assisted in the development of the Leahy crypto bill (and to some extent, even the Burns bill) because they clearly failed to solicit the kind of public input that such bills should automatically get. And in a sense, "the Net" doesn't NEED "strong supporters": what we need are politicians who are willing to LEAVE US ALONE! It should come as no surprise that the call you frequently see among net-freedom- supporters for new legislation is that which repeals existing restrictive laws, such as ITAR and censorship laws. Jim Bell jimbell(a)pacifier.com

4 3

Re:
by Sean Sutherland 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- To: cypherpunks(a)toad.com Date: Sat Aug 24 19:00:18 1996 > Does anybody know what I can get for generating the credit card > numbers? > And they say there's hope for the youth of America. - --- Sean Sutherland | GCS/C d- s+:+ a--- C+++ V--- P L E- W++ N++ K w o PGP Key ID: E43E6489 | O-(++) M-- V PS+ PE++ Y PGP++ t--- 5+++ X++ R b++ Vote Harry Browne '96 | DI+ D+ G e- h! !r y -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Key: finger or email w/ 'send key' in subj. http://www2.interconnect.net/maverick iQEVAwUBMh+Xk1ZoKRrkPmSJAQGj+Af8C2P7D+3ZZ4f8h76+6UfdgqEubOO0mkWj 2DazxBMuY1b1sx1G6gaIGR9Tc11vIcoCY3pmBzhBW7Nc6do8gfOK8Bkkon6Pck1g 61tCFH6qPb2bSH0HnbzjrXJhRD6dFv9ondTtyZgiFIeMuVDDIx4+ZKvelL6BHk8x o6sLdY4Y/Nmnvz9HXrBj0DaYR8pcY96+dexwj5luvcgVkdsDjghWXZy/mHkeDXMI bvOuUOMLQyExS0Ts4D5K4/XfIhP0HUiPfdeL9oxONcLUYznywxAUevBMfHceqvsS qFnxcDcyHa8ynHLRH9Qg0t5QuKVUvTpZh3YjPXCF9QKwvIFbZukHKw== =e03n -----END PGP SIGNATURE-----

2 1

Moscowchannel.com hack
by Joel McNamara 17 Dec '03

17 Dec '03

Not really crypto, but related to the DOJ hack in a way. Moscow Channel is a pretty slick, Russian news/commentary page. Their Web site was hacked and altered by someone who didn't seem to like Russians all that well. See: http://www.moscowchannel.com/ While not as elaborate as the DOJ hack, it's interesting that Web page vandalism is starting to turn into a unique form of protest and social commentary. As Web sites with security holes increase, my guess is vandalism will increase incrementally. Both in terms of random graffiti, and targeted attacks. Just a matter of time before some builds a dedicated Satan type tool that scans for HTTP server holes or messed up file permissions to make locating potential victims easy.

5 7

Re: DON'T Nuke Singapore Back into the Stone Age
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:35 AM 8/31/96, Arun Mehta wrote: >There are two sides to this: after all, it is the Singaporeans who finally >have to sort out this problem with their government, and denying them >the Usenet platform for discussion would only hinder that process. The point is to make clear to them that the Usenet and similar Web sites are global in nature, not subject to censorship without a very high local cost. If discussions of Lee Kwan Yew's dynasty are considered illegal, then Singaporans will have to choose not to carry the various newsgroups into which *I* post such messages! (This was done by many of us during the Karla Homulka and Teale trial in Canada a couple of years ago: Canada imposed press restrictions on discussion of the trial and the grisly evidence...and then was chagrinned to find that the global Net did not adhere to their notions of what should and could be discussed. They even seized copies of "Wired" at the border, very much akin to Singapore's stone age policies.) >Then again, inappropriate postings are the bane of the Internet: the consensus >on which the Net functions relies heavily on people not posting >inappropriately. This works imperfectly, as all long-time surfers of the Usenet will attest! And _never_ has it involved determinations of "inappropriate" by _governments_! Our point in protesting Singapore's actions (and Germany's, France's, America's, India's, etc., in other cases) is to technologically subvert their notions that their politicians can determine what the Net, Web, and Usenet carry. To be blunt, if Singapore wants to stop me from discussing the dictator Yew and his feeble son, they can't. Except by pulling the plugs on forums in which my posts are carried. I consider this a Good Thing (that politicians in Country A generally have no power to tell citizen-units in Country B what they can say and what they can't). The point of being sometimes "impolite" (*) is to "force their hand." (* I find it Orwellian that being "polite" is taken to mean not saying anything controversial. It was impolite for Salman Rushdie to write "The Satanic Verses," is was impolite for people to mention Karla Homulka in talk.politics.canada, it was impolite to point out that the prime minister of India drinks a glass of his own urine every day, it was impolite to refer to Bill Clinton's dalliances with Paula Jones, and so on. In a free society, all things are discussable. That various countries want to make the Net less free is not something we should support, even if it is more "polite" to accede to the wishes of their dictators, secret policemen, demagogues, preachers, and henchmen.) --Tim May -- [This Bible excerpt awaiting review under the U.S. Communications Decency Act of 1996] And then Lot said, "I have some mighty fine young virgin daughters. Why don't you boys just come on in and fuck them right here in my house - I'll just watch!"....Later, up in the mountains, the younger daughter said: "Dad's getting old. I say we should fuck him before he's too old to fuck." So the two daughters got him drunk and screwed him all that night. Sure enough, Dad got them pregnant, and had an incestuous bastard son....Onan really hated the idea of doing his brother's wife and getting her pregnant while his brother got all the credit, so he pulled out before he came....Remember, it's not a good idea to have sex with your sister, your brother, your parents, your pet dog, or the farm animals, unless of course God tells you to. [excerpts from the Old Testament, Modern Vernacular Translation, TCM, 1996]

10 12

encryption
by patrickbc＠juno.com 17 Dec '03

17 Dec '03

Will pay $5.00 for a good encryption program. Write to patrickbc(a)juno.com

1 0

RE: Encryption
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 8:52 PM 8/30/96, Benjamin Suto wrote: >I'm probably the last person who could mention something intelligible >here, but assuming this encryption algorithm works, and Joe wants to give >Jane a file, how would he tell her how to decrypt it? There are two parts to this: the algorithm and the key. For a strong cipher, the algorithm can be told to Jane...there is no real security in "security through obscurity." The remaining part is the _key_. It can be communicated in person, prior to sending the message (or after, though this is of course a less interesting situation). Or by a trusted courier, again prior to the encrypted communication. (A common thought error newcomers make is to ask "If the key can be communicated securely, why is encryption needed?" Think of military communications--the keys are established before a mission, then units can communicate securely, even over insecure radio channels.) Public key cryptography allows Joe and Jane to communicate without any exchange of private key material. Joe encrypts a message to Jane's public key, then sends it by some channel. Jane can decrypt it, using her private key. >If he found a "secure medium" to give her the passcode under, wouldn't >encrypting it be useless since he could just use that secure medium to >send the original file? As I said, think of _time value_. It is often necessary to exchange key material (or get public keys in advance of a communication) before a message sending is needed. Also, key materials may be exchanged via reasonably-secure channels, such as FedEx delivery, and then the Internet may be used for actual messages. While FedEx may be vulnerable to interception in certain cases, clearly this is an improvement over using no encryption. --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, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Real-time key server
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

At 04:30 PM 8/27/96 DST, "Osborne, Rick" <OSBORRI(a)msmail.northgrum.com> wrote: >In my research into keyservers, I find that none of them are realtime. > Sure, there are CGI interfaces to them, but that's not what I mean. I was >hoping for something along the line of a Finger or SMTP protocol, such that >a client connects to a host (say, keyserv.northgrum.com) on a certain port >(say, 5397) and goes through a realtime version of what is accomplished via >email. [...] >Why? Because: >1. I do not want to reinvent the wheel. >2. I would like to conform to existing standards. There are at least three shapes of wheel readily available. Some of the keyservers have had finger interfaces; there was one on wasabi.io.com for a while, though it may be inactive. John Perry may know where to find source code for it? Assuming you want PGP keys delivered in ASCII format, finger protocol should work just fine - you could easily enough hack your own fingerd server to live on the fingerd port, which gets PGP key files from a directory or database instead of from users' home directories, and run it on pgp.northgrum.com or whatever. You could even hack the existing finger code from {Free,Net}BSD, making sure to clean up any remaining sprintf()s and {*}get()s. Alternatively, a CGI query _is_ an easy way to do it, and there's existing code on the MIT keyserver that's blazingly fast. John Gilmore's SWAN project is using a DNS-based PGP key server; check out http://www.cygnus.com/~gnu/swan.html for more details. >Okay, I was told to not post to the list until I'd: >1. Lurked for a month, >2. Figured out who Detweiler was, >3. Found out about BlackNet and DC Nets, >4. Learned of at least three of David Chaum's innovations. >And at that point "[I] may be ready to post [my] first comments." > >Well, dammit, I can't wait that long. I need help now. I've only been on >for 2 weeks, I have no clue who Detweiler is (other than the >welcome message I haven't heard two words about him/her/it), and I know >enough to sound stupid about the other stuff. But if you still think I'm >worthy of listeneing to, then read on. Three out of four ain't bad, and Detweiler's been using his alias on the list for a couple of years and acting quite civilized :-) Some good reading sources are Bruce Schneier's book "Applied Cryptography" and Tim May's "Cyphernomicon" piece which is on the web somewhere. Also, asking for pointers to existing work does categorize you with the clueful minority..... # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> Reassign Authority!

1 0

PGP Comments Considered Occasionally Harmful Re: Pronto making a comment
by stewarts＠ix.netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- To cypherpunks, Re: mbabcock and Jim Ray's discussion. >> How did you get Pronto to do a comment? > >I added a "comment=" in my config.txt ;) ... the old fashionned way. ... >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3i >Charset: ascii >Comment: http://www.cyberbeach.net/~mbabcock/PGP/ Note that the comment makes traffic analysis much easier. Sure, you can send your mail through five different remailers, but if each layer of PGP has your home page URL or some other distinctive Comment:, it's traceable. -----BEGIN PGP SIGNATURE----- Version: 2.7.1 Comment: PGP available outside U.S.A. at ftp.ox.ac.uk iQBVAwUBMif6ZvthU5e7emAFAQHh2AH/R4KY4MPQBjF2XCeeFCY5XPVQTePvPwT6 5MAAzyTL/8RwU0Ul7G7rQgeb/08CxqetC0Ry22AhMV8uEV6DgTbcLg== =4Ttw -----END PGP SIGNATURE----- # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> Reassign Authority!

1 0

FWD: Re: Tiger?
by Bill Stewart 17 Dec '03

17 Dec '03

Bruce Schneier wrote in sci.crypt : > > In article <505bms$2m1(a)kadri.ut.ee>, sander(a)haldjas.folklore.ee (Sander > Vesik) wrote: > > > Bruce Schneier (schneier(a)counterpane.com) wrote: > > : Tiger is a one-way hash function designed by Eli Biham and Ross Anderson. > > : It is optimized for a 64-bit chip (DEC Alpha). While interesting, Tiger > > : is very new, completely unanalyzed (except by the authors), and hence > > : still suspect. On the other hand, it's lightning fast on 64-bit machines. > > > > : Wired is displaying typical uneducated hype in its mention. I recommend > > : that everyone look at Tiger, but that no one use it yet. > > > > It is round 2.3 times faster than MD5 on my Pentium - so the part about > > high speed on the 32bit chips also seems to hold. > > It is certainly fast, and it is definitely not your typical snake oil. > It's just a mistake > to start using an algorithm immediately after it is published. > > Bruce > > ************************************************************************** > * Bruce Schneier APPLIED CRYPTOGRAPHY, 2nd EDITION is > * Counterpane Systems available. For info on a 15% > * schneier(a)counterpane.com discount offer, send me e-mail. > * > * For Blowfish C code, see ftp.ox.ac.uk:/pub/crypto/misc/blowfish.c.gz > ************************************************************************** -- # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # Dispel Authority!

1 0

IDEA and timing attacks
by Bill Stewart 17 Dec '03

17 Dec '03

John Kelsey <jmkelsey(a)delphi.com> wrote in sci.crypt > > -----BEGIN PGP SIGNED MESSAGE----- > > [ To: sci.crypt ## Date: 08/24/96 03:11 am ## > Subject: IDEA and Timing Attacks ] > > I'm still kind-of recovering from this year's Crypto conference, but > I told several people I would post this. At the rump session this > year, I presented an arguably practical timing attack on many > implementations of IDEA. There are actually two attacks available, > but one requires extremely fine timing results. After I gave the > presentation, Willi Meier told me he had independently found the > same results, and had implemented the full attack (which I hadn't > yet done). > > There are two different attacks. The most practical is an > adaptive chosen-plaintext attack, which requires about 5*n*2^{16} > chosen plaintexts (read ``five n times two to the sixteenth''), > where the parameter n depends on the precision of timings available > and the timing variability of the implementation. The second attack > is ciphertext-only, but requires timing measurements precise enough > to detect the difference between a single multiply of a zero vs. > nonzero value. It requires about 5*n*2^{16} values, as well. > > The basic idea behind the attack is as follows: in many > implementations, a zero input into the multiply operation is handled > by an if statement, and so does not cause a multiply instruction to > actually be executed. The result on a 486 is that it is > significantly faster to multiply by a zero rather than a nonzero > value. This timing difference gives us a really nice way to learn > information about the internal values of the cipher. > > This presentation is necessarily not very good, since I can't embed > a diagram here. If you have a copy of _Applied Cryptography_, then > turn to the section on IDEA (page 321 in the hardback version of the > second edition). The diagram shows one round of IDEA, and then > (after the ellipses) the output transformation. > > The chosen plaintext attack works as follows: > > 1. Build a run of n*2^{16} chosen plaintexts, by choosing a > single value for X_1, and choosing n of each possible value for X_3, > with X_2 and X_4 taking on values at random. Time the encryption of > each batch of n plaintexts with the same X_3 value. > > 2. Choose a new value for X_1, and then build another run of > chosen plaintexts exactly as above. > > 3. For each of these two runs, if the value of Z_5 is not zero, > there should be a different value for X_3 that gives the lowest > encryption time. (These are the values that force the input to the > multiply with Z_5 to be zero.) Call these X_3 and X_3'. This gives > us two equations in two unknowns, and we can solve for it with a > 32-bit brute-force search. (There may be faster ways, as well.) > > (X_1 (*) Z_1) = (X_3 + Z_3) > (X_1'(*) Z_1) = (X_3'+ Z_3) > > We now have recovered Z_1 and Z_3. > > 4. Let's call the input to the multiply with Z_5 A. We can use > knowledge of Z_1 and Z_3 to force A to keep the same value. We then > choose three new runs of chosen plaintexts, each containing 2^{16} > batches of n plaintexts apiece. Each of these ensures that A and > X_2 are kept constant, so that we wind up three difference values > for A, X_2 and X_4 which correspond to zero inputs into the multiply > with Z_6. This means that we wind up with three equations in three > unknowns. > > (A (*) Z_5) + ((Z_2 + X_2 ) XOR (Z_4 (*) X_4 )) = 0 > (A' (*) Z_5) + ((Z_2 + X_2' ) XOR (Z_4 (*) X_4' )) = 0 > (A''(*) Z_5) + ((Z_2 + X_2'') XOR (Z_4 (*) X_4'')) = 0. > > This can be solved with a 48-bit brute force search (there are > probably faster ways). We now have 80 bits of IDEA's key, and can > brute-force search the remaining 48 bits. > > Note that this is actually an adaptive chosen-plaintext attack as > described. I'm pretty sure this can be turned into a proper > chosen-plaintext attack with some work, and I'll probably be hacking > on this in the next few weeks, as time allows. > > The ciphertext only attack is simpler in some ways. The first 32 > bits are extremely easy to recover--find the average time to encrypt > blocks with each value in their first and last 16 bits, and then > solve for the subkey values that would be necessary for those > multiplies to have zeros as their inputs. Next, we look for a > correlation between low encryption times and the values for Z_3 in > the output transformation that would result in zero inputs into the > previous round's MA box multiply. Finally, we attack the second > multiply in that MA box, using all four output values. The > approximate computational difficulty is 2^{48}, as before. > > There are other timing attacks on IDEA. We gave one in our paper at > Crypto this year (the one on related-key cryptanalysis of several > ciphers, by Bruce Schneier, David Wagner, and me), and the > related-key timing attack is where I got the idea to try a timing > attack on the whole cipher. > > All timing attacks are implementation-dependent to some extent. On > a Pentium, I suspect the timing attack will be considerably harder. > (One person I discussed the attack with said he thought it would > take longer to do the conditional branch for the if statement than > to do the multiply, so we might have zero multiplies taking more > rather than less time.) > > Most applications aren't really susceptible to timing attacks, > because of the way they're used. In addition, chosen-plaintext > attacks on block ciphers are pretty nicely thwarted by using CBC or > CFB modes. It is probably also possible to implement IDEA so that > it executes in constant time. I should point out that it is *NOT* > enough either to add random delays (which fall out if you add more > samples), nor to just get rid of the big timing difference with zero > inputs (though that will make timing attacks somewhat more > difficult). As long as internal (secret) information is being > leaked by timing, the cipher is probably vulnerable to some kind of > timing attack. > > --John Kelsey, jmkelsey(a)delphi.com / kelsey(a)counterpane.com > PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQCVAwUBMh7GKEHx57Ag8goBAQEqGQQApXRQUMWz3gpJIwGrLbVhcgcpSMXyrq0g > iTi2qjH7dJjmWugpLnbm18XHzOPZMKizdZ/gin1O3Rk89dXfqK4sIICwY3QmkwFR > ZQ2My4mTUn27ibjAjZTDuvxLXnqqoOFRrMUTQGIlMTCZdBooSWrif+pTLQbIsoPr > saHlDl2bWts= > =tWIq > -----END PGP SIGNATURE-----

1 0