- cypherpunks-legacy@lists.ogf.org

Re: Joke of the Day
by doug＠netcom.com 16 Sep '93

16 Sep '93

an23412(a)anon.penet.fi said: >My actual horoscope for today: Uh-oh...your anonymity is partially compromised; we can now narrow down your identity 91.7 percent more closely than before! A few more slips like that and we'll have it down to one of several thousand choices... Speaking of privacy violations, a coworker relates a story from his father (ok, just a FOAF story, but it's still interesting): He needed to find his wife, who'd headed off for some errand and thence to the airport, leaving her spending cash at home. He called her on her cellular car phone, but she'd turned it off. He called Cellular One and explained the problem, and they told him over the phone where she was...he sped off and caught up with her. Although this was handy for him, it's an obvious privacy problem for Cellular One to tell someone where one of their customers is. Doug

1 0

No Subject
by Anonymous 16 Sep '93

16 Sep '93

Hi, Can someone clue me in to a location of a VMS version of PGP? Thanks

2 1

Joke of the Day
by an23412＠anon.penet.fi 15 Sep '93

15 Sep '93

My actual horoscope for today: "A paradox: Someday, millions will read your words, and yet you shall be anonymous! Your ability to mediate makes you friends with opposing parties." The joke of the day from an AP report on the veep's Information Highway press conference: "American industry already is out front in high-tech development, but a fear exists that better coordinated government-industry relationships in other countries may give an edge to foreign competition." ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Random numbers
by Timothy Newsham 15 Sep '93

15 Sep '93

Anon Wrote > mjr(a)TIS.COM writes: > >So figure you want more than 56 bits of pure unpredictability as your > >seed. This is a tricky problem. One option is to give the user a typematic > >buffer: "hit keys for 30 seconds" - you NEED unpredictability! > > So, it sounds like what we *really* need is a little box with a shot-noise > generator that attaches to a serial port and generates truly random > numbers to use for the key. Anyone out there feel like designing one for us ? Last time I was fingering through an analog parts catalog under the telephony section I noticed a bunch of parts that generate audio-noise. Maybe some of these would be suitable (if they dont use an internal digital state machine to generate the noise).

1 0

Unix version of PGP
by williacw＠vuse.vanderbilt.edu 15 Sep '93

15 Sep '93

Is there a UNIversion of PGP? Please Email me the location at: WESLEY(a)ctrvax.vanderbilt.edu Thanks

1 0

Random numbers
by an31185＠anon.penet.fi 15 Sep '93

15 Sep '93

mjr(a)TIS.COM writes: >So figure you want more than 56 bits of pure unpredictability as your >seed. This is a tricky problem. One option is to give the user a typematic >buffer: "hit keys for 30 seconds" - you NEED unpredictability! So, it sounds like what we *really* need is a little box with a shot-noise generator that attaches to a serial port and generates truly random numbers to use for the key. Anyone out there feel like designing one for us ? Also, what's the recommended book/books on cryptanalysis ? Looks like I have a fair amount to read up on..... ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Re: Testing randomness of PGP-generated IDEA keys
by mjr＠TIS.COM 15 Sep '93

15 Sep '93

Anonymous writes: >Yes, obviously you're right. PGP seems to take the randseed.bin file, >the MD5 of the input, and the current time, and munge all of them together >using the IDEA encryption routines to create the final results. Assume the current time is a wash. Any message sent is going to have an approximate time (in seconds) inserted in the header as the MTA moves it, so that value is searchable trivially. For example, this message nicely contains a timestamp: Date: Wed, 15 Sep 1993 18:22:10 UTC I figure searching all the seeds within 12 hours of that will eliminate the time as a seed, and that's only 84,000 searches, which is huge orders of magnitude easier than searching DES. You don't even need gnarly fictional $1.5million DES-searching machines to do it. That leaves the MD5 of the input and randseed.bin. The MD5 of the input is by definition unknown to the attacker in MOST cases, right? If you're using this for confidentiality, that is. If the input is known, then you're left with just randseed.bin. >The contents of randseed.bin are created by generating some random bytes >using the same generation routine as the key and encrypting it with the key, >so they should be as random as the sample I created. I'm not entirely clear on this. It uses the same mechanism as the key and feeds it back through itself? What is the input into this process? Again: ignore the apparent randomness of the output, you need to look at the unpredictability of the input seed. Randseed.bin should be kept secret, clearly, as it's part of your key. >What bearing might this have on the suggestions of using electronic cheques >(presumably encrypted with PGP) ? If the cheque is a standard format, that >might open up some possibilities with this kind of approach, especially if >you know who it came from and/or who it's payable to. If I know the layout of the check and know that the only values that will change are a serial number which increases monotonically, and a value, which averages around $1,000, I can probably crack your PRNG in an hour or two, depending on how many processors I throw at it. Remember that this parallelizes trivially. Also, when you crack the PRNG with a public key system, you *KNOW* instantly that you've gotten the correct key, so the entire process is very hands off. One way of thinking about the problem is trying to count how many bits of unpredictability go into your PRNG seed. If you're willing to assume your adversary can brute-force search DES' 56-bit keyspace, then you'd better assume he's also willing to brute-force search your PRNG. So figure you want more than 56 bits of pure unpredictability as your seed. This is a tricky problem. One option is to give the user a typematic buffer: "hit keys for 30 seconds" - you NEED unpredictability! mjr.

1 0

Re: Testing randomness of PGP-generated IDEA keys
by an31185＠anon.penet.fi 15 Sep '93

15 Sep '93

mjr(a)TIS.COM said: > I found myself embroiled in a similar exploration of random >number generation as part of some other work, and it took me a while >to realize that running statistics on the output of the PRNG is >almost useless, if you're using a cryptosystem or cryptographic hash >as the PRNG. Yeah, this is a good point. I was assuming that there was no simple way of determining the possible keys from the time and other information you'd get with a random PGP-encrypted file that you wanted to crack. *If* that is the case, then looking at the output of the PRNG is useful to show that the worst-case of a brute force attack using all possible keys cannot be improved by taking the relative frequencies into account when creating the possible keys. It would be embarassing if 0x2A appeared 100 times more frequently than any other byte value, or if there was a strong correlation between the bytes in each key, for example. Whatever the case, we can probably write off any idea of brute force attack like the DES one, unless you have a few billion years to play with. (In which case, you'll do better attacking the RSA key anyway) > What you've got to look at is the predictability of the >input to the PRNG. PGP is in really good shape here, because it >bootstraps its PRNG with its input, which presumably is unknown >to the attacker. An example of a weak PRNG would be: [ Description deleted ] > Anyhow, I've been over-long winded. I think PGP is >in good shape because of the aforementioned property of >using the message as a seed. Messages that don't change >much, or that change predictably, are subject to exhaustive >searching. A means of analysing the unpredictability of >the seed is more worthwhile. Yes, obviously you're right. PGP seems to take the randseed.bin file, the MD5 of the input, and the current time, and munge all of them together using the IDEA encryption routines to create the final results. So, it's not at all clear how to test this end of things (one of the reasons why I decided to look at the output rather than the input). I'll have to poke around more in the code and see if I can work out what it's actually doing with all this stuff to get some idea of how to test it, if possible. The contents of randseed.bin are created by generating some random bytes using the same generation routine as the key and encrypting it with the key, so they should be as random as the sample I created. I could easily rewrite the program to generate the files and just calculate the MD5 and look at that, but, like you, I'm not sure that will tell us anything. Still, I can easily afford the CPU time, so it might be worthwhile anyway. Overall, I'm willing to accept that the key generation works pretty well at this point. What bearing might this have on the suggestions of using electronic cheques (presumably encrypted with PGP) ? If the cheque is a standard format, that might open up some possibilities with this kind of approach, especially if you know who it came from and/or who it's payable to. >My hat >is off to the guy who came up with the idea of seeding >the PRNG with the message. That was *clever*. > >mjr. Definitely. In fact, I wonder if this explains the 'fatal flaw' that people have mentioned. According to the comments in the code, the MD5 was introduced as an improvement over the previous method of generating the key, so perhaps there really was a flaw in this key generation that has now been fixed, or at least greatly improved. ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

Re: caching scripts
by wcs＠anchor.ho.att.com 15 Sep '93

15 Sep '93

Hal writes, on the subject of filler messages > It is true that user messages can be distinguished from dummy ones when > they are on their first or last stage in the chain; on the first stage, > they are the only messages coming from non-remailer addresses, and on the > last stage they are the only messages going to non-remailer addresses. > One way to fix this would be, instead of having the final destination > of the message be a "bit bucket" address, to instead choose a random > Internet address (say, from one of the "whois"-type databases), and to > send a message whose body starts with "Test message, please ignore". > With the tens or hundreds of thousands of addresses available (and with > the geometric growth of the Internet), it should not be necessary ever > to repeat an address. So perhaps this slight annoyance to Internet users > would be tolerable. Only a small fraction of users would ever receive > such a message. This is a way to increase the public's annoyance with remailers, when what we need to do is increase their acceptance of them. It also doesn't work - a cleartext message saying "Please ignore" is visible to any eavesdropper, an encrypted message to a real person is annoying and non-readable, and an encrypted message to a bogus person will usually generate bounce-mail (which is obvious to eavesdroppers), or will at least drop on an operator's floor, annoying the operator. If we can get a reasonable number of remailers operating, it makes much more sense to have standard bit-bucket addresses, and if we want to get more traffic to sites that aren't obviously remailers, we need to get their permission. This can either be done by asking people (which the Bad Guys can watch), or perhaps by providing some semi-useful service, like a netnews test sink or mail-a-joke or something; even those tend to be obvious - unless they can also be remailers or at least require crypto or other illegible data input. Bill Stewart

1 0

PGPC 2.2 available
by nate＠VIS.ColoState.EDU 15 Sep '93

15 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- PGPC 2.2 is available for anonymous ftp from 129.82.156.104 in /pub/pgpc/pgpc22.tar.[Z,gz] It is available in either gnuzip or regular compress. Read the README. It comes with a makefile that will add the public keys to your public keyring... you may need to edit that if you don't need it (or want it) to add the keys. I added support for the encrypted remailers... it's quite slick now, IMHO. It can nest as many rounds of encrypted remailing you want, and it will also mail through anon.penet.fi into the remailers. I also signed the archives, and put the signature certificates in near the archives, you can get my public key from fingering nate(a)monet.vis.colostate.edu have fun, - -nate +-------------------------------------------------------------------- | Nate Sammons email: nate(a)VIS.ColoState.Edu | Colorado State University Computer Visualization Laboratory | Finger nate(a)monet.VIS.ColoState.Edu for my PGP key | #include <std.disclaimer> | Always remember "Brazil" +----------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLJYBudTgi1fmrpxlAQEG4wP9HTn4xqBP/1rvPUwsuUoDpnoN/uzvVl73 fY/j9jnFjA+cAJ0/fnvUtl7Iq1OcowLauZAlIPg8ts7aR3sCT4eQnZZg2fon4xj3 dMeVjy/K3nTXPCoz+67KzIurZxHgyS5BQMzYs8YWi6lE/t7cWfFxE/6IyYMr7bYL B4OG6tKJOL4= =OIsL -----END PGP SIGNATURE-----

3 2