December 2003 - cypherpunks-legacy

Random keys ?
by A. Padgett Peterson P.E. Information Security 17 Dec '03

17 Dec '03

> This does not demonstrate that the RSA keys are as well >distributed, but it does generate some confidence that the key >generation methods of PGP are not very broken. Testing for RSA >generation would be more difficult, since there are some practical >difficulties in getting a large sample of RSA private keys. True but do not need private keys, just public ones (one to one relation), should be able to get a large sample (20,000 in one place did I hear ?) of those. Warmly, Padgett

1 0

Anonymous Web Browsers
by A. Padgett Peterson P.E. Information Security 17 Dec '03

17 Dec '03

>I took the JavaScript stuff that was posted and put it in one of my web >pages (http://students.cs.byu.edu/~don/mail2news.html) I had to pick a new >address because support(a)netscape.com is reportedly now just an autoresponder. >I've disabled java, I've changed the mail server to null (from the default >localhost) and none of it stops the JavaScript from sending mail. You did this to the *server* or the *client* ? (the latter is what I was talking about). If the client, then is Netscape/Java acting as its own mail server ? Guess I am going to have to did out a sniffer and see just what is going on... Warmly, Padgett

1 0

Re: Web of Trust vs other models
by Bill Stewart 17 Dec '03

17 Dec '03

At 09:48 AM 3/1/96 -0500, you wrote: >There are a pool of 1 million keys. Each of those keys is signed by between > two and 5 other randomly chosen keys in the pool. > Each signature implies a trust relation between the key and the signer. >Given that, determine mean, min, and max path lengths for purposes of > "certification". >Has anyone done this experiment? Probably been done, though not necessarily in a PGP context. The problem is equivalent to analyzing a randomly selected directed graph, and some Operations Research or CS grad student has probably done it. Meanwhile, Don Kitchen at one point collected all the data off the MIT keyserver for analysis, which is a much different problem than random signatures. I found that the chain from some middle point, such as Phil Zimmermann's or Derek Atkins's key was about 12-14 levels deep, averaging about 6, which compares interestingly with the default PGP depth limit of4. From my key, it was pretty deep, especially since my certification from Phil Karn was from one of his older keys, which is why I asked Derek to sign my key... #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

Win a free Apache-SSL-US Commercial license
by sameer＠atropos.c2.org 17 Dec '03

17 Dec '03

See http://apachessl.c2.org/ for more details. Thanks, -- Sameer Parekh Voice: 510-601-9777x3 Community ConneXion, Inc. FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org/ (or login as "guest") sameer(a)c2.org

2 1

Truelly Random Numbers
by A. Padgett Peterson P.E. Information Security 17 Dec '03

17 Dec '03

>The number of randomly selected 768 bit primes that you would need for a >reasonable chance of a birthday collision is 1.708E104 True however the current mechanism of generating PGP keys which consists primarily of pseudo-randomly pounding on a keyboard is hardly "truely random. Have no idea of the true number but expect it to be significantly less than that quoted above, even for a 1024 bit key like mine. Warmly, Padgett

3 2

Re: A brief comparison of email encryption protocols
by cme＠cybercash.com 17 Dec '03

17 Dec '03

At 12:01 2/29/96, Laurence Lundblade wrote: > >Isn't using a hash as the identifier replicating the key distribution >problem that PGP has or are you including some other data that can be used >to look up the cert? I think a problem occurs when you have 20 billion of >these certs (two for every person in the year 2010 or such). A simple hash >into a table isn't going to cut it because you a single database (with >replication?) isn't going to be possible. Some hierarchical lookup like >DNS is going to be needed. The look ups are needed to check for revocation. Our current straw-man http://www.clark.net/pub/cme/html/cert.html uses the following to identify a key within a certificate: KEY_ID ::= <hash of public key> [<nickname chosen by the owner>] [<URL of the full key>] It is assumed that the key is in a cache at the verifier. The verifier can add it to his cache by having it sent to him directly, by fetching it via the URL (if present), or through some other means. One of my co-workers [Donald Eastlake] is proposing distribution of keys via the DNS and that sounds fine, too. We weren't tying the distribution problem to the certificate problem. They really are separate. Revocation is a separate problem. My personal preference [quite seriously] is not to allow for revocation -- rather to issue certificates with a validity only long enough to get the job done but not so long that you'd be seriously damaged by having an invalid cert honored. There's no way to get 100%, immediate validation [by non-existence on a revocation list]. For more words on this subject, see cert.html. If one really needs CRL checking, I'd recommend including a URL for the Issuer's own revocation list as a field in the cert. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc., Suite 430 http://www.cybercash.com/ | |2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | |Reston, VA 22091 Tel: (703) 620-4200 | +--------------------------------------------------------------------------+

3 2

Re: Problems with certificates.
by Bill Stewart 17 Dec '03

17 Dec '03

At 08:35 AM 3/1/96 -0500, "A. Padgett Peterson P.E. Information Security" <PADGETT(a)hobbes.orl.mmc.com> wrote: >Today, each person generates their own PGP key. While it is unlikely that >any two will match, it is likely that at some point some two will match >(see matching birthdays in a bar - number is less than you would think). PGP KeyIDs are 8 hexes long (formerly 6), and there have been some natural collisions and it's easy to manufacture them. On the other hand, the MD5 hash used for key fingerprints is 128 bits long, and cryptographically strong. So birthday-problem collisions occur when you have ~ 2**64 keys around, which is not a problem, and you can't generate collisions on purpose either. A 64-bit hash would be more interesting; you get collisions if you have around 2**32 keys, which could actually happen. >Next rage might well be "vanity" PGP keys. While at the moment it is not known >how to create a specific match key to a sequence, if you generate enough >keys, there will be some interesting sequences found. Possibly some PGP >signatures will even be in violation of the CDA (now that should start a rush 8*). :-) The main problem is the limitations of hex; keyids like 0xdeadbeef are available, but it's tough to really trigger Exonization that way. Using 32 bits as ASCII instead is a bit more flexible. >For some time I have been concerned about the scalability of PGP. It works >well in small groups but after trying once to create a 6,000 member keyring >(took over three days on a 386 & was several meg when done) Yeah - lots of people have been concerned about this. Keyservers simplify the problem a lot, since you no longer need to carry a large number of keys around yourself, but the keyring handling mechanism of PGP wasn't designed to scale. Wouldn't be too hard to redesign, once PGP 3.0 comes out and we've got tools to do it - you could use a database or decently structured ASCII file or files. And DNS or similar distributed keyserver can make it easier to find, for people who are on-line. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

2 1

Re: Chaff in the Channel (Stealth PGP work)
by Powers Glenn 17 Dec '03

17 Dec '03

- However, I suspect that the ideal would be like cryptography: - Assume the enemy knows everything about your system but the keys. - Thus, your gifs need to look like normal gifs in the lsb. Your audio - needs to have normal levels of hiss in it. Etc. the problem with many current stego programs (jsteg/stools) is that given a data stream, they will tell you if there is data steg'ed (by the same program, of course) it in. jsteg goes out of it's way to hide it's content-length header, but jsteg can still detect jsteg headers... glenn

3 2

Re: Is there any work on entropy-lowering schemes?
by Bill Stewart 17 Dec '03

17 Dec '03

At 07:46 PM 3/1/96 -0500, Mutant Rob <wlkngowl(a)unix.asb.com> wrote: >I'm wondering if anyone has done any work on schemes to lower the >entropy of a given stream. Why? Save you've got message M encrypted >with a good cipher, but you're worried that it can be detected because >even with stego, the entropy is a lot higher than normal 'random' data >flowing through a network. Peter Wayner's work on Mimic Functions does just this sort of thing. You can describe a grammar, feed it random bits, and generate output that has the right statistics and can be reversed to get the original bits. His paper was on cs.cornell.edu a few years ago; don't know where to find it now. AltaVista yields a reference to the paper in Cryptologia, and the Cyphernomicon has the following: - "They encode a secret message inside a harmless looking ASCII text file. This is one of the very few times the UNIX tools "lex" and "yacc" have been used in cryptography, as far as I know. Peter Wayner, "Mimic Functions", CRYPTOLOGIA Volume 16, Number 3, pp. 193-214, July 1992.[Michael Johnson, sci.crypt, 1994-09-05] (When I read the Cryptologia reference on my browser, I don't get the ligature in the middle of "Huffman coding"; YMMV. :-)

2 1

Report on Privacy Enhancing
by jya＠pipeline.com 17 Dec '03

17 Dec '03

Does anyone how to get a copy of the report on "privacy enhancing technologies - the path to anonymity" cited in this paper from the Canberra/OECD conference on Feb 7-8: http://www.nla.gov.au/gii/oconnor.html Issues Facing Government : Meeting Public Concerns Kevin O'Connor Privacy Commissioner, Australia [Giant snip] In my own sphere of activity, there is some discussion taking place over the potential of new technologies and applications to assist with privacy protection. A recent report from the Dutch and Ontario Privacy Commissioners entitled Privacy enhancing technologies - the path to anonymity, offers some intriguing suggestions about the potential of public key cryptography for use in digital signatures to act as 'identity protectors' - allowing transactions to be completed and accounted for without the true identity of the participants needing to be known. While there are some obvious concerns about such technologies from a law enforcement perspective, which we have already heard about from the previous speaker, these should not be insuperable obstacles. On the other hand, the registration of digital signatures and public keys, with sufficient integrity to gain commercial and governmental confidence, itself raises additional privacy concerns. The complex issues involved are only just starting to be addressed. ... ----- Encouragingly, another paper by Matthew Bowcock http://www.nla.gov.au/gii/bowcock.html states: [Big snip] Controls on Encryption Technology There has been much heated debate worldwide about restrictions on the use of encryption technology, so that law enforcement and national security agencies can continue to intercept communications. Two questions are worth asking in this debate. Firstly, is interception of private communications a governmental right, which must therefore be protected in the face of technological change, or is it an accidental consequence of the weaknesses of the communication techniques that we have been using? I would argue that it is the latter and that there is no community obligation to protect it. Secondly, is a country better served by a vibrant, efficient, electronic economy, using trusted secure communication techniques for its day to day business, or by attempting to reduce organised crime by restricting use of technology? So far, much of the opposition to restrictions on the use of encryption technology has centred around a right to privacy and civil libertarian issues. Perhaps, instead, we need to quantify the opportunity cost, in economic terms, of delayed and lower levels of adoption of electronic commerce by the business community because the security mechanisms are not sufficiently trustworthy. It may be that the cost to the economy of restricting the use of encryption technology outweighs the benefits to the community. ...

1 0