December 2003 - cypherpunks-legacy

SSL challenge?
by Peter Trei 17 Dec '03

17 Dec '03

Where does the effort to bruteforce SSL stand? I've got a bunch of P5/90s ready and waiting. Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation trei(a)process.com

3 2

Re: NRC panel wants questions for Law Enforcement on crypto policy
by Michael Froomkin 17 Dec '03

17 Dec '03

ask them if their policy allows them to purport to run an anonymous remailer, e.g. as part of a sting operation. In message <9507261951.AA23210(a)toad.com> John Gilmore writes: > I collated all the questions into a large ungainly message and sent it > to Herb Lin. He has been after me to go back over it and make a more > useful set of questions, which I haven't done yet. He says they are > meeting with the FBI in September and want to get questions to them in > August (incorporating our ideas). I've promised him I will get him the > formatted list of questions by the end of next week. > > John > -- Michael Froomkin until Aug 6: michael(a)umlaw.demon.co.uk U.Miami School of Law London, England mfroomki(a)umiami.ir.miami.edu <-- this will still find me PO Box 248087 Coral Gables, FL 33124-8087 "Rain in parts, then dry" --BBC See http://www-swiss.ai.mit.edu/6095/articles/froomkin-metaphor/text.html

1 0

Crypto: ride from SF on Saturday
by Bruce Schneier 17 Dec '03

17 Dec '03

Is anyone driving from the SF area to Crypto (in Santa Barbara) on Saturday? If so, I would like a ride. Bruce ************************************************************************** * Bruce Schneier * Counterpane Systems For a good prime, call 391581 * 2^216193 - 1 * schneier(a)counterpane.com **************************************************************************

1 0

"Only on the Cypherpunks list..."
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

At 10:00 PM 7/25/95, Nathaniel Borenstein wrote: >Well, only on the cypherpunks list would you be likely to find general >agreement that PGP'ed credit card numbers are "easier" than First >Virtual. Many thousands of extremely naive net citizens are now happy >FV customers, and I seriously doubt that most of them could master PGP >without a full-day tutorial. (We're not talking about rocket scientists >here, folks.) A lot of truth here...sometimes the perfect is the enemy of the good. After all, only on the Cypherpunks list would you be likely to find general agreement that setting up a separate Intel box running Linux so one can create a suitable mail client is the preferred way to do secure e-mail? (Smileys for the :=)-impaired...I have nothing against Linux, and even browsed the new O'Reilly book recently. But I'm _still_ glad I'm "just a Mac user.") I have no idea what First Virtual's current or future business plans are, but I do expect more solid encryption, a la PGP or "real" RSA (licensed), will be coming soon. I assume FV is planning for this likely development. --Tim May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)sensemedia.net | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

4 5

Re: Full text of David Chaum's Congressional speech
by Rev. Mark Grant 17 Dec '03

17 Dec '03

On Thu, 27 Jul 1995, Marcel van der Peijl wrote: > Ecash itself is less > prone to abuse than paper bank notes, because privacy is "one-way," > which means that an extortionist, a seller on a black-market, or the > acceptor of a bribe is forever vulnerable to being irrefutably > incriminated by the party that paid them. Now, I'm not sure of this, but as far as I can see, if I was a blackmailer wanting to receive an untraceable payment I could do the following : I create my ecash serial number/hash I blind it with a random number I send it to the payer Payer blinds it again and sends it to the bank Bank signs it and returns it Payer removes their blinding and returns the result to me I remove my blinding and send it to the bank for payment with no chance of being traced. Will this work ? Mark

1 0

Re: Banks and Crypto
by Duncan Frissell 17 Dec '03

17 Dec '03

At 11:29 PM 7/26/95 -0400, Robert A. Rosenberg wrote: >Is there ANY reason why you did not just paste the text of this file into >your message? Also, if you are going to attach files in lieu of writing >messages, it might be useful to mention what word processor was used to >create the file so it can be read. In this case, what format is your file >in? My copy of that inferior word processor Word for Windows 6.0 tells me it is Wordperfect for DOS 5.1. DCF "The Market is X the Unknown, The Blob, and Blue Goo."

1 0

Encrypting block driver for Linux...need some advice
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- All, I dropped off the face of the earth for a few months while fighting a particularly *nasty* divorce, and to nurse my wounds, I immersed myself in writing cypto-code :) What I've come up with is a loadable module block device driver for Linux that implements transparent encryption/decryption (is there a generic word that means both, like 'cryption' or some such?). The way it works is by 'attaching' a filespec to the block driver, and translating block requests into read/write requests at the appropriate offset in the file. During the read or write, the data is transformed with either DES or 3DES (RSAREF implementation). The key is an MD5 hashed passphrase entered by the user when attaching the filespec. The key is not stored anywhere, and there is no hidden structure to the ciphertext (such as a header block.) The filespec can represent pretty much anything--another block device such as a hard drive partition or floppy drive, a regular file, a remote NFS exported file, CDROM, whatever. If the file is remote, only ciphertext is transmitted on the wire. This part is working rather well at this point (as long as everything is done as root), which brings me to the crux of my post. Being a Unix programming novice (lots of C experience on DOS/Windows), I'm pretty clueless when it comes to Unix level security issues. I need to define and implement the appropriate behavior of the device when dealing with access to the data by different users. Ideally, I want something infinitely flexible and configurable--why program in policy?--so that the user/admin can deal with a variety of threat models. Another, more crypto related question--how to deal with IV's? Right now, I'm using 512 byte sectors with CBC. For each sector, the IV is the sector number. This frustrates the known plaintext attack issue, but I'm not sure if such a simple scheme is really effective. Probably not. Then there is a whole host of issues relating to cryptographically hygienic programming practices...of which I am also pretty ignorant (especially on Unix.) I guess you could say the software is at the "proof of concept" stage, and lacks all sorts of desirable features. But it works (with many bugs I'm sure)...and I have to give credit to the Linux effort: so far I've done this with nothing but the kernel source and the kernel hackers guide as a reference. I took a look at doing this with Windows 95 and didn't even know where to start. (No, I'm not bashing Windows--I love Win95, use it all day at the office and get loads of work done with it--but Linux kernel hacking is much more fun. An ideal world would have the Win95 UI/Plug & Play stuff coded on top of a Unix kernel :) In any case, suggestions, criticism, and comments are welcome. The software will eventually be GPL licensed when it is a bit more mature. == Johnathan Corgan "For the first time in history, it is possible to jcorgan(a)aeinet.com have absolute privacy over arbitrary distances." PGP Key Fingerprint: 4F 28 69 B8 76 2E 42 3E 8B 4C 12 BB 3A 43 D4 07 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMBaCnU1Diok8GKihAQGyoQP+JAYyukotfejK84bm8olDs1GMd6zlwuXc S+91DwrPRb8pyciEC6lIoLNS3coMgPdGTEksNNJMbuIXupJNnXnSum9XrPkMzEkG gL/x6n6v4Jzm9B9IyvIV2R1UrIK893EGQbPKTIgGNNsvORJ/NB8nkoMfZalVlNnD Hl3z3vaYgtU= =grpJ -----END PGP SIGNATURE-----

2 2

Re: RC4
by rross＠sci.dixie.edu 17 Dec '03

17 Dec '03

>From: Alex Tang <altitude(a)umich.edu> >> I talked with RSA yesterday specifically about free servers and RC4. >> They just said that they would need a business plan for the >> server product. When i said that the product would be free, they started >> talking in circles about how everyone who uses RC4 needed a license (but i >> was asking about the licenses...) I asked flat out "how much would a >> license for RC4 cost for a free server product". They only reponded with >> "Very Expensive", and then went on about a business plan. > >Ask them about the free version of RC4 which is circulating. If they say >it is patented ask them for the patent number. Ask them why you should >pay them big bucks if you can get it for free. Here's their reply to a similar correspondence: >The RC4 algorithm is copyrighted by and intellectual property of RSA Data >Security. For use of this algorithm in a product or service you plan to >sell, you may use the RC4 software implementation from our BSAFE toolkit. >Licenses are not available for other commercial software implementations of >this algorithm other than what is included in our BSAFE toolkit. I wasn't aware that you could copyright an algorithm. Patent, yes, but not copyright. Intellectual property meens secret, right? Aren't there any precendence cases involving propriety schemes that are reverse engineered? I know there have been, I just can't remember what they are. In any case, RSADSI is likely to sue anyone who attempts to use the RC4 code openly, and even if they lose there are considerable legal fees involved for whoever tries it. What if a bunch of people put secure HTTPd servers online at the same time, without any clear trail pointing to the first one? If the RC4 code really is legal to use, this would make it hard for RSADSI to pinpoint anyone to sue, thus eliminating the intimidation factor. By the way, since RSA is such a vocal opponent of the Clipper chip on the grounds of its secret Skipjack algorithm, why does it market secret algorithms like RC4 and RC2? Does this seen like a double face to anyone else? ----------------------------------------------------------- Russell Ross email: rross(a)sci.dixie.edu 1260 N 1280 W voice: (801)628-8146 St. George, UT 84770-4953

5 4

Full text of David Chaum's Congressional speech
by Marcel van der Peijl 17 Dec '03

17 Dec '03

Here's the full text of the speech David Chaum gave in his Congressional hearing. I will also make it available for online reading on our web server in the publications section. --- cut here --- Mr. Chairman, Members of the Committee: As an American who is regarded as the inventor of electronic cash, who has worked over the last dozen or so years to make the technology viable, and who is now CEO of a leading company pioneering in its commercialization, I am very pleased by the interest being shown here and to be here today. We are being forced to decide between two very different kinds of electronic payment technology. The core values we as a nation have fought for, and continue to stand for, are at stake. As a consequence of choosing one of the two directions, these values will be profoundly eroded; by choosing the other direction, however, they will be preserved and likely extended. Wise decisions at this critical juncture may also allow us to avoid certain other pitfalls and to realize economic leadership and growth. I think my limited time before you is best used to briefly explain the fundamentally different approaches to security, before coming to privacy, privacy technology, and its implications. Security Security is simply the protection of interests. People want to protect their own money and banks their own exposure. The role of government is to maintain the integrity of, and confidence in, the whole system. With electronic cash, just as with paper cash today, it will be the responsibility of government to protect against systemic risk. This is a serious role that cannot be left to the micro-economic interests of commercial organizations. In order for those in government to make informed decisions, it will be necessary for them to understand the basic ways to secure transactions in different situations. One basic form is tamper-resistance, exemplified by the chip in a chip card. It is designed to be hard to modify or to read secrets from. Such tamper-resistance is needed for "off-line" payments--those in which the reader device receiving payment from a card, validates payments by contacting a central system only at the end of each day. (Incidentally, this and the other basic form must rely for security on cryptography, sometimes refereed to as encryption, which is fundamental to all information security.) The other basic form is where the individual uses their own computer, whether a desk-top, lap-top, or palm-top device. Such "software only" is all that is needed in an "on-line" system--a system in which the party receiving payment communicates over a network during each payment. The trend is toward a convergence of these two forms into a hybrid--since people don't want incompatible forms of money and since it offers the best of both worlds in terms of convenience; in other words, you will put a chip card into a user-friendly electronic device of your own choosing, whether on your desk, in your living room, or in your pocket. I have brought some examples of this to show you... The problems I see in the industry today reflect a lack architecture. And architecture is essential when building infrastructure, which is what we are embarking on. In my view, a sound architecture must: (i) include the two basic forms of security, and allow for their integration into the hybrid; (ii) prevent the vulnerability of system-wide secrets from being stored in every card or, nearly as bad, every off-line point of payment; and (iii) address privacy concerns effectively, since they cannot be addressed as add-ons or afterthoughts. Today, DigiCash systems are alone in having any of these three attributes, and their architecture has all three. Privacy Let me now turn to this issue of privacy... A recent Harris poll of the American public began by introducing respondents to all the consumer benefits of the information superhighway. Then respondents were told that in order to make such systems economically viable, payment transaction data would have to be gathered and used for purposes such as making special offers to them. But the majority of respondents still objected to any use, other than consummation of the payment, and they gave privacy as the primary reason. Fully 82% of Americans today expressed concern over privacy of computerized data. That fraction has been growing steadily ever since the "first wave" of privacy concern was triggered when Americans saw their names punched into computer cards or printed on computer generated forms. When people are exposed to the information superhighway, which provides an awesome glimpse of the power of modern information technology, with dropping transaction costs leading to finer granularity of payments (which we will be hearing more about later), concern will reach new levels. Privacy Technology "Privacy technology" allows people to protect their own information, and other interests, while at the same time it maintains very high security for organizations. Essentially, it is the difference between, on the one hand, a centralized system with disenfranchised participants (like the electronically tagged animals in feedlots); and, on the other hand, a system where each participant is able to protect its own interests (like buyers and sellers on a town market square). Take ecash as an example of privacy technology. It provides a fully digital bearer instrument--a number that is itself money, just like a bank note is money. On the Internet, once someone downloads the requisite software, which takes only a few minutes, they are ready to send and receive ecash in payments. Security of ecash is superior to that of paper cash. If it is stolen, it cannot be used; if someone refuses to give you a receipt, you have proof that they deposited it; and if it is lost, you can get your money and records back. Counterfeiting ecash poses the same cryptographic challenge as breaking the most sophisticated codes used to protect nuclear materials, military secrets and large-value wire transfers. Therefore, ecash is certainly not the target of opportunity. Ecash is already being experimented with on the Internet in a worldwide monopoly money trial with tens of thousands of participants. Related card technology has been extensively tested, by DigiCash licensee Amtech, for highway-speed road tolls and road pricing, offering privacy instead of dossiers on everywhere people drive. And, CAFE, the European Commission sponsored trial, at its headquarters buildings in Brussels, of chip cards that can be inserted into electronic wallets (that I have already shown you), allows privacy in payments and the electronic ECU. Such "privacy technology" was even successfully used by the participants at the most recent international meeting of data protection commissioners. Ecash has received substantial media coverage; consequently, the public is beginning to realize that the coming of electronic payments need not mean an obliteration of privacy. And the superhighway will give consumers unprecedented mobility to choose it. Some concern about ecash, however, has been raised by various parties over possibilities it might open for illicit payments. But there is simply no legitimate basis for these allegations. Ecash, even when it achieves significant scale, is considerably less dangerous to society than automatic teller machines. For one thing, like cash, the amount withdrawn and deposited is on record; but, for another, unlike cash, the amounts of money that pass through each person's hands are also on record at the bank. Ecash itself is less prone to abuse than paper bank notes, because privacy is "one-way," which means that an extortionist, a seller on a black-market, or the acceptor of a bribe is forever vulnerable to being irrefutably incriminated by the party that paid them. National Leadership Governments who stifle the new technology while it is still in its infancy, before its has had a chance to develop and harmonize with our institutions; who don't pro-actively support needed infrastructure; or who fail to establish confidence by protecting against systemic risk--will be left behind in global competition. Countries who take clear positions based on understanding of the technology, however, and encourage needed developments, stand to gain enormous economic growth and market leadership. Privacy technology, whether used for electronic payments, voting, or other public expression, is the electronic equivalent of a free market and democracy. People will come to insist on it as an informational human right. Dr. David Chaum, DigiCash --- cut here --- // Marcel van der Peijl, DigiCash bv // http://www.digicash.com/~bigmac/ // There is no signature like no signature!

3 2

Re: RC4
by Wolfgang Roeckelein 17 Dec '03

17 Dec '03

Hi, >I wasn't aware that you could copyright an algorithm. Patent, yes, but not >copyright. Intellectual property meens secret, right? Aren't there any >precendence cases involving propriety schemes that are reverse engineered? Game cartridges (I think sega was involved) Wolfgang --- Dipl.-Wirtsch.-Inf. Voice: +49 261 6509 173 Wolfgang Roeckelein Fax: +49 261 6509 179 WHU Koblenz E-Mail: roeckelein(a)wi.whu-koblenz.de Burgplatz 2 (NeXTmail ok) D-56179 Vallendar WWW: http://www.whu-koblenz.de/~wolfgang/ Germany --rsa--------------------------------8<------------------------------------- #!/usr/local/bin/perl -s-- -export-a-crypto-system-sig -RSA-in-3-lines-PERL ($k,$n)=(a)ARGV;$m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2% Sa2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*' ,$_)while read(STDIN,$m,($w=2*$d-1+length($n||die"$0 [-d] k n\n")&~1)/2) -------------------------------------8<------------------------------------- TRY: echo squeamish ossifrage | rsa -e 3 7537d365 | rsa -d 4e243e33 7537d365 Residents of the USA & France *MUST NOT* include this .sig if following up! *** Residents of France & Russia *MUST NOT* make any use of this -sig ! ***

2 1