December 2003 - cypherpunks-legacy

Re: MS-Mail Security
by AwakenToMe＠aol.com 17 Dec '03

17 Dec '03

In a message dated 96-06-27 21:39:21 EDT, harka(a)nycmetro.com writes: >I'd also like to know how secure the MS-Mail files are (*.mmf). They are >password protected and should be encrypted but does anybody know how secure? > >Harka >___ Blue Wave/386 v2.30 [NR] > > as far as I know.. the encryption used on them is weak. I think ive seen a generic cracker for these on the internet. I dont think MS is going to put the time into a good VERY secure encryption for this.. because then aftermarket things wouldnt be bought!!! hehe

1 0

Another free speech victory
by Anonymous User 17 Dec '03

17 Dec '03

Just read that the Supreme Court "struck down provisions of the 1992 Cable Act that require local cable companies to either ban indecent shows from appearing on leased or access channels or place all programs deemed indecent on a single channel and block it. Those provisions violate free-speech rights, the court said. But the court said Congress lawfully can permit cable operators to choose not to broadcast such programs on leased access channels." [NYT] Looks like the gov't will lose if it decides to appeal the CDA decision. Medea

1 0

secure WWW on UNsecure servers
by Kevin Q. Brown 17 Dec '03

17 Dec '03

I know several people who want to share private information on some web pages but do not trust any publicly-accessible web server not to leak the information on those pages. The normal IP address or password-based web page protection mechanisms thus are not sufficient since they assume that the server is secure from non-web-based mechanisms for retrieving the pages. Also, encryption schemes such as SSL will not solve the problem because they protect only against interception between the server and the client, not at the server itself. Instead, it looks like the web pages must reside on the server in encrypted form. How might one arrange for these encrypted web pages residing on an (unsecure) server to get decrypted only at the client's machine? This should work as transparently as possible for the user; except possibly for a userid/password query it should look like a normal web browsing session. For now, we can assume that the decrypted web pages contain only HTML and images in .gif format. Might this best be done with some combination of special MIME types and helper applications or plug-ins? Has someone already done it? Thanks. Kevin Q. Brown kqb(a)c2.org

5 4

Re: Another free speech victory
by jim bell 17 Dec '03

17 Dec '03

At 11:05 AM 6/28/96 -0700, Anonymous User wrote: >Just read that the Supreme Court "struck down provisions of the 1992 >Cable Act that require local cable companies to either ban indecent >shows from appearing on leased or access channels or place all >programs deemed indecent on a single channel and block it. Those >provisions violate free-speech rights, the court said. But the court >said Congress lawfully can permit cable operators to choose not to >broadcast such programs on leased access channels." [NYT] > >Looks like the gov't will lose if it decides to appeal the CDA >decision. >Medea However, it's worrisome that the decisions were only 6-3 and 5-4. Jim Bell jimbell(a)pacifier.com

1 0

anonymous mailing lists
by JMKELSEY＠delphi.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [ To: Cypherpunks ## 06/28/96 04:34 pm ## Subject: anonymous mailing lists ] >Date: Fri, 14 Jun 1996 02:15:03 +0000 (GMT) >From: Ecafe Mixmaster Remailer <mixmaster(a)remail.ecafe.org> >Subject: Hackerpunks and C2 >The proposal for a Hackerpunks nym based mailing list is >interesting, however, there are some concerns regarding the >susceptibility of the list to traffic analysis. I was thinking about attacks that can be carried out on remailers in general, and came up with something that is potentially pretty nasty, especially for anonymous mailing lists and people who post a lot of stuff anonymously using ``nyms.'' Let's imagine an anonymous remailer network as a ``black box'' which functions perfectly. Messages (broken into equal-sized packets and strongly encrypted) are sent into the network by the sender, and at some later time, they come out at the receiver. Let's assume there is no possible way for an attacker to trace a message through this network. Now, we still have to deal with two more issues--mail goes into the network, and comes out of the network. At those two points, there is trafic analysis available. Specifically, we can see how much data goes over the line. (Naturally, if it's encrypted, we can't tell how much of it is real data and how much is padding.) Generally, when we're attacking this system, we're trying to figure out either the sender or the receiver of a message (or a sequence of messages), based on what we can observe coming into and going out of the network of remailers. There are basically five scenarios: 1. The sender wants to know who the receiver of his message is. 2. The receiver wants to know who the sender of his message is. 3. An outsider wants to identify the sender of a message. 4. An outsider wants to identify the receiver of a message. 5. One receiver of a message wants to know who the other receivers of the message are. (This is the case for anonymous lists.) Now, there are a couple of different ways these attacks can be carried out. Usually, I've seen people talk about ``tracing'' attacks, in which a message is traced from one side of the network to another, without any clear idea of who might be on the other side. However, I think a more realistic situation is to imagine the attacker trying to test the hypothesis that some person is on the other end of the anonymous transmission. If relatively few people regularly send or receiver anonymous e-mail, then this is practical for many kinds of test. It's even more practical when we're dealing with relatively small populations of interested people in some technical subject. (This is conceptually similar to the ``dictionary attack'' on passphrases.) Basically, what we're looking at, in that case, is some test which (with some reasonably high probability) determines whether some person is the sender or receiver of a given message or stream of messages. This leads to some interesting insights. 1. In reasonably large text messages, it's probably easy to test hypotheses about senders. There are metrics that can more-or-less identify the writer of a piece of prose. While it's no doubt possible to defeat this kind of analysis for some things (i.e., blackmail notes or rigidly-defined messages in a cryptographic protocol), I suspect that this is very hard to defeat for a mailing list where the objective is to discuss serious technical issues. (This kind of analysis also causes headaches for people trying to do strong steganography in text.) 2. If an attacker (i.e., the NSA) logs the total volume of all traffic in and out of the remailer network, and to whom each message came from or went to, then that attacker can probably mount some very powerful hypothesis-testing attacks. It's these attacks I want to discuss. If Alice sends a message to Bob through the remailer network, two things must happen to prevent it from being trivially traceable. 1. The message has to change size. If the message is already encrypted, then compression isn't much of an option--so what's left is padding it out by a random amount. The amount of padding per message is probably a uniformly distributed random variable. 2. The message has to be delayed somewhat. The delay is probably also a uniformly distributed random variable, or possibly the result of adding N such variables, where N is the number of chained remailers. For a single mailing, this is probably not much of a threat. There will be enough ``noise'' in the delay and padding that most transmissions will be masked. However, consider the situation of a mailing-list. Alice and Bob are both recipients of the list. Alice wants to decide whether Bob is receiving the list. Let D be a delay such that, if Alice received her copy at time T, 90% of the other list members received their copy between T-D and T+D. Now, Alice looks at Bob's anonymous e-mail volume during that time span vs. at all other times. If he's receiving the same stuff she is, then there should be an increase within that span of time, on average. The random distribution of the arrival time will mask individual transmissions, but with many messages, it probably will not. (This is conceptually similar to the situation in Paul Kocher's timing attacks--adding some random pauses doesn't hurt the attack as much as most people expect it to, because those random pauses, summed up over many messages, become a normally distributed random variable.) The average amount of anonymous e-mail Bob gets per day doesn't have much effect, nor do occasional worst-cases. The only ways I can see to prevent this attack are either to ensure that Bob gets a constant rate of information from the anonymous remailer network, or to make the arrival time span so large that other randomness in the sample makes the change in volume undetectable. In general, I don't think this second one will work without accepting incredible delays on messages. This can also be adapted to tracing back anonymous posters to newsgroups and mailing lists, when they use a consistent nym. (They could also be traced by textual analysis.) In this case, the attacker starts by posting some anonymous messages (not using a nym--he doesn't need one), to get some statistics on what the average delay is, and also what the average amount of padding is. He may do this for several different ways of putting things together--he's got almost unlimited time to gather acceptable data. At this point, he observes in/out traffic logs for each hypothesized sender during a wide timespan before the arrival of the post at its destination. He compares activity inside that span with activity outside, over a large number of posts. If there is a correlation, then he's got the e-mail address of the nym. There are ways to get around this second attack, at least to some extent. However, I don't think it's wise to count on even very good remailer networks (i.e., the Mixmaster stuff) to protect your anonymity in this situation. (However, note that I'm thinking in terms of a very well funded, determined adversary. It's probably not too bad to count on it to protect your anonymity from technically unsophisticated attackers--but I wouldn't recommend using it for things that (say) the FBI or NSA might get very interested in.) I think the best defense against this will be something like this: Each user sets a quota of how much trafic he will take in and send out per day. Once per day, he goes through an interaction in which he downloads and uploads that much stuff, whether there's any of it for him or not. (Naturally, this won't be detectable from looking at the transmission, timing the interaction, etc.) This makes any volume variations per day disappear. Unfortunately, it also limits the user's total inflow and outflow, which means he'll have to set it to something larger than the maximum he ever expects to get. (It would be possible to have occasional overflow onto the next day's downloads, but not too often, or the user would fall further behind, on average, each day.) The size of these quotas will still leak some information, though not enough for the kinds of attacks I discussed above. Note: Please respond via e-mail as well as or instead of posting, as I get CP-LITE instead of the whole list. --John Kelsey, jmkelsey(a)delphi.com / kelsey(a)counterpane.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMdRWR0Hx57Ag8goBAQHCowQA71WBKkx1yonS0dEpy3pe7lgvSJPkpLUk zLjm0KeFoP+HGQBep48iILRYBlbGy5czcxNCU4zhE6+c4PWwvD+BpaGGccWWkyRi 0l/rdo5L5/1KgnpCAQJ/HNyRH0fO2NNOHvGB3m7I0H3lfmfOlNed8oIIjPFDVB23 60wpMZ9S93w= =HC1g -----END PGP SIGNATURE-----

5 5

Re: rsync and md4
by jim bell 17 Dec '03

17 Dec '03

At 01:19 PM 6/29/96 -0400, Mark M. wrote: >> A first guess might be 2^-128 but I know that this sort of thing is >> rarely that simple. Is md4 that good? > >2^-64. >> >> Note that I am not interested in "attacks" on md4 as such as the >> source of the random data is just another file provided by the same >> user, so it won't have been specially designed to defeat md4. >> >> If the probability is within a few orders of magnitude of 2^-128 then >> can I also be sure that if I only use the first b bits of a md4 >> checksum it will be within a few orders of magnitude of 2^-b ? There >> is an option in rsync to use a shorter checksum by truncating >> md4. This saves some bytes on the link at the risk of lowering the >> confidence. > >The probability of failure is 2^-(b/2). I don't think that's correct. That would be the correct formula if I were looking for two strings that happened to have the same hash value, but that's not what he's asking for. Jim Bell jimbell(a)pacifier.com

1 0

John Grubor and you
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Lucifer Remailer Operator wrote: >Just for the record, I am NOT John Grubor and had never even heard of him >before I did an Altavista search on his name earlier today. The concept that >some net.loon like Grubor would get another account with DHP to run an >anonymous remailer for whatever reason is LAUGHABLE. From what I have read, >Grubor spams newsgroups quite often, something I have not done nor plan on >doing. I was expecting people to be posting paranoid rantings about how I >am obviously a SPOOK... Why you were expecting people to be posting paranoid rantings if you did not even know who Dr. John Grubor, undercover police agent, was?

2 1

No Subject
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

declan(a)well.com (Declan McCullagh) spake thus and so: >WASHINGTON, DC -- With no fanfare and no hype, the Justice Department >yesterday faxed a 39-word statement to Senator Exon saying they will >appeal their loss in the Philadelphia case. > >The consolidated lawsuits of ACLU v. Reno and ALA v. DoJ resulted in a >victory for the plaintiffs earlier this month after a three-judge panel >granted a preliminary injunction preventing the DoJ from enforcing the >Communications Decency Act. Sounds like a case of "political testicles in a vise." This smells like an election-year maneuver so the Clinton administration can maintain its faade. (After all, who wants to be called "soft on the protection of children"?) By the time it's finally settled, the Congresscritters will have been re-elected and can go merrily back to perverting the Constitution. So how'd we wind up having to choose between *these* two yahoos for President? :-)

1 0

PC-ness of nym.alias.net
by Rich 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On Fri, 28 Jun 1996, Anonymous wrote: > I would appreciate any information members may have regarding the > security/safety of the new nym server nym.alias.net (in "alpha" state) who > posted here about 3 weeks ago. Nym.alias.net reportedly is the same > machine as anon.lcs.mit.edu. > > Specifically, is the individual running the nym _known_ to cypherpunks, or > is this an unknown about whom I should have serious doubts. I could tell you who it is, but then I'd have to kill you. So let's just stick to publicly available information. According to the root DNS servers, which as we know are controlled by a ZOG defense contractor, alias.net is an alias for alpha.jpunix.com, and anon.lcs.mit.edu is indeed the same as nym.alias.net. alias2-dom is said to get name service from Sameer and company, but that could be a trap. Obviously, they've infiltrated pretty deep, but thanks to you, we know to be careful. Then again, this could just be FUD from another Fucking Statist. Who knows? Somewhat more seriously, wouldn't it be nice if the various remailers signed each other's keys? - -rich -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMdScnJNcNyVVy0jxAQEwFQH/ZXv+9Nj5ZDjk5FpA33T+kw68H39p/SuW Ab/hRfGGkZX97PIa50C7UVu4YROYE9RYcn7kalsZgFKOsJKAq3JKIw== =1CQg -----END PGP SIGNATURE-----

2 1

rsync and md4
by Andrew Tridgell 17 Dec '03

17 Dec '03

I've recently released a package called rsync that uses a checksum search to provide very efficient file update over a slow link. (see ftp://samba.anu.edu.au/pub/rsync if you are interested) Now I'd like to calculate some probabilities of failure of the algorithm. The fundamental thing I need to know to do the calculation is the probability of a random piece of data of length n having the same md4 checksum as another given piece of data of the same length. A first guess might be 2^-128 but I know that this sort of thing is rarely that simple. Is md4 that good? Note that I am not interested in "attacks" on md4 as such as the source of the random data is just another file provided by the same user, so it won't have been specially designed to defeat md4. If the probability is within a few orders of magnitude of 2^-128 then can I also be sure that if I only use the first b bits of a md4 checksum it will be within a few orders of magnitude of 2^-b ? There is an option in rsync to use a shorter checksum by truncating md4. This saves some bytes on the link at the risk of lowering the confidence. Why md4? I chose md4 because it seemed to be the fastest of the reputedly strong, publicly available checksum algorithms. Suggestions for alternative algorithms are welcome. Cheers, Andrew

2 1