December 2003 - cypherpunks-legacy

Re: Storm Signals
by rparratt＠london.micrognosis.com 17 Dec '03

17 Dec '03

> > If I were the DOD, I would set the standard GPS default to selective > availability. After all, with SA on military receivers can still get > fine positioning data. If someone could come up with a good reason to > turn SA off, great, but I wouldn't leave it on otherwise. > > The scenarios concerning GPS-piloted Cessnas full of nasty stuff come > to mind, especially vis-a-vis the North Koreans. They probably don't > have accurate IRBMs but they certainly could cobble together a > Learjet-based delivery system. SA is effectively cancelled out by using differential GPS (Using a correction transmitter to send out differences between GPS as-reported position and actual position). However, any 'home made cruise missile' would need to be fairly slow moving and manoevring. One of the features of p-Code is support for 'high-dynamic' vehicles. I've been away from the navigation field for some years, so others may know more. Does the Russian Glonass system have SA? -- Richard Parratt

1 0

Re: CBS/C.Chung Plan Hit Job on Internet? (fwd)
by Brad Parsons 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Wed, 11 Jan 1995 07:32:03 -0800 (PST) From: Skip Leuschner <skipl(a)pacifier.com> Subject: Re: CBS/C.Chung Plan Hit Job on Internet? I see C.Chung's program as one of the first vollies in a new phase of a TV/print media project. Internet and talk radio emerged as political forces in the '94 election. If political influence by the media is a zero-sum game, as I believe it is, then the TV and print media must look to their own survival by trying to discredit or regulate their talk radio/internet competition. Regards, Skip.

2 1

mail killfiling
by Craig A. Johnston 17 Dec '03

17 Dec '03

There was some talk on the list earlier about reading the list through news so as to be able to use kill files. Here is an alternate way for folks that have 'deliver' installed on their system as the local mail agent. (do a "grep Mlocal /etc/sendmail.cf" to see...if you don't see 'deliver' in there somewhere, you don't. This is provided you are using sendmail, of course.) First, install the following as ".deliver" in your home dir: --- cut here --- #!/bin/sh # delivers all mail except that from folks in $NOMAIL NOMAIL=.nomail FROM=`header -f From $HEADER` if grep "$FROM" $NOMAIL >/dev/null 2>/dev/null then # we don't want any mail from this person! exit fi echo "$1" # otherwise, deliver as usual --- cut here --- Now, you also need this little script that I call "killem" installed in your home dir. --- cut here --- #!/bin/sh NOMAIL=.nomail header -f From >> $NOMAIL --- cut here --- Now, let's say you are in your mailbox and you see such a horrible piece of mail from someone that you never want to see any mail from them again. ;) Provided you are using 'elm', (probably is a mechanism for this on other readers.) just pipe the message through 'killem' with a "|" from elm and answer "killem" when asked what you want to pipe the message through. The From: line will be stripped and stuck in .nomail (or whatever you change it to) and you won't see any more mail from this person. Of course, this is not entirely true: mail that does not get delivered will go to a file called Undel.mail in your home dir, which you can keep, or have a cron job deal with, or whatever you like. Also, if they change their 'real name' on their system, you'll start to get mail from them again. (i.e. w/'chfn' or the like.) This is just a quick hack I whipped up a moment ago, and could of course be improved/changed. 'deliver' will also run perl scripts, and it should be relatively easy to write something that way that will handle wildcarding and field selection. An automated mailing to folks upon their 'termination' could be added for those that want to rub it in, or an automated bounce that sends mail right back with a note that their mail is not being received. If you want to block mail based just upon the account name and not have to worry about them changing their "real" name, you can just add the account name to .nomail manually. Judicious use of the unix 'cut' command could have 'killem' just toss the account name into .nomail for mail coming from unixy systems, but would fail for others, so I decided to not assume anything about the From: line. Ought to work fine and transparently for most folks as-is. Ingenious folks can build on it. I dunno how many systems use 'deliver', but it's sort of a Linux (slackware) default, and those using it can avoid learning procmail with this script. Enjoy, Craig.

1 0

Cryptanalysis
by Brendan McKenna 17 Dec '03

17 Dec '03

Hi, I light of recent threads about recognising whether or not a given message/file is encrypted, and using CBW and things along those lines, is there any way to determine how something was encrypted? For example, I know that a statistical analysis of the cyphertext will uncover simple substitution cyphers fairly quickly. Does the same sort of analysis apply to determining whether something was encrypted using IDEA or DES or RSA? I realize that they attempt to maximize the entropy of the cyphertext -- perhaps there is some characteristic amount or range of amounts of entropy associated with these cyphers? Not every package is as nice as PGP in labeling everything it encrypts with headers... Any pointers would be greatly appreciated.... Brendan PS. What I'd like to be able to do is take a given chunk of cyphertext and analyze it and say: "There is an x% probability that this was encrypted using method y...." Hopefully I'd have a reasonable chance of recognizing how it was encrypted, and not all of the percentages would be so low as to make the exercise meaningless.

1 0

analysis of RemailerNet
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I've been reading through T.C. May's FAQ, and came upon this section about analyzing the RemailerNet. > + What's needed: > - aggreement on some terminology (this doesn't require > consensus, just a clearly written paper to de facto > establish the terminology) > - a formula relating degree of untraceability to the major > factors that go into remailers: packet size and > quantization, latency (# of messages), remailer policies, > timing, etc. > - Also, analysis of how deliberate probes or attacks might > be mounted to deduce remailer patterns (e.g., Fred always > remails to Josh and Suzy and rarely to Zeke). > - I think this combinatorial analysis would be a nice little > monograph for someone to write. > 8.10.2. A much-needed thing. Hal Finney has posted some calculations > (circa 1994-08-08), but more work is sorely needed. I think one of the most difficult aspects of analyzing remailers is the large number of variables you have to deal with. In contrast, when analyzing ciphers things are pretty much static. The only thing variable you have to worry about is key length. But think of the factors you have to include in a complete analysis of the RemailerNet: 1. different methods of attack - passive traffic analysis (i.e., packet sniffing) - active attacks: including physical attacks, subverting remailer security, flooding, denial-of-service, starting "trap" remailers, etc. 2. differences at the user level - fixed vs random chains vs something in between - length of chains - numbers of real messages sent - numbers of fake (cover) messages sent - concerns about latency, bandwidth, and monetary costs - acceptibility of risk, and benifits of anonymity 3. differences at the individual remailer level - the mixing mechanism: does batched mailing occur by time or by the number of messages in the queue, and is there a rollover pool? - security: including vulnerabilities to political, physical, and electronic attacks - usage level - price 4. differences at the RemailerNet level - total numbers of remailers - average security (or the number of compromised remailers) - total number of users ... and I'm sure there are more. The number of variables and the complex way they're all interrelated make the analysis difficult. Perhaps a good way to go about this is to construct simplified models which focus on different aspects. For example, someone pointed out that if you didn't have to worry about active attacks, and the attacker can monitor all the remailers, then you can treat the entire RemailerNet as a single large remailer. I'm not sure how well this approach would work, since I don't know how easy it would be to integrate the different simplified models into a realistic one. Anyhow, this might at least give us some insights, so I'll make some attempts in this direction, and post my results. Just to start things off though, let me try an *extremely* simple model. Assume there is just one remailer, it's perfectly secure, and it does 4 batches of remailing at equal intervals each day. There are one million users, each of whom receives a mail from the remailer once per day. Alice is sending anonymous mail to Bob through this system, also once per day. But just to be extra careful, she also sends a cover mail to the remailer at some other time each day, which gets redirected to its /dev/null. So the situation looks like this on day 1: Alice sends Bob receives some random user receives Batch #1: 0 0 0 Batch #2: 1 1 0 Batch #3: 0 0 1 Batch #4: 1 0 0 Suppose Eve, the traffic analyst, is trying to figure out who Alice is sending mail to. After the first day, she can eliminate about half of the remailer users from the list of possible targets, because they, like the the random user above, received a mail even though Alice didn't send one out during the collection period of that batch. Now, since Eve can eliminate on average half of the list every day, Bob will be the only person left on that list after about (log base 2 of one million) = 20 days. Suppose Alice sent out some different numbers of cover e-mail: # of cover mail # of days to discover Bob 0 log base 4 of 1,000,000 = 10 1 log base 2 of 1,000,000 = 20 2 log base 4/3 of 1,000,000 = 48 3 log base 1 of 1,000,000 = infinity! Hopefully that makes sense... Comments? Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLxU0QTl0sXKgdnV5AQFkoAP/SSyqbbDw+zoh+q5aL0+xr5BcLzaEoS4h NASocZvKHGLe8/sfefDj4J2zPINKhmQzbKdD4oHirPEVbnWZC+7Us3giCKl80t2V bKx6QPB1hJWi6n3cFme6NCuTjmHCsgrQ/bI2j524O43FhW6BIQAAxQ6GGN10t1V8 3nv3SzUC6jE= =Y2qv -----END PGP SIGNATURE-----

1 0

time stamping service (again)
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- My PGP based time stamping service is back online. I took it down a while ago thinking the folks at notary.com (Digital Time-Stamp, Inc.) were going to release their commercial time stamping product soon (it uses a more elegant protocol that doesn't require trust in the time stamper, but the algorithm is patented). But I haven't heard anything from them in a while. Anyway, it is now running as the following procmail recipe: :0 w * ^Subject: Time Stamp This Mail { PGPPASS=whateveryourpassphraseis :0 c w | (lockfile timestamp.lock ; pgp -fast +batchmode +force +verbose=0 \ +clearsig=off) > timestamp.out :0 a h | (formail -r -i 'Subject: Time Stamp Output';cat timestamp.out) | \ ($SENDMAIL -t ;rm -f timestamp.lock) } To use it, just send whatever you need time stamped to me with the subject "time stamp this mail". BTW, can a procmail expert explain to me why the locallockfile mechanism doesn't work with this recipe? If I use :0 w : as the first line, procmail will happily ignore the locallockfile flag and proceed to munge up timestamp.out, so I have to do the filelocking manually. Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLxU7Zjl0sXKgdnV5AQE1agP/TFGtHEUj6GUwEF1ISGLcUZ/T64Vs7BUJ PIcydYUDk/5AVPLS2F8r81oLLxDUzYFkVy/6uvhnj6Pvo17ZIx6ELhKNPLPVoLPL iklR9E7rmY2cRMQfuCPRYi10x4mD9yJcw0GmlQmgOqZS/HfQ30njrsAeDXBUNvA5 SvFBaPKuOro= =NNoJ -----END PGP SIGNATURE-----

4 3

Re: Cryptanalysis
by rparratt＠london.micrognosis.com 17 Dec '03

17 Dec '03

> I light of recent threads about recognising whether or not a given > message/file is encrypted, and using CBW and things along those lines, is there > any way to determine how something was encrypted? For example, I know that > a statistical analysis of the cyphertext will uncover simple substitution > cyphers fairly quickly. Does the same sort of analysis apply to determining > whether something was encrypted using IDEA or DES or RSA? I realize that they > attempt to maximize the entropy of the cyphertext -- perhaps there is some > characteristic amount or range of amounts of entropy associated with these > cyphers? Not every package is as nice as PGP in labeling everything it > encrypts with headers... Any pointers would be greatly appreciated.... If the encryption method is any good, the output will be pseudo-random with no digit being more frequent than any other. This certainly applies to IDEA and DES. With RSA, you usually have a random (IDEA) session key encrypted using the senders private key. This will also be an effectively 'random' number. > PS. What I'd like to be able to do is take a given chunk of cyphertext and > analyze it and say: "There is an x% probability that this was encrypted > using method y...." Hopefully I'd have a reasonable chance of recognizing > how it was encrypted, and not all of the percentages would be so low as > to make the exercise meaningless. This would only work for ciphers that are effectively 'broken'. Also, many packages and users compress data before encryption. Compression algorithms work by removing patterns from data, so the resultant compressed plaintext becomes fairly random anyway, removing the utility of frequency analysis. -- Richard Parratt

1 0

good stuff
by nelson＠crynwr.com 17 Dec '03

17 Dec '03

Interestingly enough, there are lots of interesting documents, including anti-clipper screeds etc, on the New York State Education Department's gopher. Good stuff for political activists (as opposed to passivists :). gopher://unix5.nysed.gov:70/11/TelecommInfo/Reading%20Room%20-%20Points%20of%20View -- -russ <nelson(a)crynwr.com> http://www.crynwr.com/crynwr/nelson.html Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | What is thee doing about it? Potsdam, NY 13676 | What part of "Congress shall make no law" eludes Congress?

1 0

Knowing Something's Encrypted
by Jeff A Licquia 17 Dec '03

17 Dec '03

Maybe I'm missing something here. If I am, please bonk me. Here's a simple method for knowing that some data you received is encrypted: 1. Require a specific method (we'll use PGP in this example). 2. When a message comes in, check for a PGP format message. If you really wanted to get fancy, you could parse the PGP header a bit to make sure the data was really encrypted. It's true that this isn't "cryptographic" in the sense of testing the ciphertext itself, but it should work for the practical goal of enforcing a "must be encrypted" rule. ---------------------------------------------------------------------- Jeff Licquia (lame .sig, huh?) | Finger for PGP 2.6 public key jalicqui(a)prairienet.org | Me? Speak for whom? You've got licquia(a)cei.com (work) | to be kidding!

1 0

Re: Cryptanalysis
by daleh＠ix.netcom.com 17 Dec '03

17 Dec '03

You wrote: >If the encryption method is any good, the output will be pseudo-random >with no digit being more frequent than any other. This certainly applies >to IDEA and DES. With RSA, you usually have a random (IDEA) session key >encrypted using the senders private key. This will also be an effectively >'random' number. Just a technical note, but a normal distribution of digits (i.e. 'no digit more frequent than any other') is no inidication of either randomness or 'good' encryption. A better test is to look for a normal distribution at all scale levels. For example, the following text block: "UUU" (in ASCII) has a normal distribution at the bit level "0101 0101 0101 0101 0101 0101", but not at the byte level. Dale H.

1 0