December 2003 - cypherpunks-legacy

Strong encryption for credit cards only
by monty.harder＠famend.com 17 Dec '03

17 Dec '03

H > There are many aspects to privacy beyond credit card numbers. The bottom "Jane goes to dance class Wednesdays from 4:30 to 5:30. And since Madame Sophia's School of Dance is just a few blocks away from Johnson Elementary, she can walk." tells that pedophile (and we know that the Internet is just =filled= with them, thanks to Marty Rimm's Definitive Study on the subject) exactly where he can lie in wait for his next victim. We need strong crypto to protect The Children!<tm> from such threats. Hillary and the rest of the Children's Defense Fund-amentalists should be in the vanguard of this Just Cause. * Encrypted just to pixx off Louis Freeh: mQCNAiqxEn0AAAEEAM0fi4K4+iXI9fV0fz0n --- * Monster(a)FAmend.Com *

1 0

Sun's buggy MD5?
by michael shiplett 17 Dec '03

17 Dec '03

Here's something fun to do on Solaris 2.3 or 2.4. Notice the similarity among the Solaris md5 output. Anyone know why this is? The Sun service folk weren't able to point me to a Solaris bug-report email address. I had a similar experience looking through www.sun.com. Pointers are welcomed. PROBLEM: A program which uses md5 from a dynamically linked (or loaded) library and the nsl library is loaded before a ``standard'' md5 library will get md5 results different from the rest of the non-Solaris world. NOTES: the non-Solaris md5 files are from RFC 1321. some test output has been deleted as it does not fit nicely on a standard message line. solmd5 seems to give slightly different output on different machines and greatly different output with different compilers the nsl library is required on Solaris 2.4 when using sockets. /usr/include/sys/ppp_chap.h includes a slightly modified---mainly names---version of md5.h. % gcc -o md5 mddriver.c md5c.c % gcc -o solmd5 mddriver.c -lnsl % ./md5 -x MD5 test suite: MD5 ("") = d41d8cd98f00b204e9800998ecf8427e MD5 ("a") = 0cc175b9c0f1b6a831c399e269772661 MD5 ("abc") = 900150983cd24fb0d6963f7d28e17f72 MD5 ("message digest") = f96b697d7cb7938d525a2f31aaf161d0 MD5 ("abcdefghijklmnopqrstuvwxyz") = c3fcd3d76192e4007dfb496cca67e13b MD5 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") = d174ab98d277d9f5a5611c2c9f419d9f % ./solmd5 -x MD5 test suite: MD5 ("") = f00001c0effffba8429b59d50529097c MD5 ("a") = f00003c0effffba8aec5fcf4284a8dbe MD5 ("abc") = f00005c0effffba896fc8af8ca60a911 MD5 ("message digest") = f00007c0effffba8f373218f317a9558 MD5 ("abcdefghijklmnopqrstuvwxyz") = f00009c0effffba896b4f24acb3f4738 MD5 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") = f0000bc0effffba8cef237a614aa457d michael

1 0

Re: Certificates/Anonymity/Policy/True Names
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:47 PM 8/18/95 -0400, Michael Froomkin writes about CAs, and asks why a CA or customer would want a certificate for a pseudonym without any identification or True Name. >given that the recipient of a digital signature will easily be >able to check the value of the certificate (nil), won't the >transaction/communication be in all ways identical to one where there was >no certificate at all. So is anything of value lost by prohibiting such >a certificate? It's useful for a couple of reasons 1) Continuity - For a single transaction, it doesn't make much difference; for multiple transactions/communications it does. If you want to use the nym JohnDoe, and you register with keys.com, you can do repeated transactions (e.g. posting to the net) as JohnDoe/keys.com, and nobody can impersonate you as long as keys.com doesn't allow duplicates. This allows people to build reputations under pseudonyms, and do repeat business or have readers bother to read their postings. Without certification (whether web-based or hierarchy-based), you're stuck with always posting your messages with a given key and hoping people can decide whether they've really got yours or some other JohnDoe. Our local Black Unicorn is this way - few of us know his True Name, but his reputation is established. On the other hand we can't really tell if the many postings by the L-Name are from a single person, a cooperating group, or imposters who decided it would be fun to borrow his reputation for the day. Tim May has occasionally proposed that the key is really all that matters, and that the name tacked onto it is just an untrustable convenience, but I'd say that certification does increase that convenience by adding some trust. 2) Policy-vs-Mechanism - Realistically, there'll be software out there that wants an Official CA-approved certificate to talk to anyone. If nobody's willing to give certificates to nyms, then nyms can't participate. 3) What's your definition of "prohibit"? If you mean "Keys.com decides not to offer the service", they lose the cash they might have made selling certificates to nyms, lose some customer goodwill, but maybe gain an improved reputation in other parts of the market, and JohnDoe can always go to Nyms-R-Us.org and register as JohnDoe32767. If you mean "the government should ban it", I've done enough anarchist ranting about how that sort of thing degrades society :-) However, if you mean "The Certificate Authority Cabal should agree not to offer any certificates without real ID and contractually forbid lower-level certifiers to do it either", well, it's a sad thing for society, but they can do it if they want. You lose the ability to participate as a nym, you lose privacy, you lose the value that you might have gained by transactions with people who wanted to retain their anonymity. RSA does offer personna certificates to unauthenticated people. (Also see my follow-on message about my offer to sign PGP keys for nyms.) 4) Are there negatives about dealing with unattributable pseudonyms? Of course. But you don't have to deal with them, and there will be CAs who don't, and services that refuse to deal with unauthenticated pseudonyms, just as there are on-line services like the Well that allow "unlisted" identifications but do keep track of true names for their users. It would be nice if certification authorities did indicate how much trust they have in the identity of a given key's owner, but markets will take care of that. Thanks; Bill Stewart #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #--- "The fat man rocks out Hinges fall off Heaven's door "Come on in," says Bill" Wavy Gravy's haiku for Jerry

2 1

Re: Certificates/Anonymity/Policy/True Names
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:47 PM 8/18/95, Michael Froomkin wrote: >I have a question which is of course purely hypothetical. > >Suppose you were designing the legal framework that would govern the >operation of Certification Authorities (the people who issue certificates >vouching for public keys used for digitial signatures), called CAs for >short. The CAs will operate in a hierarchical model (not a >PGP-web-of-trust model), with a state agency being at the root, and >issuing certificates for private CAs. I don't see any basis for having a state agency as the root...lots of things that are grounded in law have no origin/connection to the state. But, I'll assume your hypothetical (though I think the assumption that government = root leads down a dangerous path). >You have decided to allow the private CAs to issue certificates of varying >degrees of corroberation so long as the degree of verification used is >deducible from the certificate. E.g. a certificate might say "we check >the passport"; or "we check driver's license" or "we took blood, hair, >fingprint, retinal scan and first-born child". It might even say "we >checked nothing". You have also decided that a CA may issue a certificate >in the name of a pseudonym, so long as the CA retains information about >the True Name. Now the issue arises as to whether one should allow the CA >to issue certificates to pseudonyms where it has *no record* of the real >identity of the person proffering the key pair. It all depends on what the purpose of certification is in the first place, and whether alternative heierarchies of certification exist outside the one that has government as root. For example, I may instantiate many keys for use in experiments, or as agents in a market microworld, and I may "vouch" for them. These "agents" have no True Name, are not persons, but still have varying levels of certification (to me, at least) A company may even have multiple agents. Multiple departments, multiple users, etc. The web-of-trust model, which, loosely phrased, says "I say I believe this is the key of so-and-so, and you can believe me or not. We don't need no steenking badges!" The beauty of this is that any person or program can generate lots and lots of keys, for experiments, agents, etc. Now if it is desired to have the "legal system" mesh with this certification process, the governemnt is still not needed. Contract law suffices. If the Alice Corporation claims the Bob Company signed a document with a fraudulent key )or whatever the scenario might be), then each side can present in a court what the contracts they agreed to said and what the facts were. This happens all the time, though "I am not a lawyer," in disputes about whether a contract was signed properly, about whether the signer had the right authority, etc. And it is apparently not necessary to have the "state" establish itself, for example, as the keeper of signatures. I concede that there is a path back to the legal "is-a-person" status of parties, such as credentials for identity. In cases involving software agents and "virtual persons" (which is where key certification tends to come in), a stipulation can be made that a Real Person is to be involved in the loop. >Is there any reason why a person would want such a certificate? In other >words, given that the recipient of a digital signature will easily be >able to check the value of the certificate (nil), won't the >transaction/communication be in all ways identical to one where there was >no certificate at all. So is anything of value lost by prohibiting such >a certificate? So long as I am not prohibited from getting together with others (on a list like our, in a corporation, with offshore folks, etc.) and setting up our own system--of whatever nature--then I suppose it doesn't matter. But you ask "So is anything of value lost by prohibiting such a certificate?" Well, why prohibit something unless a real and compelling problem exists? it might turn out to be very useful to have certificates even for keys that belong to entities or agents that have no True Name attached to them. I've given some examples, and can think of more. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net (Got 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."

2 1

Economic Model for Key Cracking
by cman＠communities.com 17 Dec '03

17 Dec '03

So far, list members have mostly presented two points of view on the economics of key cracking: o It's free, since it uses spare CPU cycles o It should be priced at the cost of the dedicated computer hardware needed to do it. Both of these approaches are wrong. The first approach fails because it doesn't scale -- there probably aren't enough people willing to crack lots of keys purely for the research interest, hack value, or the goodness of their heart. At the same time, many people and companies have lots of unused CPU time on their hands. Economically, this CPU time is scrap material -- and there are companies out there that do nothing but buy up scrap equipment for pennies on the dollar. Therefore it should be possible to create a market in spare CPU cycles for tasks like this that require massive parallel computing. An earlier suggestion for bounties on keys (basically the Chinese lottery approach) is a step in this direction. I'd also like to point out that a hacker who can sniff out SSL-encrypted packets on a hacked network is going to be vastly harder to catch than someone who trolls through his or her physical community dumpster diving and bribing clerks. The ability to anonymously gather and decrypt credit card numbers has a vastly lower "cost" in terms of likelyhood of prosecution. If it drops down to under $100 per key, it's probably at a good break-even point to do it wholesale. Certainly the out-of-pocket cost of cracking a 40-bit SSL key is less than that right now for a great many people, even without creating a market.

3 2

Re: Exportable if Escrowed Changes Nothing!
by Joey Grasty 17 Dec '03

17 Dec '03

Anonymous wrote: > Joey Grasty writes: > > Governments: can't live with 'em, can't shoot 'em. > ^^^^^^^^^^^^^^^ > > It is precisely this kind of self-defeating pessimism that has allowed > the current state of affairs to develop. > > You grossly misinterpreted my remark. I believe that socialist-statism exhibited by the current US gov't is about to crack due to overspending and technology. Whether it will go peacefully or not is another question. I stand ready to defend myself if necessary, but I prefer to kick the statists in the ass by deploying strong encryption. When information can flow, the statists lose. They know that; witness the frantic effort to outlaw encryption. Too late, though. I'm writing code to hasten the end of the statists. Just what are you doing besides hiding behind anonymity? Regards, -- Joey Grasty jgrasty(a)gate.net [home -- encryption, privacy, RKBA and other hopeless causes] jgrasty(a)pts.mot.com [work -- designing pagers] "Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin." -- John Von Neumann PGP = A7 CC 31 E4 7E A3 36 13 93 F4 C9 06 89 51 F5 A7

1 0

Time-memory tradeoff in SSL's RC4 code?
by JMKELSEY＠delphi.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Thu, 17 Aug 1995 08:32:56 -0400 >From: "Perry E. Metzger" <perry(a)piermont.com> >Subject: Re: SSL challenge -- broken ! >It has occured to me that, because the RC4 key crackers spend most of >their time in key setup, you can crack N SSL sessions that you >captured in not substantially more time than it took to crack 1. This >is analagous to the way brute force Unix password file hacking operates. This would work with straight 40-bit keys, but I believe SSL uses 128-bit keys, and then intentionally leaks 88 bits to comply with export requirements, to prevent this kind of attack from working. >Perry --John Kelsey, jmkelsey(a)delphi.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMDVGXUHx57Ag8goBAQFyUQP7B7fhKc8AqpcHnQ09ip5gOfy5QMCtGImB f1Y9lZtAmLFwOIkrfdaL2vCWJKIKc7yg8+FwtmX6Q8yYWH4TdE5eWOGIKSfl5Q8f etVgF2B49T5Lxxb02ah5cHfO8baOqQOTMkvzQ9bj0XVqAItPoPjDTCOAAegwKZ3V 6L+kZQn89lY= =KkAX -----END PGP SIGNATURE-----

1 0

Export policy change
by JMKELSEY＠delphi.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Thu, 17 Aug 1995 23:48:01 -0400 >From: Rich Salz <rsalz(a)osf.org> >Subject: Export policy change >Just heard on the 11:30pm NPR news update. The Clinton Administration >has changed the crypto export policy. You will now be allowed to >export strong crypto, provided it is a key escrow system. The >reporter (Dan Charles?) said something like anyone can hold the keys, >as long as they will be made avail when presented with a court order. >He also said, US citizens will still be able to use strong crypto >without key escrow internally. Terrorists and drug pushers were given >as "reasons." I think this is an important and somewhat subtle political move on the part of the administration. If they can get at least a few large businesses (the ones who buy into the key-escrow scheme) on their side, by making it in their economic interests for everyone to use escrowed crypto, they will have manufactured some potentially powerful allies in the computer industry. Certainly, once any major company has spent a lot of money to set up a key escrow facility, they will help lobby *against* any easing of the requirement to use escrowed crypto, based simply on self-interest. --John Kelsey, jmkelsey(a)delphi.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMDVGZUHx57Ag8goBAQEutQQAmM/qEIAlLklDRW/FVvLah7vgY6lYcCK/ XToA79tVZNmy+8U/XjS2g6+Ffsc/gQflOdg/ZmewDOQRJ4YI+BzHUjKL5NVDWAUA /4+ySWxcAAEOD23GhS9p/iFN/Gbe0oV9JIQ2HCpPN929VaRl7J+1fWA/ETZkB914 ClJPlXqa1xo= =XefF -----END PGP SIGNATURE-----

1 0

Anonymous certificates
by JMKELSEY＠delphi.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >Date: Fri, 18 Aug 1995 14:47:55 -0400 (EDT) >From: Michael Froomkin <mfroomki(a)umiami.ir.miami.edu> >Subject: Certificates/Anonymity/Policy/True Names >Now the issue arises as to whether one should allow the CA >to issue certificates to pseudonyms where it has *no record* of the real >identity of the person proffering the key pair. >Is there any reason why a person would want such a certificate? In other >words, given that the recipient of a digital signature will easily be >able to check the value of the certificate (nil), won't the >transaction/communication be in all ways identical to one where there was >no certificate at all. >So is anything of value lost by prohibiting such >a certificate? There are definitely cases where something is lost by prohibiting that kind of certificate. For example, there may be cases where a certified key gives someone some right that doesn't need any further identification, such as a right to run up $100 in phone bills, or a right to receive a year's subscription to cp-lite. As long as the person has paid for that right, who cares who he or she is? In other words, you may wind up sometimes binding a key to a function, rather than a person. >A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) >Associate Professor of Law | mfroomki(a)umiami.ir.miami.edu >U. Miami School of Law | >P.O. Box 248087 | It's hot here. And humid. >Coral Gables, FL 33124 USA | --John Kelsey, jmkelsey(a)delphi.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMDVGbUHx57Ag8goBAQHO/AP+IM1YQSXZWaysjDALtOljqUEiyiCBA3EM Wxd8dp0dVrXKEii1Ima/xLHMKY4P0fvwT3oQl4x+mMo+ED2lNHo5GOUhgkE1tOZ8 6JfnUS6+l1Y4r14Aq0eMLljrOKFBDDUxewJTRaz36awWNr9W0tEcnnKv9NwQMU// CCKR6L5fekI= =EI6V -----END PGP SIGNATURE-----

1 0

Re: Certificates/Anonymity/Policy/True Names
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 1:26 AM 8/19/95, Michael Froomkin wrote: >Bill Stewart asks what follows from "prohibit". In the model I am, um, >hypothesizing, CAs that play by the rules are entitled to certain safe >harbors shielding them from potential liability (e.g. can't be sued if >their certificate was used in a transaction that went bad through no >fault of theirs). No other behaviour or act is banned, but other, >private, alternatives may suffer a coompetitive disadvantage since they >would lack the certainty that they could not be sued. Then I suggest you use a different word than "prohibit." To many of us, this implies illegality, men with guns, early morning raids, and Janet Reno. You don't seem to mean this. By the way, is this really just an excercise, or are you perchance involved in the goings-on with policy on crypto? (Not making any accusations, just noting that various crypto policy groups are reported to be meeting...the National Research Council thing, the key escrow initiatives, etc.) Encrypting minds want to know. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net (Got 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."

1 0