December 2003 - cypherpunks-legacy

REMINDER: SAFE Forum Cybercast - Monday July 1, 12 noon - 6 pm EDT
by Bob Palacios 17 Dec '03

17 Dec '03

SECURITY AND FREEDOM THROUGH ENCRYPTION FORUM MONDAY JULY 1, 1996 STANFORD, CA 9:00 am - 3:00 pm PDT / 12:00 noon - 6:00 pm EDT / 1600 - 2000 GMT On July 1, 1996 in the heart of California's Silicon Valley, members of Congress and prominent computer industry leaders and privacy advocates will meet to discuss the need to reform U.S. encryption policy. The SAFE Forum will bring together members of Congress, privacy advocates, cryptographers, and industry leaders for a discussion on the need to reform U.S. encryption policy. If you can't attend the SAFE Forum in person, you can still participate by attending the cybercast of the event. The cybercast will include still photos of the conference, a RealAudio broadcast of the forum, and a telnet chat room for netizens to discuss the event and cryptography issues. Just visit the SAFE Forum web site on Monday for the necessary links: http://www.crypto.com/safe/ (You will need to be a copy of RealAudio installed on your computer. Visit http://www.realaudio.com/ for a FREE copy of Real Audio). The SAFE Forum Cybercast is brought to you with the help and support of: MediaCast (http://www.mediacast.com/) and AudioNet (http://www.audionet.com/) --------------------------------------------------------------------------- Event Information * Location: Kresge Auditorium at Stanford University, Stanford, California * Date: July 1, 1996, 9:00 am - 3:00 pm Program: 9:00 - 9:15 Welcome Rep. Anna Eshoo (D-Ca), co-host Rep. Tom Campbell (R-Ca), co-host Sen. Patrick Leahy (D-Vt) (by satellite) Jerry Berman, Center for Democracy and Technology 9:15 - 10:15 The Need for Locks and Keys on the GII: An Encryption Overview Marc Andreessen, Netscape Communications Lori Fena, Electronic Frontier Foundation Eric Schmidt, Sun Microsystems Craig Mundie, Microsoft Corporation 10:15 - 10:30 Technology Demo: The Need for Locks & Keys -- Packet Sniffing on the Internet (Cylink Corporation) 10:30 - 10:45 Break 10:45 - 11:45 How U.S. Encryption Policy Fails to Meet User Needs Herbert Lin, National Research Council Jim Omura, Cylink Corporation Tim Oren, CompuServe Incorporated Phil Zimmermann, PGP, Inc. Todd Lappin, Wired Magazine -- Introducing "Stories of Real-Life Encryption Users" 11:45 - 1:00 Lunch 1:00 - 1:45 The Cryptographers' Report: "Forty Bits Is Not Enough" Matt Blaze, AT&T Whitfield Diffie, Sun Microsystems Bruce Schneier, Counterpane Systems Eric Thompson, Access Data Tom Parenty, Sybase Technology Demo: The Genie is Out of the Bottle -- A World Wide Web Tour of Good Cryptography Available Outside of the United States 1:45 - 2:45 Addressing Law Enforcement Concerns in a Constitutional Framework Ken Bass, Venabel, Baetjer, Howard and Civiletti Cindy Cohn, McGlashan & Sarrail Michael Froomkin, University of Miami Law School John Gilmore, Electronic Frontier Foundation Grover Norquist, Americans for Tax Reform Nadine Strossen, American Civil Liberties Union Daniel Weitzner, Center for Democracy and Technology 2:45 - 3:00 Conclusion Members of Congress expected to participate include: * Rep. Anna Eshoo (D-CA) * Rep. Tom Campbell (R-CA) * Rep. Zoe Lofgren (D-CA) * Sen. Conrad Burns (R-MT) * Sen. Patrick Leahy (D-VT) (by satellite) --------------------------------------------------------------------------- Sponsors Of The SAFE Forum: America Online American Civil Liberties Union Americans for Tax Reform AT&T Audionet Business Software Alliance Center for Democracy and Technology Center for National Security Studies Commercial Internet eXchange CompuServe Incorporated Computer and Communications Industry Association Computer Professionals for Social Responsibility Cylink Corporation Digital Secured Networks Technology EDS Electronic Frontier Foundation Electronic Messaging Association Electronic Privacy Information Center Information Technology Association of America IEEE - USA ManyMedia MediaCast Media Institute Microsoft Corporation National Association of Manufacturers Netcom Online Communication Services Netscape Communications Corporation Novell, Inc. Oracle Corporation Pacific Telesis Group Pretty Good Privacy, Inc. Prodigy, Inc. Progress and Freedom Foundation Rent-a-Computer Securities Industry Association Software Publishers Association Sun Microsystems, Inc. Sybase, Inc. Voters Telecommunications Watch Wired Magazine --------------------------------------------------------------------------- CORRECTION An earlier Policy Post listed Matt Blaze with Lucent Technologies. That information was incorrect; he is with AT&T Research. ---------------------------------------------------------------------------

1 0

MD5 breaks, etc.
by Perry E. Metzger 17 Dec '03

17 Dec '03

1) On the question of MD4, it has been demonstrated that one can generate multiple documents with the same hash -- an example was given in a paper a while back of two contracts, identical but for the dollar sum agreed two, with identical MD4 hashes. That demonstrates that MD4 is useless. 2) Hans Dobbertin on May 2nd released a short paper that circulated widely on the net describing collisions in the MD5 compression function. Several people have asked me for references on this. I cannot give you anything -- all I have is postscript of the document, which had not been published in any journal when I last checked. However, the result is widely known. MD5 is *not* something that should be trusted going forward, and I hope the next version of PGP uses SHA-1. Perry

1 0

Re: rsync and md4
by David F. Ogren 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Subject: Re: rsync and md4 To: perry(a)piermont.com, ogren(a)cris.com Cc: markm(a)voicenet.com, Andrew.Tridgell(a)anu.edu.au, cypherpunks(a)toad.com > > "David F. Ogren" writes: > > Are you sure? MD5 is a 128 bit hash, and the probability of collision > with > > a specific random piece of data (of any length) should be 2^-128. I > could > > be wrong, but do you have any explanation of why you think the answer > is > > 2^-64. > > Does the phrase "birthday attack" mean anything to you? But this isn't a birthday attack. Its a comparison between one specific file and one randomly chosen one. > > MD4 is the fastest hash I am aware of. However, there has been some > > successful attacks against two rounds of MD4. Although this is not to > > suggest that MD4 is insecure, MD5 almost as fast (~1.3 times slower) > and > > more secure. > > I'm afraid you are totally wrong here. MD4 has been completely > broken. I wouldn't trust it for anything. In fact, MD5 is no longer > trustworthy, either -- it was broken recently. Stick to SHA. > Unless you are aware of some attack that I'm not, this is the most current information on MD4 and MD5: MD4 has had successful attacks on limited rounds. It has _not_ been completely cracked. MD5 has not been broken. A weakness has been shown, but collisions still cannot be developed. So checksums should still be secure. Additionally, in this case we are more concerned with the chance of random collisions than intentional collisions. In fact, I was probably wrong to suggest MD5. It _is_ more secure, but speed is his first priority, not security. SHA1 is a good hash algorithm as far as security goes (I've used it myself), but it's over three times slower than MD4. - -- David F. Ogren | ogren(a)concentric.net | "A man without religion is like a fish PGP Key ID: 0x6458EB29 | without a bicycle" - ------------------------------|---------------------------------------- Don't know what PGP is? | Need my public key? It's available Send a message to me with the | by server or by sending me a message subject GETPGPINFO | with the subject GETPGPKEY - -- David F. Ogren | ogren(a)concentric.net | "A man without religion is like a fish PGP Key ID: 0x6458EB29 | without a bicycle" - ------------------------------|---------------------------------------- Don't know what PGP is? | Need my public key? It's available Send a message to me with the | by server or by sending me a message subject GETPGPINFO | with the subject GETPGPKEY -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMddOi+SLhCBkWOspAQHLTgf7BsDpCO2nhxsHYOunVv8abXWgITexhM/Z vmYWaz2Lgu3tBYZHXIG7B2ijTikZ7u8RgMGd9esipjFxOks1bHRQwYbVbWeDUDb3 O0c5TmPPmZt/7PscUEw1D3hhtj8HeGmn9pfu0y/I54OnMIJzbvNMICpMtLLDXJCu PhpUoAfamyRdWl9OYAvZ3LBMLBdGagzCh/jPxCQ9gEBq0aYMkxF1/qlfIMdmegow H/uL+TRgN5roTIKDZPGPZWYbdLbf0NT00avPz5qKaA5BkOpxYgeRKtoBHdYC5krH O2NZGZqb5LRKgxW9+IvCWoUoJQTB6IXP+YDU7p4pbn/Y/QORSHzqGA== =WA0Y -----END PGP SIGNATURE-----

2 1

Re: rsync and md4
by David F. Ogren 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > > "David F. Ogren" writes: > > > I'm afraid you are totally wrong here. MD4 has been completely > > > broken. I wouldn't trust it for anything. In fact, MD5 is no longer > > > trustworthy, either -- it was broken recently. Stick to SHA. > > > > > > > MD4 has had successful attacks on limited rounds. It has _not_ been > > completely cracked. > > Could you please quit spewing inaccurate information? > > Dobbertin completely cracked MD4 already, and found MD5 collisions in > a document circulated on May 2nd that mean it isn't far behind. > > The comments you are making are dangerous because they encourage > people who don't know better to think that hashes which are known > unsafe are safe. Please quit posting until you start monitoring the > field enough to have accurate sources of information. > I stand by my statements. I have followed the current developments regarding MD5 with interest, and am using SHA1 in the program that I am currently authoring because of its MD5's weaknesses. However, MD5 (and MD4) have not been completely cracked. The problems that you bring up have to do with situations where an active attacker develops a slightly different pair of documents with the same hash. Although this is highly undesirable characteristic for a hash function, and shows a weakness in the function that may eventually lead to its being completely cracked, it does not mean that a fraudulent document can be created from an already signed document. This is an old argument and I don't want to get into it here. However, there a lots of people that who still think MD5 can be safely used to a) sign documents that you create yourself, and b) sign documents that you have made cosmetic changes to. Irregardless, this argument is moot. This thread is titled "rsync and md4". It is a discussion about which hash function suits this particular purpose and he is not particularly concerned with resistance to deliberate attack. In this case MD4 will function adequately. - -- David F. Ogren | ogren(a)concentric.net | "A man without religion is like a fish PGP Key ID: 0x6458EB29 | without a bicycle" - ------------------------------|---------------------------------------- Don't know what PGP is? | Need my public key? It's available Send a message to me with the | by server or by sending me a message subject GETPGPINFO | with the subject GETPGPKEY -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMddp3uSLhCBkWOspAQEI1Qf/VLg6ak6Y/VfbynFhCcA69RZKAQ/C6pCx DMdz3OFitOwQM/csjTPBs7jue/3ArIQ+jevBOjp/NyAoJ4U8+Np4yv7ksmpEjTKq EWq4DcvAB7MgpgJ72A92tO55vQo8AjYPmcZT2LhqeiTg+R6yL437T4gqS0ZSs7Ud 7e1anp7m72shSel6OKsxtfgiyVDlVi6mdtpXlLegWxcZhPaRYaZen3mHJ3JdxCpc EsQupdrNVxBGMuxKeBwlkjCxD1TbqFpHTodh0oapEDScjpzTMmQeHYavmboI+Pys 32jt1PI9JEPIDracYcI3ovkgvR5VmMlKhAPDXcYbr2MWeBbVRDOaJw== =9dqv -----END PGP SIGNATURE-----

4 6

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ksub"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.jpunix.com> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"treehole"} = "<remailer(a)mockingbird.alias.net> cpunk pgp hash latent cut ek"; $remailer{"nemesis"} = "<remailer(a)meaning.com> cpunk pgp hash latent cut"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"vegas"} = "<remailer(a)vegas.gateway.com> cpunk pgp hash latent cut"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"ncognito"} = "<ncognito(a)rigel.cyberpass.net> mix cpunk pgp hash latent"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash latent cut ek"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Groups of remailers sharing a machine or operator: (c2 alpha) (flame replay) (alumni portal) Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. Note: The remailer list now includes information for the alpha nymserver. Last update: Mon 1 Jul 96 6:47:34 PDT remailer email address history latency uptime ----------------------------------------------------------------------- flame remailer(a)flame.alias.net +++++__.-++- 10:04:50 100.00% alumni hal(a)alumni.caltech.edu #######*+*## 1:13 100.00% ecafe cpunk(a)remail.ecafe.org ####*#+--##* 14:24 99.98% replay remailer(a)replay.com *********+** 4:18 99.98% nemesis remailer(a)meaning.com +**** 23:43 99.98% c2 remail(a)c2.org ++++++++-+++ 51:58 99.97% portal hfinney(a)shell.portal.com +#######+*## 1:24 99.95% haystack haystack(a)holy.cow.net *-+#++++###+ 9:25 99.94% exon remailer(a)remailer.nl.com ++*******+** 5:49 99.94% lead mix(a)zifi.genetics.utah.edu ++++++++++++ 39:16 99.94% nymrod nymrod(a)nym.jpunix.com ** ****#+#-# 12:31 99.92% mix mixmaster(a)remail.obscura.com __.-_.-.--- 18:42:17 99.88% treehole remailer(a)mockingbird.alias.net +++ -..+++-+ 5:28:11 99.24% amnesia amnesia(a)chardos.connix.com ----------- 4:20:06 99.22% penet anon(a)anon.penet.fi __ _-..... 44:52:17 99.20% extropia remail(a)miron.vip.best.com --.-------- 5:15:59 97.93% ncognito ncognito(a)rigel.cyberpass.net -.___.-._ 22:24:17 97.35% alpha alias(a)alpha.c2.org ******-+++** 38:56 96.99% jam remailer(a)cypherpunks.ca * 19:19 96.68% lucifer lucifer(a)dhp.com +++ 56:06 95.20% vegas remailer(a)vegas.gateway.com #**-#*** 16:52 60.55% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

Re: Hardware RNG
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

At 06:23 AM 6/30/96 -0700, Timothy C. May wrote: > While radioactive decay is unpredictable (so are a lot of things, by the > way), there are all kinds of biases that reduce the apparent entropy. > Detector "dead time" is a classic one (basically, the detector can't detect > counts during a post-pulse recovery time...probably not a problem at low > count rates, but an example of how subtle things can sneak in). If he has more than eight bits of timing resolution, such biases will have no affect. He is using his non uniformly distributed random number to select a uniformly distributed pseudo random number. Provided that the does not attempt to get more entropy out than he puts in, the result should be a uniformly distributed truly random number. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

FTS2000 Security Info and RFP
by Mark O. Aldrich 17 Dec '03

17 Dec '03

The URL's for FTS2000 RFP, Security Policy data, and assorted sundries are: http://post.fts2k.gsa.gov/ (the official government stuff) http://204.70.134.242/policy/ (This appears to be an MCI server and I don't know if they know that this stuff is online) Enjoy. ------------------------------------------------------------------------- |Just as the strength of the Internet is |Mark Aldrich | |chaos, so the strength of our liberty |GRCI INFOSEC Engineering | |depends upon the chaos and cacophony of |maldrich(a)grci.com | |the unfettered speech the First Amendment|MAldrich(a)dockmaster.ncsc.mil | |protects - District Judge Stewart Dalzell| | |_______________________________________________________________________| |The author is PGP Empowered. Public key at: finger maldrich(a)grci.com | | The opinions expressed herein are strictly those of the author | | and my employer gets no credit for them whatsoever. | -------------------------------------------------------------------------

1 0

Re: rsync and md4 (my final comments)
by David F. Ogren 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > > "David F. Ogren" writes: > > I stand by my statements. > > Then you have lost all your reputation with me. If you don't even have > the integrity to admit that you are wrong, you are obviously not a > reasonable source of information. > At this point, I can see that we have agreed to disagree. Mr. Watt has kindly quoted the exact text from Dobbertin, which I did not have handy. Let the readers of this list decide for themselves in regards to the security of MD5. But I wanted to make two last comments before this thread (finally!) dies. 1. I think that you will agree that MD4 will work fine for Mr. Tridgell's program, irregardless of your criticisms. He specifically stated that he was not concerned about intentional collisions, only random ones. 2. (quoted from Mr. Perry in an article entitled "MD5 breaks, etc.") > checked. However, the result is widely known. MD5 is *not* > something that should be trusted going forward, and I hope the next > version of PGP uses SHA-1. As I understand the current plans, PGP 3.0 _will_ incorporate a SHA option. In fact, I believe that there may already be "bootleg" versions that incorporate SHA. - -- David F. Ogren | ogren(a)concentric.net | "A man without religion is like a fish PGP Key ID: 0x6458EB29 | without a bicycle" - ------------------------------|---------------------------------------- Don't know what PGP is? | Need my public key? It's available Send a message to me with the | by server or by sending me a message subject GETPGPINFO | with the subject GETPGPKEY -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMdfvtuSLhCBkWOspAQGkQwf5AQTJbqJ7YQOCSaLWK7qjn0Fr0AzF9Cyb Bd2WJcHisQZ4WxwPy41SF3uUNXvgyES11rfvqa7SoqDU1QuO4N3I8PZ5+zrlwDpI 2Yb/wHyQ2jPtCVSWCmoyZfbw7a9086wWbg+N4IDuefPdgI+SqNiYmQnEsrh1+f9T L2/gC6GLXFHtl68guYTGjI3XIgHcILWkqjuo19rzw+4NXAQ3kPxTaBLGcxuMYEPl E5IbuKZ3mN4CZIDTSSctr78cthsr79KgW5NwlBW5AcCkU1XnhALVTN0vNEf2tILN jl0BdVALNbkyFdTAE7/5z6pDcThgKR/68cRrTBTRFlq1WAadXAKV8w== =drZ2 -----END PGP SIGNATURE-----

2 1

MD5 breaks, etc.
by John Hemming - CEO MarketNet 17 Dec '03

17 Dec '03

Accepting for a moment that MD5 collisions have been identified. From a commercial aspect I am concerned to ensure the cryptographic security of our ECheque system. Just a thought on the use of MD5. If two signatures are appended to the same document both using MD5, but one either a) Signing all but the last octet of the message ... or b) Signing the whole of the message and signature. Would that not make the determination of useable collisions either impracticable or impossible? I must admit I am inclined to encode additionally the key components of the message (amount paid, to whom) as well as the hash using a Private Key encryption. After all we have at least 60 octets of important data that can be encoded in this manner using one simple encryption sequence, this can cover account credited and amount easily. If someone can collision codge the description I am not desperately concerned. Alternately, could someone please point me at the SHA algorithm.

2 1

Sameer got plugged on C-SPAN
by Alex Strasheim 17 Dec '03

17 Dec '03

Janlori Goldman, at the Center for Democracy & Technology, just mentioned Sameer's anonymizer on C-SPAN during a segment of Internet privacy. They showed a shot of the screen and everything.

1 0