December 2003 - cypherpunks-legacy

Re: (fwd) DES challenge organisation
by Thomas S. 17 Dec '03

17 Dec '03

Hi! (wow, what a distribution. I should mention that des-challenge is down this weekend, so the response may not be as expected.) >>>>> "Timothy" == Timothy C May <tcmay(a)got.net> writes: Timothy> At 11:02 PM +0000 2/15/97, Adam Back wrote: >> Thomas S <ths(a)fh28.fa.umist.ac.uk> writes: >>> [...] >>> >>> 5. The prize money will be split equally between Gutenberg and >>> EFF. There is a possibility of using part of it for stickers >>> or something similar, but don't count on it. >> Not a good idea. >> >> How can this be enforced? The RSADSI DES challenge is open to >> all comers, and how do you prove that someone who finds the key >> found it through this group effort? The client reports the key to the server, not to the user (very simple, and very simple ways to get around of course). In a nutshell: we can't enforce it, at least I can't see a way to do so. We certainly can't keep people from doing their own "treasure hunt". ... Timothy> A 2-4x factor is significant, and may warrant a Timothy> coordinated search. However, the various problems Timothy> implicit in coordinated searches are factors, too. Timothy> Also, an uncoordinated search solves the "prize" problem, Timothy> as whomever finds the key makes the contact with RSADSI. Indeed--that's what we try to avoid. Our project is not a race for money, it is a demonstration with a political impact. The main point in favour of a coordinated search is the availability of progress reports. Nobody can argue that the key was found by chance--as there is exact data about performance and the expected maximum duration for the search. Timothy> One of the problems with a coordinated search, if the Timothy> remaining keyspace to be doled out is publically Timothy> announced, is that as the keyspace is searched and a key Timothy> _not_ found, the remaining keyspace is increasingly more Timothy> tempting for "independent searchers" to search. Sort of Timothy> the way the odds on some lotteries actually become Timothy> "acceptable" as the lottery pot grows. The organizer of Timothy> the coordinated search must then, I surmise, keep the Timothy> assignments secret and dole out keyspace securely. This is a technical problem which is discussed at the moment. The keyspace will not be publically announced (and it wasn't during the last project). Thomas -- OOOO, OOOOOOOO, |, ths(a)rz.tu-ilmenau.de OO, OO, O, O, |, http://www.rz.tu-ilmenau.de/~ths/ O, O, O, |, ______ __ ___ O, O--O, O, O, |, | (_ |-|-` O, O, O, |, |homas __)te| |en OO, OO, O, O, |, OOOO, OOOOOOOO, |, not to be forwarded without permission

1 0

ANNOUNCE:- RSAEuro
by rsaeuro＠sourcery.demon.co.uk 17 Dec '03

17 Dec '03

ANNOUNCE:- RSAEuro Version 1.04 (Internet) and 1.10 (Commercial) ================================================================ What is RSAEuro? ---------------- RSAEuro is a cryptographic toolkit providing various functions for the use of digital signatures, data encryption and supporting areas (PEM encoding, random number generation etc). To aid compatibility with existing software, RSAEuro is call-compatible with RSADSI's "RSAREF(tm)" toolkit. RSAEuro allows non-US residents to make use of much of the cryptographic software previously only (legally) available in the US. RSAEuro contains support for the following: * RSA encryption, decryption and key generation. Compatible with 'RSA Laboratories' Public-Key Cryptography Standard (PKCS) #1. * Generation and verification of message digests using MD2, MD4, MD5 and SHS (SHS currently not implemented in higher-level functions to maintain compatibility with PKCS). * DES encryption and decryption using CBC (1, 2 or 3 keys using Encrypt-Decrypt-Encrypt) and DESX(tm), RSADSI's secure DES enhancement. Blowfish and RRC.2 encryption and decryption using CBC (available in commercial versions only). * Diffie-Hellman key agreement as defined in PKCS #3. * PEM support support for RFC 1421 encoded ASCII data with all main functions. * Key routines implemented in assembler for speed (80386 and 680x0 currently supported). * Much improved library documentation with code samples. International Use ----------------- IMPORTANT NOTICE: Please do not distribute or use this software in the US it is 'illegal' to use this toolkit in the US, as RSADSI and Cylink hold patents relating to public-key cryptography. If you are a US resident, please use the RSAREF toolkit instead. On The Web ---------- RSAEuro can now be found at http://www.sourcery.demon.co.uk/RSAEuro.html Author Details -------------- With comments and suggestions, please address them to Stephen Kapp, at 'rsaeuro(a)sourcery.demon.co.uk', for documentation comments suggestions please address them to Nick Barron, at 'nikb(a)sourcery.demon.co.uk' ---------------------------------------------------------------------------- RSAEURO: rsaeuro(a)sourcery.demon.co.uk RSAEURO Bugs: rsaeuro-bugs(a)sourcery.demon.co.uk Tel: +44 (0) 468 286034 Http: http://www.sourcery.demon.co.uk/rsaann.html RSAEURO - Copyright (c) J.S.A.Kapp 1994-1996. ----------------------------------------------------------------------------

1 0

Re: DFA
by John Young 17 Dec '03

17 Dec '03

Paul Bell wrote: >does anyone know what has happened to DFA, and the people who >just a few months ago were publishing such encouraging results? There seems be sustained investigation of DFA, offensive and defensive, by Biham and Shamir, by Anderson and Kuhn, by the Bellcore team, by Quisquater and others. However, the smartcard manufacturers appear to have a role in dampening publicity about the ongoing research, or at least diminishing the claims of effectiveness of DFA. Carol Francher, of Motorola, for example, writes in February IEEE Spectrum: Technology is a wonderful thing but criminals, too, can use it as new equipment and techniques become available or less expensive the barriers to cracking a system may weaken. Recently Bellcore announced a paper, "Cryptanalysis in the presence of hardware faults" (available at www.bellcore.com) that proposed a theoretical method for breaking an asymmetric encryption code once a computer (or a smartcard microcontroller) had been forced into faulty behavior. The Smart Card Forum, a multi-industry membership organization headquartered in Tampa, Fla., has stated that it does not regard this approach as a real-world risk, since in smartcard applications more than one technique is used to protect the security of the entire system. But the Bellcore methodology for breaking algorithms -- as well as similar theoretical approaches, such as the one taken by two Israeli researchers, Eli Biham and Adi Shamir -- highlights the need to analyze and evolve the security of any system continually. -- "In your pocket: smartcards." <http://jya.com/tee08.htm> Several of the DFA-type researchers have commented on the smartcard industry's reluctance to publicize security weaknesses when the push is on to increase consumer trust and use; see, for example, Anderson and Kuhn at: http://www.cl.cam.ac.uk/users/rja14/tamper.html Quisquater and the SG group also note the reluctance of smartcard mass-marketers to own up to security shortcomings of which their own engineers know and fret. Meanwhile, the DFA proponents and opponents are eagerly absorbing the continuing DFA-relatged reports, quietly watching one another, and both sides eying the booming smartcard market for lucrative rewards, as Ms. Francher suggests: licit and il.

2 1

No Subject
by Bovine Remailer 17 Dec '03

17 Dec '03

Timothy May must have been sharing needles with a rabid hedgehog. o o Timothy May o \_/

1 0

Thanks to John Gilmore for running cypherpunks mailing list
by ichudov＠algebra.com 17 Dec '03

17 Dec '03

Hi, cypherpunks(a)toad.com goes down in four days. I would like to thank John Gilmore for all his efforts that he spent to run the list. Administering a huge mailing list like cypherpunks is a tough job, requiring a lot of dedication, time and patience. John, along with other cypherpunks, created a unique online community that generated many valuable ideas. This community helped a great deal to increase crypto awareness of the masses. I personally joined cypherpunks for very arkane reasons, but later found out a lot of useful information. The moderation experiment failed by many reasons, but the last month should not distract us from what John did over last several years. Again, thanks to John for his work. - Igor.

1 0

Proposed info file
by ichudov＠algebra.com 17 Dec '03

17 Dec '03

Hi, The text below is what I wrote for cypherpunks(a)algebra.com to be sent to new subscribers. Feel free to criticize. - Igor. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ About cypherpunks mailing lists ------------------------------- * * * ATTENTION: PLEASE SAVE THIS MESSAGE IN A MAIL FOLDER!!! IT WILL BE * * * HELPFUL FOR YOU WHEN YOU WANT TO UNSUBSCRIBE FROM cypherpunks MAILING * * * LIST. * * * * * * DO NOT JUST DELETE THIS MESSAGE. I. Administrivia (please read, boring though it may be) The cypherpunks list cypherpunks(a)algebra.com is one of the cypherpunks mailing lists discussing cryptography, privacy, and social issues relating to them. These lists are connected to each other in such a way that all messages appear on all of these lists. All of these lists are high-volume mailing lists. There are several reasons for existence of multiple mailing lists that are inter-subscribed. The main reason is the large number of subscribers and limited bandwidth of each of the participating list nodes -- each node can take on only that many users. Most people will not want to subscribe to more than one of these lists. If you don't know how to do something, like unsubscribe, send mail to majordomo(a)algebra.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-request(a)algebra.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. Also, please realize that there will be some cypherpunks messages "in transit" to you at the time you unsubscribe. If you get a response that says you are unsubscribed, but the messages keep coming, wait a day and they should stop. Do not mail to the whole list asking to be removed. It's rude ans stupid. To post to the whole list, send mail to cypherpunks(a)algebra.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 a meta list which discusses the architecture and other issues of the distributed cypherpunks lists. It is not intended to be used for crypto discussions. if you want to be added or removed to the metadiscussion list, send a message "subscribe cypherpunks-hosts" to majordomo(a)algebra.com. 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. alt.cypherpunks is indended as a mirror USENET forum for this mailing list. III. Posting Policy. Please note that some members of cypherpunks mailing list may surprise you as very rude people. You may see views that sound very offensive to you. You will also see many articles that make no sense to you, are very stupid, or appear to be commercial advertisements. Consider such situation to be a price of YOUR freedom to post anything you want. Remember that speech that pleases everyone needs no protection: it is the offensive speech that is most often assaulted and thus needs to be protected. Also, speech that you find silly and distasteful may seem to be of great use for others. If you feel that some poster's articles are not useful and offensive to you, you can set up your mail reading software to ignore all articles coming from that person. Ignoring them silently has shown to be the best way of dealing with them. It will save you a lot of your own time. Even though you are free do write anything, please consider not following up to their posts with suggestions to shut them up. It only decreases usefulness of this mailing list. Eudora for Windows is known for its mail filtering capability. Procmail is a tool of choice for Unix users who want to filter their articles. Please read the documentation for these programs to find out how to set them to filter and delete unwanted messages. None of the above precludes the administrator of this mailing list to use tools protecting his hardware and bandwidth from denial of service attacks. If someone maliciously mailbombs cypherpunks mailing list, the mail bombs may be silently ignored and not passed on to the list. IMPORTANT: the list owner does not monitor the content of the messages appearing here. I disclaim any liability whatsoever for the content of articles on cypherpunks(a)algebra.com. If you have a problem with any materials posted here, please contact the poster to resolve them. Your use of the resources of this list constitutes an agreement with these terms. You have been warned. IV. 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 (and there are no non-technical cypherpunks). 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. Enjoy and deploy. ----------------------------------------------------------------------------- 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 Sun Feb 16 13:10:56 CST 1997 ichudov(a)algebra.com] [Adopted from the original version by John Gilmore and Eric Hughes]

2 2

'Jim Beam' me up, Scotty!
by Toto 17 Dec '03

17 Dec '03

scribve cypherpunks-thenextgeneration "Dr. Spook" <6UALDV8(a)cyberspace.9>

1 0

Re: Query on "secure databases"
by Bill Stewart 17 Dec '03

17 Dec '03

Hi, Peter - here's my previous posting, with an addendum, Cc: cypherpunks At 04:43 PM 2/11/97 -0500, Peter Swire <swire.1(a)osu.edu> wrote: > Can you point me to anything I can read on "secure databases"? I >hadn't hit that term before. I am curious to what extent they are secure >due to cryptographic approaches, or to what extent you rely on other >mechanisms for keeping out unauthorized users. It's been a long time since I've looked much into it, since I was getting out of phone-company-defense-contractor mode at the time the field was developing. I think the NCSC Rainbow Book that deals with secure databases is the Purple Book, though it might be the Gray. Oracle and/or Sybase have done some work trying to do databases at the B1 or B2 level, but I don't know details. I'll talk about secure databases a bit, but for the real world there's more useful stuff that isn't related to them. =================== Begin "Secure Database" Section ============== At the time, the Orange Book (security for standalone computers) was well-understood, though there weren't really any systems above B2 level, and the Red Book was written, but nobody really had a clue how to implement multi-level machines on a multi-level LAN, though you could use encrypting Ethernet cards to get single-level machines of different levels on the same LAN, if they were all administered by the same group of people (so user-IDs and security levels worked across the entire system.) At the lower security levels, Orange Book techniques mainly involve removing bugs and adding accounting features. At the higher levels, the key is to come up with a good mathematical/logical model of interactions in your computer system, and then design a computer system that only does the things permitted by the model and prove it does that. Some of these systems use cryptographic techniques, including some of the capability-based systems - see Bill Frantz's KeyKOS work, which he's referred to on Cypherpunks occasionally. The objective is to have databases that can be accessed by multiple users with different sets of security permissions. In the military vernacular, this mainly means having UNCLASSIFIED, CONFIDENTIAL, SECRET, and maybe TOP SECRET data in the database, where not all users are cleared to the highest security level, and maybe projects X, Y, and Z, where users of project X may not have a need to know for project Y, etc. The easy problems are probably solved by now - either you do a good job of verifying the design and bug-free-ness of your database software so you can be sure that each request includes, and obeys, security levels, or you use crypto to encrypt the data items for each security level (e.g. everybody with a SECRET or PROJECT Z clearance shares a key for that data, which isn't really ideal for non-small groups of people, the database just tries to do a good job, and you only do operations in the database that make sense when the data is encrypted, though that's annoyingly restrictive for many applications.) The sticky problems are aggregation-related. It may be ok if an uncleared person knows that military base A has missile types 1, 3, and 5, and if the uncleared person knows where all your military bases are. But is it ok if the uncleared person knows about _all_ the missiles at _all_ the bases, and can tell that nobody's using Type 2 missiles any more, and that all the Type 4 missiles got moved to New Jersey last week? =============== End "Secure Database" section ================= =============== Begin "Real-World and Crypto" section ========= For the average person, though, the simple military models aren't really useful. You really care more about groups of people, though the multi-level stuff is sometimes a good way to keep machines from being hacked. But the real problem is that computers are very good at correlating information - if two different companies know your Social Security Number, and they share their data with each other (maybe for a price), then they can all tie together everything they each know about you. And there's no way to stop it, except by limiting the information you give people (which limits the transactions they'll do with you), or contractually limiting what they can do with it (good luck), or using multiple identities - and even then, computers are often good at guessing that the John Doe at 1234 Main Street is the related to Jane Smith at 1234 Main Street, and maybe the foreign car parts Jane bought on her American Express are for the Porsche registered to John, so there's a junk-mail opportunity. There's really only one technology that lets you avoid this, which is crypto and its relatives - though you still have to get people you use business with to use it, which is an uphill game. Some of the fundamental work on this is David Chaum's papers on Credentials without Identity (or something about like that, from ~1985.) For instance, you can have a voter registration number that's cryptographically signed by the voting bureau, but uses blinded signatures so they can't correlate the known good unique number with the Peter Swire who walked in and showed a picture ID one day. A driver's license smartcard could keep a pointer to your driving records, but wouldn't give your True Name, and would only show a cop that the person whose picture is on the front is a Licensed Driver, and maybe could demonstrate that the bearer knows the card's PIN. One big issue is that the government is pushing banks to demand SSNs, and requiring employers to demand SSNs (makes them easy Employee IDs), and pushing medical insurers and providers to use SSNs (makes it easy to collect Medicare data.) You can gain a lot of privacy just by having employers use their own employee-ID numbering system, so the travel agent subcontracting to Corporate Travel doesn't need your SSN on every form they fill out. But suppose the Social Security Administration and IRS issued you a bunch of separate numbers, that were either related using a cryptographic key, or just randomly picked and kept in a big database (maybe pointing to your old SSN), so you could give everybody who needs a Tax ID a different number, and only you and the IRS could correlate them. (To some extent, you can do this yourself by creating lots of companies, but it's a real pain and costs a certain amount of money.) =============== addendum ===================== Of course, for many transactions, the way to reduce the privacy problems is to use bearer certificates rather than book-entry approaches - pay cash, or digicash, rather than credit cards, use on-line anonymous delivery of bits, or picking up stuff in person, rather than mailing stuff to a snail address, etc. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

1 0

Re: Excerpt on SPAM from Edupage, 11 February 1997
by Sean Roach 17 Dec '03

17 Dec '03

At 04:45 PM 2/15/97 -0600, Igor Chudov wrote: >Roy M. Silvernail wrote: ... >> Or that the money wasn't there in the first place (absent a trusted >> signature system), or the key doesn't exist, or the wrong key is >> offered, or the sender put the same e-dollar on all 60000 mails sie >> sent and it's already been redeemed. > >Well, if the trusted party performs the encryption by both recipient's >public key and the "retrieval key", the problem that you mention can >be avoided. Yeah. I as a spam artist send the "proof" message through the e-cash verification center with the Send To: field returning it to a mail exploder. Each receipient gets the same dollar. This assumes that the To: field is not hashed into the verification signature, and that the verification works like a glorified remailer. (cash added on a separate channel).

1 0

We're in Anguilla! Comon down!!!
by Bill Clinton 17 Dec '03

17 Dec '03

My fellow cypherpunks, I wanted to let you all know, we are having a great time, building a router to the 21st Century, down here in sunny Anguilla. Al and I will be wiring Anguilla's great high school for the internet. Afterwards, we'll meet with some longtime supporters of the democratic party for a beer. Spaces at the conference are still available, I didn't let those folks at American strike, so you have no excuses to be anywhere else next week. Willy Citizen Unit 429-92-9947

1 0