December 2003 - cypherpunks-legacy

Re: Mandatory ID in California?
by Duncan Frissell 17 Dec '03

17 Dec '03

At 08:45 AM 10/25/95 -0700, Ian Goldberg wrote: >"The officer, in accordance with police policy, arrested Burton >for refusing to properly identify himself." ><snip> > >That last sentence seemed ominous to me... This has been chatted about for years. Under California law, failure to identify yourself is a minor violation. They always dismiss the next day at your hearing. You don't have to carry ID, you just have to identify yourself (there's a difference). "my name Jose Jimenez." You still don't need ID unless you are operating a motor vehicle on public streets and roads (or maybe catching a plane). DCF "The average seasoned citizen pays a higher percentage of his income for medical expenses today than he did in 1964 before the passage of Medicaid."

4 4

Welcome to cypherpunks
by Majordomo＠toad.com 17 Dec '03

17 Dec '03

-- Welcome to the cypherpunks mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo(a)toad.com" with the following command in the body of your email message: unsubscribe cypherpunks cypherpunks(a)toad.com Here's the general information for the list you've subscribed to, in case you don't already have it: About cypherpunks ----------------- I. Administrivia (please read, boring though it may be) The cypherpunks list is a forum for discussing personal defenses for privacy in the digital domain. It is a high volume mailing list. If you don't know how to do something, like unsubscribe, send mail to majordomo(a)toad.com and the software robot which answers that address will send you back instructions on how to do what you want. If you don't know the majordomo syntax, an empty message to this address will get you a help file, as will a command 'help' in the body. Even with all this automated help, you may still encounter problems. If you get really stuck, please feel free to contact me directly at the address I use for mailing list management: cypherpunks-owner(a)toad.com Please use this address for all mailing list management issues. Hint: if you try to unsubscribe yourself from a different account than you signed up for, it likely won't work. Log back into your old account and try again. If you no longer have access to that account, mail me at the list management address above. For other questions, my list management address is not the best place, since I don't read it every day. To reach me otherwise, send mail to eric(a)remailer.net This address is appropriate for emergencies (and wanting to get off the list is never an emergency), such as the list continuously spewing articles. Please don't send me mail to my regular mailbox asking to be removed; I'll just send you back a form letter. Do not mail to the whole list asking to be removed. It's rude. The -request address is made exactly for this purpose. To post to the whole list, send mail to cypherpunks(a)toad.com If your mail bounces repeatedly, you will be removed from the list. Nothing personal, but I have to look at all the bounce messages. There is no digest version available. There is an announcements list which is moderated and has low volume. Announcements for physical cypherpunks meetings, new software and important developments will be posted there. Mail to cypherpunks-announce-request(a)toad.com if you want to be added or removed to the announce list. All announcements also go out to the full cypherpunks list, so there is no need to subscribe to both. II. About cypherpunks The cypherpunks list is not designed for beginners, although they are welcome. If you are totally new to crypto, please get and read the crypto FAQ referenced below. This document is a good introduction, although not short. Crypto is a subtle field and a good understanding will not come without some study. Please, as a courtesy to all, do some reading to make sure that your question is not already frequently asked. There are other forums to use on the subject of cryptography. The Usenet group sci.crypt deals with technical cryptography; cypherpunks deals with technical details but slants the discussion toward their social implications. The Usenet group talk.politics.crypto, as is says, is for political theorizing, and cypherpunks gets its share of that, but cypherpunks is all pro-crypto; the debates on this list are about how to best get crypto out there. The Usenet group alt.security.pgp is a pgp-specific group, and questions about pgp as such are likely better asked there than here. Ditto for alt.security.ripem. The cypherpunks list has its very own net.loon, a fellow named L. Detweiler. The history is too long for here, but he thinks that cypherpunks are evil incarnate. If you see a densely worded rant featuring characteristic words such as "medusa", "pseudospoofing", "treachery", "poison", or "black lies", it's probably him, no matter what the From: line says. The policy is to ignore these postings. Replies have never, ever, not even once resulted in anything constructive and usually create huge flamewars on the list. Please, please, don't feed the animals. III. Resources. A. The sci.crypt FAQ anonymous ftp to rtfm.mit.edu:pub/usenet-by-group/sci.crypt The cryptography FAQ is good online intro to crypto. Very much worth reading. Last I looked, it was in ten parts. B. cypherpunks ftp site anonymous ftp to ftp.csua.berkeley.edu:pub/cypherpunks This site contains code, information, rants, and other miscellany. There is a glossary there that all new members should download and read. Also recommended for all users are Hal Finney's instructions on how to use the anonymous remailer system; the remailer sources are there for the perl-literate. C. Bruce Schneier's _Applied Cryptography_, published by Wiley This is required reading for any serious technical cypherpunk. An excellent overview of the field, it describes many of the basic algorithms and protocols with their mathematical descriptions. Some of the stuff at the edges of the scope of the book is a little incomplete, so short descriptions in here should lead to library research for the latest papers, or to the list for the current thinking. All in all, a solid and valuable book. It's even got the cypherpunks-request address. IV. Famous last words My preferred email address for list maintenance topics only is hughes(a)toad.com. All other mail, including emergency mail, should go to hughes(a)ah.com, where I read mail much more regularly. Enjoy and deploy. Eric ----------------------------------------------------------------------------- Cypherpunks assume privacy is a good thing and wish there were more of it. Cypherpunks acknowledge that those who want privacy must create it for themselves and not expect governments, corporations, or other large, faceless organizations to grant them privacy out of beneficence. Cypherpunks know that people have been creating their own privacy for centuries with whispers, envelopes, closed doors, and couriers. Cypherpunks do not seek to prevent other people from speaking about their experiences or their opinions. The most important means to the defense of privacy is encryption. To encrypt is to indicate the desire for privacy. But to encrypt with weak cryptography is to indicate not too much desire for privacy. Cypherpunks hope that all people desiring privacy will learn how best to defend it. Cypherpunks are therefore devoted to cryptography. Cypherpunks wish to learn about it, to teach it, to implement it, and to make more of it. Cypherpunks know that cryptographic protocols make social structures. Cypherpunks know how to attack a system and how to defend it. Cypherpunks know just how hard it is to make good cryptosystems. Cypherpunks love to practice. They love to play with public key cryptography. They love to play with anonymous and pseudonymous mail forwarding and delivery. They love to play with DC-nets. They love to play with secure communications of all kinds. Cypherpunks write code. They know that someone has to write code to defend privacy, and since it's their privacy, they're going to write it. Cypherpunks publish their code so that their fellow cypherpunks may practice and play with it. Cypherpunks realize that security is not built in a day and are patient with incremental progress. Cypherpunks don't care if you don't like the software they write. Cypherpunks know that software can't be destroyed. Cypherpunks know that a widely dispersed system can't be shut down. Cypherpunks will make the networks safe for privacy. [Last updated Mon Feb 21 13:18:25 1994]

4 3

Transcript of Bernstein hearing is now available
by John Gilmore 17 Dec '03

17 Dec '03

We received the transcript of October 20's oral hearing from the court stenographer. It's up on the EFF Web site at: http://www.eff.org/pub/Legal/Cases/Bernstein_v_DoS/Legal/951020_hearing.tra… This is from Dan Bernstein's case, which is trying to get the crypto export laws invalidated as unconstitutional. This particular hearing is about the government's motion to throw the case out of court because the courts don't have jurisdiction to decide the issue. Some of it is deep legalese, and some of it is quite readable. There's still no news from the judge on what her decision is, or when she will decide. John Gilmore

3 2

If I WANNA I'M GONNA
by carolann＠censored.org 17 Dec '03

17 Dec '03

I see all the traffic analysis arguments. They are silly. If someone wants something, they will get it. Simple. The only question is how long it will take. Not if! Just how long! Love Always, Carol Anne ps Wanna argue with a loaded gun at your face? SEE! -- Member Internet Society - Certified BETSI Programmer - Webmistress *********************************************************************** Carol Anne Braddock (cab8) carolann(a)censored.org 206.42.112.96 My Homepage The Cyberdoc *********************************************************************** ------------------ PGP.ZIP Part [017/713] ------------------- M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M MF=O0H+*%(-S%&>S%+FS&<LS%3(Q&#W1"<]2%`H^;,]^1C$'HBN8PX$4SYAU^ MPGD<Q0ZLA0D+,`MCT!LA**4M[-JPAK9F?40!AJ,CW"'%DR#:'9?Q)3[%<DQ` ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/

1 0

Re: Keyed-MD5, and HTTP-NG
by baldwin 17 Dec '03

17 Dec '03

Perry, I wish that the field of cryptography was as well advanced as the field of Bridge Building. A modern Bridge Builder can design a bridge that is easy to construct and will in fact last for 100 years. Unfortunately, modern Cryptography is like Bridge Building in the late 1800s. Back then, it was possible to build bridges that did last for 100 years but lots of cities refused to pay the extra costs in materials, labor and time to make a solid bridge, and as a result the bridges did not last. To make it worse, there was no systematic teaching of the best practices, so often no one would realize that they had build and/or bought a weak bridge until the day that it fell apart. The sad result of the state of the art in Cryptography is that we end up with situations like the one you described where it takes months to get agreement among Cryptographers and then it turns out that one of the other choices would have been better. Not surprisingly, the other choices often run slower than the initial choice. However, there is little guarantee that the second choice will resist all new attacks. One of the reasons that the IPsec authenticator was analyzed was that it had been chosen as the IPsec authenticator. As soon as a large organization picks a new authenticator, the researchers will try their hand on breaking that one. In the field of Cryptographic Engineering, we just don't have a well tested construct for authenticators. If the IPsec group was run by scientists instead of engineers, then they would consider cryptographic constructs that have "provable" security properties (e.g., faking this authenticator is as hard as factoring a Blum integer (a composite number with two strong primes)). The downside of having this kind of provable security is that the packet processing time would be enormous. You would loose all the benefits of a T1 connection to the Internet in order to get provable security on your authenticator or encryptor. Speaking for myself, I am glad that the IETF is run by engineers. The vitriol you spewed is quite justified. People at RSA and IBM both agreed that the IPsec authenticator would resist all known attacks. In fact, a fully conforment IPsec implementation will still resist the new attack because IPsec requires that the all keys be changed every 2**32 packets. However, this new attack makes Cryptographers nervous. Perhaps it could be extended to work with only 2**40 chosen packets in which case there is a noticeable chance of it succeeding with only 2**32 packets. Only further research will tell. Currently, the only way to get the MD5 key is to feed in 2**60 chosen messages of various lengths. Of course, this is another good reason to use different keys for the MD5 authenticator and packet encryption. Wisely, IPsec requires different keys for the authenticator and the encryptor. I also understand your being upset about not hearing about this attack the moment it was published. Actually, as soon as RSA Labs confirmed the weakness we did call some of the editors of the IPsec specifications to let them know about it. The consensus was that this was not a show stopper. The IPsec protocols could be rolled out as is. Later, once a better authenticator had been developed and tested, it could be substituted for the existing one. One of the excellent features of the IPsec specification is that new algorithms can be substituted easily (modulo a "small matter of programming"). Perhaps your main complaint is that it took time for the attack to be confirmed by other researchers before the issue was brought to the IPsec authors. That is another effect of the current state of the art in Cryptography, and an effect of the normal academic process. It takes time to understand and confirm a weakness, and it is necessary to confirm weaknesses (researchers make mistakes in designing attacks just like they make mistakes in designing ciphers). That's the way things are in "cryptography today". I guess my conclusion is to say "Sorry". Several professional cryptographers gave it their best shot, and the authenticator turned out to be somewhat weaker than expected. --Bob ______________________________ Reply Separator _________________________________ Subject: Re: Keyed-MD5, and HTTP-NG Author: perry(a)piermont.com at INTERNET Date: 10/31/95 5:25 PM "baldwin" writes: > Simon, > There are a few different ways to add key material to MD5 to > make it suitable as a shared-secret authenticator function. Some of these > are less resistant to attacks than others. For example, the keyed MD5 > mechanism that is part of the current IPsec specifications can be > attacked using 2**60 chosen messages. Fortunately, the IPsec specs > also require that the shared MD5 key be changed every 2**32 messages, > so this attack is unlikely to succeed. Specifically, IPsec uses > MD5 as follows: X = MD5(key | keypad | Message), where "|" means > concatenation and the "keypad" pads out the key to 512 bits. > Basically, this function is the same as standard MD5 with a > different initialization vector for the compression operation > on the first block of the message. > RSA Labs recommends that a people use an authenticator like > X = MD5(key1, MD5(key2, Message)). This resists the chosen plaintext > attacks that were published at the crypto conference in Spring 1995. Pardon me. The amount of vitriol I am going to spew is probably difficult for people to understand because most folks around here weren't following the keyed MD5 discussions during the IPSEC work and have no idea of the sort of crap the professional cryptographic community put us through. We spent months, and months, and months, and months, getting advice from every cryptographer on the planet. Every conceivable combination of pads, multiple keys, keys before the text, after, before and after, etc., was discussed over and over and over again. Finally, the folks at RSA and IBM both agreed that Hugo's scheme, the one we were putting in to place, was the best possible one. (Thats the one with the padded key.) What the flying hell are you doing telling us now, and indeed not even telling the IPSEC community but instead mumbling on cypherpunks, that you guys were in possession of information BEFORE the entire discussion in midsummer that indicated that your own advice was wrong? Perry

2 1

Re: ecash remailer
by David K. Merriman 17 Dec '03

17 Dec '03

>> Wouldn't the ability to have the bank prove that the coins were 'cashed' >> make this all null and void? The only way this would work would be if >> Charlie is willing to completely forego cashing in the coins, *ever*. Should >> he cash them in later, Ed would seem to have grounds for suspicion/complain. > >In the scenario I suggested, Charlie never gets coins from anyone. He just >(falsely) claims that he was supposed to have received some from Alice. My test copy of the Ecash software logs what coins were spent - wouldn't something like that constitute evidence that any claim was made? Failing that, wouldn't Ed be able to tell the bank 'these coins were misplaced/lost/damaged. please cancel them', and then re-issue any payment due? *If* Alice really paid Ed, then he would have evidence of such, whether Charlie's claim is valid or not. With the cash in hand, Ed should reasonably be able to re-issue them, just as one could put a stop-payment on a check and re-issue. Or am I completely missing something here? (always a possibility, I suppose :-) Dave This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

1 0

Re: Keyed-MD5, and HTTP-NG
by baldwin 17 Dec '03

17 Dec '03

Perry, I personally spoke to Bill Simpson about this problem. I should have given you a phone call or email in addition to speaking to Bill. In my opinion this problem does not at all reflect on your skills or reputation. What it signifies to me is the poor state of cryptographic engineering. If anything, it points out the wisdom of the IPsec designers in requiring that key material have a limited lifetime. A wise engineering choice like this protects the system against many different kinds of attacks. Of course, the protocol implementors often omit "details" like key lifetime limits. In fact, 17 years ago when I wrote a TCP/IP stack for the Xerox Alto I left out several "details", which of course caused lots of problems when I did interoperability testing with a mainframe (Multics). --Bob ______________________________ Reply Separator _________________________________ On 11/1/95 10:20 AM, perry(a)piermont.com worte: > There were two names on the MD5 document -- mine and Bill > Simpson's. Bill didn't tell me that he was called (I suspect he > would have), and I wasn't called, either. We were the only two > editors of that portion of the specification. > > Given that my name was on that document and that I made a large effort to > try to make sure that people examined the algorithms and thought they were > good, and that I have some of my reputation tied to that document, I am > rather unhappy at the fact that I only find out third hand about what people > in the field have determined about our selected algorithm.

4 3

Hit-and-Run Anonymous Posts (Re: "Dr." Fred)
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 10:22 AM 11/1/95, Dr. Frederick B. Cohen wrote: (quoting an anonymous poster) >> The difference, of course, is that its almost impossible >> to have sympathy for Dr. Fred. His hustle is for a hell >> of a lot more than subsistence. He was also never actually >> a master of his field, a fact that becomes increasingly >> obvious as our exposure to him goes on. Now he's reduced >> himself to trying to collect someone else's winnings. > >Sour grapes, and from an anonymous poster too. Oooo - I'm insulted. > >I have been thinking about the issues of anonymity for some time, and I >have been convinced for some time that you can't have both integrity and >anonymity. I thought there might be ways to accomplish this, but the >cypherpunks have convinced me it isn't true. Show some integrity and >tell us who you are. I've also found that anonymous persons are usually the most prone to hit-and-run attacks and flames. I usually only briefly scan anonymous posts and then delete them. Some people hide behind anonymity to launch scurrilous attacks. Best to just ignore them, in my opinion. Exceptions are the cases when an anonymous source has something "sensitive" to contribute, such as the release of the putative MD4 code, and the like. And there have of course been thoughtful anonymous essays. Anonymity is under some assault today. I think it important not to throw out the very basic advantages of allowing anonymity just because some abuse occurs. (The issue is not that "allowing" it is good, but that "banning" it would require drastic and draconian enforcement measures.) Pseudonyms are another matter entirely. Some are classy (Pr0duct Cypher, Black Unicorn, Lucky Green), some are oafish (S Boxx), some are ephemeral. Persistence of the identity, as when backed by digital signatures, is important. (Though not essential, yet.) --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."

2 1

SCO Unix Crontab Problems-Need Help
by ncra＠ix.netcom.com 17 Dec '03

17 Dec '03

I have a bourne shell that I need to execute in SCO unix 4.0 from a crontab. The script is a communications upload using ecu. The script runs just fine in terminal mode, but when it is executed in cron, it is not able to gain access of the modem for some reason. Q: Is there something special that needs to be added to the crontab line in order to allow for tty access. Please let me know if you have any suggestions.

1 0

Re: ecash remailer
by Bill Stewart 17 Dec '03

17 Dec '03

At 01:20 PM 11/1/95 -0500, Michael Froomkin <froomkin(a)law.miami.edu> wrote: >I thought a property of Chaumian DigiCash was that a coin *had* to go back >to the bank before it could be spent again. No. The basic Chaum Digicash method looks like this: 1) Alice creates a number of a recognizable form (Chaum's 1985 CACM paper uses n1n2n3...n64n1n2n3....n64, i.e. a 64-bit number concatenated with itself). 2) Alice blinds the number and sends it to the bank (along with some request for withdrawing money from her account or payment in other coin or whatever.) 3) The bank signs the number and sends it back. 4) Alice unblinds the coin; now it's good, recognizably signed, and untraceable. 5a) Alice gives the coin to Bob, who deposits it; the bank records the coin number, and in case of double-spending, the first person to the bank wins. This is useful for on-line transactions, or off-line where everyone trusts each other. OR 5b) Alice gives the coin to Bob using a complicated cut&choose protocol that doesn't give away her identity if it's only used once, but if she also gives the same coin to Carol with the same protocol, Bob and Carol can identify Alice with probability 1 - 1/2**n, for some adequately large n. This is more work, but you can use it for off-line transactions where you don't trust Alice not to double-spend. The protocol doesn't say what to do to Alice if you catch her cheating; depending on the environment you can debit her account or sue her etc. 6) Bob now has a number, signed by the Bank of Foo, which he can either give to them to deposit or get cash or use for highway toll (if Foo is really the highway company) or give to somebody else to spend (which is a little messy in the cut&choose method.) >Logically, I can see at least four possibilities: >1) payee data is encoded onto the coin at time of payment, making it >impossible for Carol to bank the coin. I see no evidence of this in the >docs at the Digicash site, but I just rechecked quickly and may have >missed it. The basic protocol doesn't say anything about what a valid coin looks like; you could use the example in Chaum's paper or a long string followed by a checksum or whatever. You _could_ put the payee's name account number in the string as the 64-bit "random" number, or even put both payer and payee. The bank could insist on that sort of thing if they wanted. If I remember right, the version in the Digicash trial left you the choice of filling in a specific payee or using "@" for bearer-payable coins. >2) No payee data as such is encoded on the coin but it is marked "spent" >to prevent multiple uses by payee to the detriment of payor. The bank marks the coin spent upon deposit. >3) the Digicash software only allows you to send a "spent" coin to the >bank. You have to hack the software to send the coin to Carol (do you >have to break your own key?). I don't know if their merchant-client software lets you do this or not, but it's just a matter of implementation, not protocol. >4) nothing in the DigiCash software or protocol prevents you from sending >a coin to Carol so long as you trust Carol not to get you in trouble by >misusing the coin in some way. That's why Chaum is interested in >hardware based agents that would keep you from respending coins you receive. Your problem isn't trusting Carol not to get you in trouble, it's trusting Alice not to spend the coin again. Hardware-based agents are interesting because they make it easier to enforce double-spending prevention in off-line systems, and to offer better anonymity because you've got more trust that the person didn't double-spend. Stefan Brands has done a lot of work on this. In on-line systems you can check whether a coin's been spent already by depositing it - the problem is that on-line systems aren't always convenient for many applications (e.g. newspaper machines), and the costs of communication for an on-line system may be higher than the cost of a sufficiently smart smart-card. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

5 5