- cypherpunks-legacy@lists.ogf.org

FTP location for sci.crypt FAQ
by cme＠ellisun.sw.stratus.com 15 Sep '93

15 Sep '93

>sci.crypt Usenet newsgroup FAQ. It's posted occasiuonally to sci.crypt, >but I can't think of a site (offhand) where you can FTP it. [from the FAQ] The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, sci.answers, and news.answers every 21 days.

1 0

caching scripts
by hfinney＠shell.portal.com 15 Sep '93

15 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- I am very excited to hear about Karl's progress in experimenting with caching (batching) mail messages. Karl, if it becomes convenient, I'd appreciate seeing a copy of your scripts. I have two thoughts about batching. The first regards the mechanism for arranging for activation of the batch scripts at regular intervals. Karl mentioned at and crontab as two ways of arranging for this. Some users may not be allowed use of these functions. I am not sure I can use them on the systems which I use. Another possibility, it occurs to me, would be an "activation" message sent to each remailer from some system where crontab usage is allowed - one of the systems which is owned by a remailer operator, for example. This system would send out an activation message at midnight every night to each remailer which had requested this function. The activation message would have a special header field which could be trapped by the slocal program and cause it to run the batch script. The other idea I had was to increase the volume of messages passing through the remailers. This way we could batch at more frequent intervals while still having good "mixing" at each step. Suppose some remailer system took on the task of periodically injecting messages into the remailer web. Each message would be a large chain, perhaps through a dozen randomly- chosen remailers, which would end up disappearing by being sent to a "bit bucket" address like nobody(a)soda.berkeley.edu. With the new scripts appearing for producing random remailer message chains such a program would be quite easy to write. The message injection rate would be adjusted to give each remailer in the system an average load large enough that batching would usually have (say) ten or more messages to work with. Perhaps nine of those ten would be these dummy messages, while one is an actual user message. But it would not be easy to tell these apart, at least for user messages which are in the middle of their chain; each message, dummy and real, is from another remailer and to another remailer. There is no hint as to which are the actual 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. The increase in traffic brought about by this dummy message source would not be large in terms of the net as a whole. It would only need to introduce messages at the rate of (# messages per batch) * (# of remailers) / (size of chain per message) per (batch interval). Plausible values might be: # messages per batch: 10 # of remailers: 20 size of chain per message: 10 batch interval: 6 hours This works out to about 3 messages per hour, not too large a load. Of course, this message injection system would only be maintained as long as user message traffic remained too low to provide good mixing in a batch system. As user message traffic increases, the injection rate would be decreased to compensate, until finally it might be possible to eliminate the dummy-message injection completely. Comments are appreciated, as usual. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLJaN5agTA69YIUw3AQECnwP9F+0gMxoL4xoLPyAJS4/owHOmTGW2OE0a nOLkjop+vT388LyZjbj40cRwm0OWpjNXwvsxsmY+Uhc8EYyTu/H1wKn2N2PR0Ufu TD/EYxLFuvXQGviGKftMfM/VbwRXUf1SiUnPovZ7jVaBhacp62y4+C6BQtFSZIft l3T2U1KI+Y4= =11AS -----END PGP SIGNATURE-----

1 0

Remail: errors
by HFinney＠shell.portal.com 15 Sep '93

15 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- I have been out of town for the last week, so I missed some CP mail. It looks like some good things are happening with remailers, though. Kudos to Karl, Sameer, and the others for their work! I have received many messages to my remailer in the last week which came from remail(a)tamsun.tamu.edu, which were PGP-encrypted apparently in an effort to get my remailer to send them. They did not work, though, because there was no "Encrypted: PGP" header to trigger the remailer's decryption. This can be arranged by creating the message something like this: ======================================================== :: Request-Remailing-To: hfinney(a)shell.portal.com :: Encrypted: PGP - -----BEGIN PGP MESSAGE----- <rest of message> - -----END PGP MESSAGE------ ======================================================== This would then be sent to remail(a)tamsun.tamu.edu. I don't know whether the multiplicity of such erroneous messages is just due to one person stubbornly re-trying, or whether there is an error in one of the new programs for creating chained remailer messages. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLJaNuKgTA69YIUw3AQHrNwQAowMEQwuH6YyHoj6T7AqZFLNdTf+eqJ9L LhAatHS94nmC1smkfVNq0dZmigmkvBdMNEPlBZemmxALz+KJw6OSY/ULSBmuVNEq 5rJANh3XimoJWqLISy2lZiuC5Fw2R7UvRadcdM94pncSVvev92Fyf7CqEOOtrGAK PUzRds7BVNo= =FpLa -----END PGP SIGNATURE-----

1 0

Re: more than spread spectrum
by George A. Gleason 15 Sep '93

15 Sep '93

Re. Carl's suggestion to "lay our own wires/fibers..." That's exactly what I'm up to with the Community Dialtone project. Basically it comes down to having a neighborhood switch. We may be doing our first installation in the Winter, about 800 lines if all goes well. Seems to me that owning the switching & transmission infrastructure has a lot of possibilities. Anyway, more news to come on this in a few weeks... The thing is, I've looked into things like having infrared laser networks and various non-switched message relay systems... these just don't have the overall reliability of a decent switched system, for a large number of reasons which essentially boil down to the fact that each individual link is weak enough that even a redundant system can break down badly at points where the link density is relatively thin. Then also there's the question of economic feasilbility; to make a decentralised/non-switched system work, you need an application that is *so* popular that everyone in an area will want to be in. This comes down to subscriber density, and the issue is basically the same with telephone lines, but everyone needs a phone line... cable TV has high market penetration but satellite TV doesn't... how can we expect a lot of average folks to set up an infrared relay, eh...? Seems to me the best thing is to have the IR relays located where they can connect among the switching systems serving the various blocks and neighborhoods. (and if anyone's figured out how to do that at 2.048 Mb, i.e. approx double T1, please email me ASAP). -gg

1 0

Re: more than spread spectrum
by doug＠netcom.com 15 Sep '93

15 Sep '93

cme(a)ellisun.sw.stratus.com (Carl Ellison) said: >The benefit isn't just for Cypherpunks. It's a free network for the masses... >I'll volunteer to do the software for the node card. Does anyone have >hardware design/fab to donate to the effort? You might want to contact the Garden project, which I believe is operational in San Jose and in Santa Cruz. I'm not up on all the details, but it is far too similar to what you're talking about to ignore. Doug

2 1

more than spread spectrum
by cme＠ellisun.sw.stratus.com 15 Sep '93

15 Sep '93

There are alternatives to spread spectrum, if we're threatened with loss of freedom to communicate. We could lay our own wires/fibers. We could set up a mesh network of infrared lasers through the air. Last time I looked, there were no laws against shining lights out your window as long as they didn't bother anyone. An infrared laser could hardly bother anyone. We could produce a line of cheap cards to plug into a PC which would do packet routing, using a variety of physical links -- our own wires, lasers, very low range radio, .... Each card would connect to three or more neighbors and become part of the global mesh. Adaptive routing with no global map would suffice for the card and would keep the whole system peer-to-peer with no need for central control and no chance for central tapping. Of course all of these solutions require a high density of users. A college campus might be the right place to start. We could then branch out to cities. I suspect that a place like Chicago or NYC with high rise apartments might be the place to start -- many options for line-of-sight communications. The benefit isn't just for Cypherpunks. It's a free network for the masses -- like the original USENET (with each user donating routing and store/forward) but with unrestricted, low-range, continuously operating physical links. I'll volunteer to do the software for the node card. Does anyone have hardware design/fab to donate to the effort? - Carl

3 2

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

15 Sep '93

>Hi, you may remember a few weeks back I was going to take a look at >the randomness of PGP random number generation.... well, I finally >got round to it. Since the MD5 of the file being encrypted is used >as part of the random number generation process to prevent anyone >copying the randseed.bin file and generating all future keys from it, [...] 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. With any decent cryptosystem, one bit change in the input to the PRNG will cause every bit of the output to have a 50% chance of being different - that's a desirable property in a cryptosystem. DES, and I assume IDEA, show this property. 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: `date | md5` For example: otter-> cat foo #!/bin/sh date | /usr/local/bin/md5 date | /usr/local/bin/md5 sleep 1 date | /usr/local/bin/md5 otter-> foo f4a66f827a8e62ad9c419f7e2117abc6 f4a66f827a8e62ad9c419f7e2117abc6 bcfa24d319ccdcad56a99be2e203e787 As you expect the first two runs are exactly the same. The second run is completely different. The seed, however, is only very slightly changed (by one second). You could run statistical analyses on the output for a long time and never realize that your random number is really extremely easy to crack. If I knew roughly what day you generated the "random" number on, I could crack it in only 86,400 MD5 hashes, and it's an operation that parallelizes trivially. *MUCH* cheaper to attack the PRNG than the cryptosystem! And if you used a toy PRNG to generate your RSA key, then you're lunchmeat. 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. I made some basic starts at doing this by ad hoc measures (generating repeated seeds and running them through a program to count a minimum-bit edit similar to diff) but I wasn't sure enough of the validity of my approach to bother continuing it. My hat is off to the guy who came up with the idea of seeding the PRNG with the message. That was *clever*. mjr.

1 0

No Subject
by remail＠tamsun.tamu.edu 15 Sep '93

15 Sep '93

> If people are willing to go to these measures to steal Intel > microprocessors, which are generally available, imagine what people > will do in order to steal unprogrammed Skipjack chips. In the volume > the Government would like to see them made, the physical security > which one might want to give to a classified production facility will > be difficult or impossible. They thought of this. The Skipjack algorithm is programmed into the chip at the same time the escrowed keys are. If you steal the unprogrammed chips you may learn the list of basic operations that are part of Skipjack. However there are also basic operations implemented on the chip which are *not* part of Skipjack but are there just to confuse someone who would disassemble a chip. Btw. This also means that the actual chip assembly line does not require cleared workers.

1 0

A E-mail to Usenet kludge for cs.texas.edu
by Anonymous 15 Sep '93

15 Sep '93

> 1: group-name(a)cs.utexas.edu > 2: group.name.usenet(a)decwrl.dec.com > 3: group.name(a)news.demon.co.uk > 4: group.name(a)news.cs.indiana.edu > 5: group-name(a)pws.bull.com > 6: group-name(a)ucbvax.berkeley.edu > > NOTES: > > * This does not include ones that work for single groups, like > twwells.com. > #1 apparently blocks anonymous remailer posts > #6 blocks from non-berkeley sites (so use the berkeley remailers :-) > for further help and/or questions. The comment concerning #1 (group-name(a)cs.utexas.edu) does not exactly hold true. Apparantly, by simply pasting in the - :: Request-Remailing-To: group-name(a)cs.utexas.edu header does not suffice. As a general rule of thumb, you must add the minimum in the pasted header - :: Request-Remailing-To: group-name(a)cs.utexas.edu Subject: Organization: Thanks to Chael Hall for helping me "troubleshoot" this little feature.

1 0

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

14 Sep '93

Hi, you may remember a few weeks back I was going to take a look at the randomness of PGP random number generation.... well, I finally got round to it. Since the MD5 of the file being encrypted is used as part of the random number generation process to prevent anyone copying the randseed.bin file and generating all future keys from it, I wrote a program to read in /usr/dict/words, and loop around generating files containing a random number (using the unix random() call) of random sentences using the words in the dictionary, and encrypt them with a test 384-bit key. The copy of PGP I was using was modified to dumped the 24-byte key/random prefix combination into a file, which the main program read out and processed. Firstly, it maintained a table of counts for each byte value, and secondly (since I gave up statistics years ago), XOR-ed all the bytes in each 24-byte sample together and maintained a table of frequency of XOR values as a simple check for randomness in each 24-byte sample. After running for a few days, the results were: Total bytes generated : 3000504 (125021 runs) Frequency : High: 11960 Low : 11377 Mean: 11721 Spread: 584 (4 %, +2 %, -2 %) Within 50% of mean : 2505989 (83 %) XOR Freq : High: 553 Low : 432 Mean: 488 Spread: 122 (25 %, +13 %, -11 %) Within 50% of mean : 107652 (86 %) Since, as I said, I'm not a statistician, my definitions of the above categories are : Mean - expected frequency, i.e. total number of bytes generated/256, Spread - absolute difference between frequencies of rarest and most common byte values, plus difference as percentage of mean, and spread above and below the mean as a percentage of the mean (rounded to nearest) Lastly, the program summed the frequencies of the bytes whose frequency was between (mean-(mean-low)/2) and (mean+(high-mean)/2), giving the result as an absolute value and a percentage of the total number of bytes generated. >From this, it looks to me like the random number generation is, indeed, pretty random, and if you're trying to break an arbitrary PGP-encrypted file by a brute-force attack on the IDEA-encrypted section, then you don't have any shortcuts based on frequency of bytes in the key. If anyone with a better grasp of statistics wants the original data to look at (25k, containing 24 arrays of byte frequencies and one of XOR frequencies), let me know and I'll email it to you. So, if there is a 'fatal flaw' in PGP, it looks like it must be either the known plaintext, or it must be somewhere in the prime generation code. Since I know nothing about fast methods of testing primality, someone else is going to have to look into that.... (Unless I get bored enough to hunt out some books on the subject) ------------------------------------------------------------------------- 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