December 2003 - cypherpunks-legacy

RE: What is needed for S/MIME remailer ?
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Raph Levien[SMTP:raph@CS.Berkeley.EDU] Sent: Tuesday, October 24, 1995 1:27 PM To: sameer Cc: cypherpunks; baldwin Subject: Re: What is needed for S/MIME remailer ? sameer writes, among other things: > A) limit on number of multiple concurrent procersses doing > decryption. Remailer spams have the bad effect of spwaning hundreds of > concurrent PGPs on the mailhost, bringing things to halt. Limiting > number of concurrent decryptions would help this problem. Agreed. > B) A strong interaction with the UNIX shell, with the program > returning a return code based on whether or not the decryption > succeeded. (Remailers only do decryptions...) That way a remailer > could something like: We very much need a command line interface to S/MIME, to use in remailers and also for other kinds of testing/hacking. I hope one is forthcoming soon. > I think the smime should be easily plugged into premail as > well, but I don't know premail to know what would be necessary for > that. I suspect Raph would have some input on that matter. Raph does indeed have some input on the matter. I am currently rewriting premail from the ground up, and am about 700 lines into it. One specific design goal was the support of other types of encryption, including Mixmaster and MOSS in the first release, and hopefully others as well. Basically, I'm waiting on a command line S/MIME implementation as described above, most hopefully as free software. In any case, the new premail is _much_ more modular, so plugging in experimental email stuff should be pretty straightforward. Raph

1 0

RE: 80 bit security from 40 bit exportab
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Jeff Barber[SMTP:jeffb@sware.com] Sent: Tuesday, October 24, 1995 4:05 PM To: RobertW.Baldwin Cc: cypherpunks Subject: Re: 80 bit security from 40 bit exportable products baldwin writes: > > Long ago vendors should have put encryption into network layer > products, but for a variety of reasons that effort was delayed or > discouraged. One effect of this lack is that almost every layer of > the network stack is adding its own encryption. For example, the > HTTP session layer added S-HTTP and the TCP transport layer added > SSL. Soon we will have network layer encryption with IPsec. > The vendors for each layer can export a product that uses > ciphers with 40 bit keys. A user can then combine multiple > products to get more than 40 bits worth of security. For example, > a web client might fetch an S-HTTP page over an SSL protected link > via a firewall that supports IPsec tunnels. That's three 40 bit > keys protecting the data over the internet link (of course, this > may not be equivalent to a 120 bit cipher, that depends on the > details of the cipher systems and independence of the key setups). > Interesting possibilities. > --Bob Baldwin Even if you assume complete independence of key setup, if a successful decryption at each layer can be independently detected and verified (which seems likely in your example), there're only about 3 * (2 ^ 40) total operations in the worst case, NOT 2 ^ (3 * 40) operations needed to expose the plaintext. This is an effective 41.5 bits, not 120. -- Jeff

1 0

RE: What is needed for S/MIME remailer ?
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: sameer[SMTP:sameer@c2.org] Sent: Tuesday, October 24, 1995 1:15 PM To: RobertW.Baldwin Cc: cypherpunks; raph Subject: Re: What is needed for S/MIME remailer ? My understanding of S/MIME isn't excellent, so I figure there are things I could be confused about which may make this a bit wrong.. I figure a command line S/MIME program which could easily be integrated into a remailer wouldhave the following features: A) limit on number of multiple concurrent procersses doing decryption. Remailer spams have the bad effect of spwaning hundreds of concurrent PGPs on the mailhost, bringing things to halt. Limiting number of concurrent decryptions would help this problem. B) A strong interaction with the UNIX shell, with the program returning a return code based on whether or not the decryption succeeded. (Remailers only do decryptions...) That way a remailer could something like: #!/bin/sh if smime -f < incoming-message > /tmp/decrypted.$$ then # Process /tmp/decrypted fi rm incoming-message rm /tmp/decrypted.$$ The option would also be a very low-cruft-output -- there would be none of that PGP v2.6.2 stuff that PGP sends out. Just the decrypted output and if the message cant be decrypted, nothing gets output. (Maybe a -q option for that..) I think the smime should be easily plugged into premail as well, but I don't know premail to know what would be necessary for that. I suspect Raph would have some input on that matter. > > The other day I was wondering what it would take to make an > anonymous remailer for an S/MIME client. Implementing S/MIME from > scratch is a lot of work given the lack of a public domain > implementation, but it seems that a remailer could be built on top > of a commercial email product that supported S/MIME. The question > is: What features should a commercial S/MIME email product have to > make it easy to support a remailer? Are there a small set of > command line options that would greatly simplify a remailer > implementation? > --Bob Baldwin > -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

RE: No Subject
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Mixmaster[SMTP:mixmaster@obscura.com] Sent: Tuesday, October 24, 1995 1:10 PM To: cypherpunks Subject: No Subject To All, A theme I have been thinking about lately is a virtual data haven using a m from n secret splitting scheme via a DC Net for access and hosting the entire process via HTML and W3. The salient feature would be database objects split in such a way that participating sites would possess no more than 1 encrypted slice of any particular encrypted object. Some redundancy of storage is built into the design and participating site give up local storage to store other slices of the datahaven. At no time is the site hosting able to make correlations of slices to plaintext traffic because the split is done on the users workstation and the placement of the slice on the individual slice on the member datahaven site is accomplished with encrypted remailer tech(probably Mixmaster 2) and CGI or java scripts. The idea here is to be able to store ANY information on the net not just what the local bluenoses approve of. anon

1 0

RE: MD5 weakness ? [was Re: Netscape Log
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Steve Bryan[SMTP:sbryan@maroon.tc.umn.edu] Sent: Tuesday, October 24, 1995 3:08 PM To: Dr. Frederick B. Cohen Cc: cypherpunks Subject: Re: MD5 weakness ? [was Re: Netscape Logic Bomb detailed by IETF] Dr. Frederick B. Cohen writes: >In the case of the trust being placed in MD5 by Netscape, the assumption >being made (without adequate support as far as I can tell) is that an >MD5 checksum cannot be forced, through a chosen plaintext attack, to >yield checksums of 1, 2, 3, 5, 7, 9, ... on up to enough primes to >allow the known plaintext attack that gets the RSA private key used to >authenticate messages. As far as I am aware (and I may not be aware of >everything) there is no reference work to support this assumption. If >the assumption is wrong, then the whole SSL can fall to a selected >plaintext attack launchable (presumably) through those general purpose >Java aplets we have heard so much about. With a mailing list this large and diverse one can reasonably assume a range of interests and expertise. What I don't understand is your agnostic stance on something as apparently basic as MD5. If computer security is your purported area of expertise why have you not reached any firm conclusions about it? I understand that rigid conclusions are unsafe (eg they'll never prove Fermat's last theorem) but it is not like every question is equally open. Do you have a realistic attack on MD5 or is this sophomoric claptrap? How do you propose to generate messages with specific message digests? Assuming you could somehow, how do you proceed to use that information to your advantage? So let's say I have a message digest and I'm retrieving the allegedly corresponding message which you have the opportunity to alter to your heart's content. How would you proceed, even in principle, to defeat MD5? I realize I might be assuming too much when I posit that I have the true MD5 for the message but my understanding is that you feel that MD5 might be vulnerable. I've given you all the known plaintexts. Is there a next step? +---------------------------------------------------------------------- |Steve Bryan Internet: sbryan(a)gofast.net |Sexton Software CompuServe: 76545,527 |Minneapolis, MN Fax: (612) 929-1799 |PGP key fingerprint: B4 C6 E2 A6 5F 87 57 7D E1 8C A6 9B A9 BE 96 CB +----------------------------------------------------------------------

1 0

RE: MD5 weakness ? [was Re: Netscape Log
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Dr. Frederick B. Cohen[SMTP:fc@all.net] Sent: Tuesday, October 24, 1995 4:01 PM To: cypherpunks Subject: Re: MD5 weakness ? [was Re: Netscape Logic Bomb detailed by IETF] ... > I believe Dr. Cohen's point is that no-one knows, AFAIK, how to prove that a > one-way hash is truly one-way (uninvertible). We cannot prove that MD5 is > secure, ergo we cannot (completely) trust it. [Please correct if this is a > substantially incorrect inference.] > > One of the standard responses is "it's the best we can do". When people said > this about PGP, FBC made some (IMHO) interesting comments about the > encryption he uses in various circumstances. Perhaps he would like to share > his personal choices of one-way hash functions with us. Since you asked: It's a really complex issue. As a fundamental, we know that any "one-way" hash function must be many-to-one, which means that, in practice, there are always large numbers (2^large numbers) of sources for any given hash. This means that forgeries are always possible. I know of no way to prove that (and no convincing argument that the workload for creating) a forgery is hard for any "one-way" hash function. This seems to mean that we are always betting on faith about these things. The techniques that seem to be reasonably good are; modular exponentiation in a modulus that's the product of two appropriate primes (a.k.a. RSA but throw out the private key when you create it); certain classes of non-linear feedback shift registers of high degree; and some general class of mixing algorithms like MD5. The RSA-type hash is slow, and some great mathematician may show up tomorrow and lay waste to the whole thing. Non-linear feedback shift registers have the advantage that we don't know how to factor high-degree equations, so we don't know how to make simple closed form solutions to find output values. MD5-type systems are good because they combine diffusion and confusion and avoid a lot of the more well-known flaws as far as we know. None of these reasons are particularly convincing, so I think we have to take a risk management approach. So the ultimate question here is, how much are we willing to bet that nobody can break one of these in the intended application over a particular time frame. I trust the RSA and NLFSR systems, if reasonably well implemented, for a single short time-frame low-valued transaction. For example, pick a good pseudo-random number and create an RSA one-way hash of 512 bits (the random number issue is of course another whole area), encrypt the first bloack, Xor with the second block, encrypt the result, etc. till done, then Xor again with the original random seed, send the file and the hash along with the one-way key, and get a confirmation back within a few days. I don't trust any of them as a basis for running a major part of an economy over open communications links, and I especially don't trust them when combined or when the security of one depends on another. To run an economy, I think you need more redundancy, more personnel security, more stop-loss capabilities, physically secure devices, independent checks and balances, etc. Someone on this list mentioned that the banking system trusts the RSA and MD5, etc. but this seems to me to be a mischaracterization. They trust these systems to an extent, but they have key change requirements, regular audits, physical security, relatively secured communications lines (when compared to the Internet), strong procedural controls (most of the time), and other such protections, and they still get hammered for a few million now and then. This is probably enough for now, since the list is probably getting tired of my posts and I have made the major points. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

1 0

RE: (fwd) Chaum vs. Stein
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Robert Hettinga[SMTP:rah@shipwright.com] Sent: Tuesday, October 24, 1995 3:52 PM To: cypherpunks Subject: (fwd) Chaum vs. Stein --- begin forwarded text To: www-buyinfo <www-buyinfo.allegra..att..com(a)mail.checkfree.com> From: Andrew Barrett/CheckFree Corporation <Andrew_Barrett(a)checkfree.com> Date: 24 Oct 95 13:38:40 EDT Subject: Chaum vs. Stein Wanted to save my 'me too' until a time I could piggy-back it onto something a little more pithy (and I DO mean 'little'). Robert, thanks for taking the time and energy for filtering cpx and forwarding the best. David, thanks for providing the forum. Now that _that's_ out of the way ... I've just been handed a registration booklet for The Bank Administration Institute's Retail Delivery '95 conference December 2-6 in Atlanta. Notable speakers include The Bill, MasterCard CEO Eugene Lockhart, Visa International CEO Edmund Jensen, Intuit CEO Scott Cook and Checkfree CEO Pete Kight (among others). Featured on page 6 is a "Fireside Chat: The Financial Marketplace of the Future" moderated by Lou Dobbs... How warm and fuzzy. What really caught my eye was a panel discussion on Internet Security scheduled for that Wednesday. The panelists are David Chaum, Cybercash CEO William Melton, and FV CEO Lee Stein. If anyone goes, tell us all how it went! Kicker - the postal frank is of the "non-profit organization" variety. BIA's site is at http://www.bai.org --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

RE: Sun speaks out - but not to the cyph
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Todd Glassey[SMTP:todd@lgt.com] Sent: Tuesday, October 24, 1995 12:52 PM To: David A Wagner Cc: cypherpunks Subject: Re: Sun speaks out - but not to the cypherpunks >-----BEGIN PGP SIGNED MESSAGE----- > >In article <v02110101acaf51651ef9(a)[204.156.156.4]>, >Todd Glassey <todd(a)lgt.com> wrote: >[ lines marked > > are from fc(a)all.net (Dr. Frederick B. Cohen) ] >> Pardon the flame but I really have just about heard enough of this BS... >[...] >> >> The area where we can (must) build trust is the computing base. >> >> Traditionally, this has been the OS, but in the case of java, it is >> >> the java interpreter (such as netscape 2.0 and hotjava). The browser >> >> is now the TCB (trusted computer base) for all practical purposes... >> > >> >Read: The Java interpreter is supposed to be a TCB. >[...] >> >Who here truly believes that the implementations of Java meet the >> >requirements of a TCB? >[...] >> Dr. Fred, you seem to spend a lot of engery slamming Java and HotJava. >[ ... flame deleted ... ] > > >No, here I think Dr. Cohen's comments are right on the mark. > >The Java interpreter *is* supposed to be a trusted computing base. >Do we have any reason to believe that this trust is well-placed? > >(If you don't agree, go through the Orange Book evaluation criteria, >and pay special attention to the assurance sections...) >- --- >[This message has been signed by an auto-signing service. A valid signature >means only that it has been received at the address corresponding to the >signature and forwarded.] > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.2 >Comment: Gratis auto-signing service > >iQBFAwUBMIwG2CoZzwIn1bdtAQEpowGAgHiyk0tTQk5SO/3TR5EZRMFmUy/TjQmu >NbYIt0R/Tf0g9xWbolm5XN0alu947uJs >=UZH0 >-----END PGP SIGNATURE----- Sorry abopt the above flame-war I caused. My point was almost benign in and of itself. Yes, the Java concept is sound, No, the currently available implementation has some real architectural considerations that must be addressed in order that we can build a stable and secure platform atop it. My real issue is that there is so much time spent on this list knocking the individual spokes that make up this wheel we call Electronic Commerce, that it is more and more costly to filter out the technology from the background noise. Still because of the value of that technology, I and others are forced to spend precious hours reviewing all that comes across our desks. Bluntly being an active member of several Security and Payment Mechanism working groups I view some 150+ pieces of email a day and sometimes get frustrated by the amount of noise, or the roar in the background, about what are to the largest percentage of us, meaningless dribble... Still there is the occaisional golden nugget that makes it all worth while.. Again My apologies to have stirred up this mess. I will retreat under my desktop from the mele' that seems to be unending. Todd Regards, T. S. Glassey Chief Technologist Looking Glass Technologies todd(a)lgt.com (415) 324-4318 -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB1AwUBMFu5E6gNRnWhagU5AQHI+gL+Mwpcd3lAWd8FF06qcG6rnLhIYveHW71a XC7xh1T0uu8qnYX31yMp17OG28jWpKUbWec1IM9/eXOi+gInA7rKICWczV8zo9Z0 0puxjRRN7yO4KfRb3cPpk+r0p6pDg01Y =bTYb -----END PGP SIGNATURE-----

1 0

RE: Verification of Registration
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Scott Brickner[SMTP:sjb@universe.digex.net] Sent: Tuesday, October 24, 1995 2:09 PM To: x85849i1 Cc: cypherpunks Subject: Re: Verification of Registration "Raymond Val" writes: >Lynne L. Harrison writes: > >> Curious. Did anyone else receive this unsolicitated *invitation*? > >Everybody who receives mail from cypherpunks(a)toad.com received this >message becuase the message was addressed to >cypherpunks(a)toad.com. Apparently someone may have >joined this 'group' or service and used the cypherpunks address as >the e-mail address. Mayhap the cypherpunks(a)toad.com / cypherpunks >userid/password. > >This would be my guess, of course. Mine too. > >Does anybody know what this service does? C|NET Central is a cable TV show which reports on the 'net. The service is their on-line address where you can get more details on stuff they report. Doesn't seem to be especially c-punks related, but I guess someone didn't like the idea of having to reveal his identity just to look at a web page. You can probably assume that the password for the "cypherpunks" userid on the server is either "cypherpunks" or "writecode".

1 0

RE: Hash collisions [was Re: MD5 weaknes
by agermain＠cmp.com 17 Dec '03

17 Dec '03

I have unsubscribed from this mailing list. Please remove my name from your personal address lists. Thanks. ahg3 ---------- From: Matt Blaze[SMTP:mab@crypto.com] Sent: Tuesday, October 24, 1995 3:02 PM To: hallam Cc: cypherpunks Subject: Hash collisions [was Re: MD5 weakness ? ...] > >>As to weaknesses, I seem to remember that someone managed to forge a >>modification to a program used to observe networks on a Sun so that it >>had the same MD5 checksum as the official trusted version. But whether >>this is real is not strictly the issue. > >Ron has not mentioned such an event to me and if that were the case I would >seriously doubt that he would not have been told about it. The only comment he >generally makes is that he wrote MD5 because "MD4 was making me nervous". > >>In the case of the trust being placed in MD5 by Netscape, the assumption >>being made (without adequate support as far as I can tell) is that an >>MD5 checksum cannot be forced, through a chosen plaintext attack, to > >Netscape do not simply use the MD5 of the message, they are using (as I >understand it) the PKCS#1 standard for makoing the signature. If not they >probably have severe problems. > >>There has been no limit given by anyone on this list to the level of >>trust they place in MD5. Several people have posted (without >>contention) that MD5 is sufficiently trustworthy to trust billions of >>dollars in commerce to it's being able to prevent a selected plaintext >>attack as eluded to above. > >NIST and the NSA trusted MD4 sufficiently to base SHA upon it. SHA is preferab le >in many ways to MD5, it has a different approach to extending the scheduling a nd >resist differential cryptanalysis. There is a problem with the compressor >function of MD5 which I dislike. This is fairly irrelevant though since SSL >allows other digests to be used. > > Phill I hesitate to jump in to this exchange given the defensive and vague nature of the discussion, but... While I agree that SHA seems preferable, for a number of reasons, to MD5, it is worth noting that Hans Dobbertin of the German Information Security Agency recently found a collision in MD4. His attack allows you to generate a pair of plainexts that generate the same hash. A fast technique for finding a second plaintext that hashes to some given value remains an open problem with MD4 (and SHA and MD5, for that matter). As far as I can tell the attack does not readily generalize to MD5 or SHA. -matt

2 1