December 2003 - cypherpunks-legacy

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

Re: Pornography, What is it?
by frissell＠panix.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 06:29 PM 1/11/95 -0600, root wrote: >Article XIV (1868) > >Sec. 1. > >All persons born or naturalized in the United States, and subject to the >jurisdiction thereof, are citizens of the United States and of the States >wherein they reside. No state shall make or enforce any law which shall >abridge the privileges or immunities of citizens of the United States; >nor shall any State deprive any person of life, liberty, or property, >without due process of law; nor deny to any person within its jurisdiction >the equal protection of the laws. > >Where in there is the protection you speak of? I see no guarantee of my >Constitutional rights, only of privileges and immunities as granted >by the federal government. The courts have held that the term "liberty" in the XIVth Amendment includes the liberties protected by the body of the Constitution and the other Amendments. DCF - -- PGP signing encouraged by Private Idaho (for Windows Eudora) by Joel McNamara -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLxVIOYVO4r4sgSPhAQHPfgP+PisOuBlvGgb96M5bjkVdIfDb2JEkb0Nb N4Uw9FoILGtUPibEphsJbRF4GpCd8qfHJvZjP5jTCLztCwo0r/kPc4qDKYPzRpVv EmZm2WwByOBSDqljJJAb3a7bC5b9vOEr2shr29u1apYmGl6sldvi4lTHYMjTOxI3 rUmivlpfsOc= =kTT1 -----END PGP SIGNATURE-----

1 0

Re: How do I know if its encrypted?
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The data haven concept as I understood it held data for public access in some form (for sale or for free) which would be illegal in some jurisdiction. This might include credit information that was older than the legal limit, libelous claims, damaging medical records, etc. Frankly, I suspect that most usages would be directed towards reducing, rather than increasing, individual privacy. So this is not an area I am interested in working towards. The idea of offsite storage doesn't seem that helpful since you can just store the data on your own disk in encrypted form. Maybe if encryption gets outlawed it would be useful, but then you can't use encryption to communicate with the haven. As far as remailers requiring encryption, one purpose would be to reduce complaints by making it impossible to send some kinds of messages which people would object to. It would be hard to post to usenet, for example, in a useful way. And mail to private individuals could not contain obvious obscenities or other objectionable material. The problem with this is that if people become able to handle and deal with incoming encrypted mail in a transparent way, this restriction is no longer effective in the latter purpose. Someone could get encrypted hate mail and have it transparently decrypted and displayed just like normal mail. They will be just as upset as people are today when they get objectionable mail from the remailer. As far as usenet posts, if a particular decryption key were widely and customarily used in a particular newsgroup, objectionable material could still be widely read if encrypted with that key. Tim May's example of a fake encrypted post containing inflammatory material is a good example of the heat which could occur, especially when the message is real and not a fake one like he did. So I don't think this restriction would really accomplish the desired goal except perhaps in the short term. If the purpose is to have plausible deniability by the remailer operator, I feel we can still get that by publicizing the remailer software source, which has no provisions for manual filtering. A policy of sending only encrypted mail so that the operator can't filter would be no more acceptable to critics of anonymity than a policy of just not filtering at all. Entropy checking is not adequate to detect encryption, as compressed files have maximal entropy as well. For these purposes, compression may be nearly as good as encryption, except that standard compression formats are already widely used. An entropy checker might well pass a gif, jpeg, or zip file, so this filter would by itself be useless to prevent posting of unencrypted graphics. It would probably have to be augmented at least by some checks for these special file formats. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLxVgSRnMLJtOy9MBAQF66wIA3a01avgc0jBjKXH6IMjO+6wj4tBeSUmM ZeRl+xFZFZ4Cfsrik1ghuHXI31isiHUzrPAIVEZfFIpTw6w9T0QdSQ== =YVRq -----END PGP SIGNATURE-----

2 1

Chain
by assets＠alpha.c2.org 17 Dec '03

17 Dec '03

I use Hal Finney's 'Chain' a lot: it is an easy way of automatically building a remailer chain. But it won't PGP correctly with the Usura and the Flame remailers because these two have e-mail addresses that have changed and/or are different from the addresses specified in their public keys (Usura, for instance, is now <usura(a)replay.com>, but this is not the address given in its public key ID). Is there a way for me in PGP to edit and update the information contained in the public keys of others? I would want to add an "also known as" line for 'Chain' to spot. O.A. <assets(a)alpha.c2.org>

2 1

Pgp where?
by kevin.rock＠njackn.com 17 Dec '03

17 Dec '03

I think this is the correct board to put this message on, but since there are no messages to read here I might be wrong. Does anyone know where to locate the program (algorithm) Pretty Good Protection (PGP) ? I've read about it in the local newspaper, in Scientific American and in the alternate news message area. It sounds like a good encryption scheme and I would like to explore it's possibilities. Thanks for any assistance.

1 0

Re: Multiple symetric cyphers
by cactus＠seabsd.hks.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- In article <199501121623.IAA00846(a)largo.remailer.net>, Eric Hughes <eric(a)remailer.net> wrote: >I am assuming that it's unlikely that all of the ciphers will be >broken simultaneously. Quick reasoning note: For forward secrecy, it's unnecessary that the ciphers be broken simultaneously; just that they are broken in the span of time between encryption and the attack. - - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus(a)hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLxUnexNhgovrPB7dAQE5LwP+JYB/CW87wI8zdgaE64KHffcde/L6c7f9 nrC0AC5ljrKYgUyzDY0XFiDd5kHSp/wtwFeZeGkobihZqGnuHgh9R9wnPTgfrKM5 L+DBymQiHvT8LG+UwBCCNcRH0dDODYpvB3fJrYobvAzEfEazfuWDdYMZ/o4feBqT r2meoZryBxE= =8qyB - -----END PGP SIGNATURE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLxViPSoZzwIn1bdtAQFC4AF/aIdX8R43DwPV8sfpjzr7MBlS2dFM+kmW MnYjcGHaSCkkyZ9XjXnJ3QWtvTFiigyF =9w/Z -----END PGP SIGNATURE-----

1 0

Re: analysis of RemailerNet
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 8:57 AM 01/12/95, Wei Dai wrote: >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: [...] > 3 log base 1 of 1,000,000 = infinity! Yeah, I think it made sense. Let me try to rephrase what you are saying in English rather then math, to see if it's still what you are saying. 1) Attacker Eve wants to figure out who Alice is sending mail to. 2) She can weed people out by noting 'collection periods' where Alice sends mail, but certain people don't receive any mail, and eventually arrive at Bob. 3) If Alice sends mail out in _ever_ collection period, perhaps just to the bit bucket, this method won't work, because there won't be any periods where Alice doesn't send mail out. Hmmm. The basic idea here is simply that you should send out lots of cover mail, at least one piece in every collection period, to prevent this kind of attack. Best, a random number of cover pieces, but at least one every collection period. Several thoughts: 1) If Alice and Bob are both corresponding with many people, things get more complicated. I tried to model it similarly to the way you modeled your simpler situation, but got confused quickly. This would be a good thing to look at. Alice sends and receives mail to several people other then Bob, and same with Bob. I'm not sure how this changes things, if at all. 2) In real life, it's more likely for an attacker to want to discover Alice knowing Bob then it is for him to want to discover Bob knowning Alice. It's Alice who is being anonymous here by using the anonymous RemailerNet, of course. I don't think this changes things either, but it's something to keep in mind.

1 0