December 2003 - cypherpunks-legacy

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

Re: Purpose of Data Havens
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hal writes: > 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 Eric notes elsewhere, off-site backups are useful in general in case some physical calamity strikes your site. It seems to me that a data haven addresses a more aggressive threat model than this. Rather than just worrying about the act of a hacker / nature / etc. eradicating our local copies of data (encrypted or not), we're concerned about intelligent agents (human or electronic) attempting to commit genocide on all instances of some data we possess. Scenario: June is a test engineer at Rockwell Intl. At the lab where she works, it is observed that some rubber O-rings being designed for the space shuttle are liable to crack, and lose their airtight seal, when exposed to the extremely low temperatures of space. The project is behind, so the researchers are instructed to proceed in spite of the problem. June encrypts the test results and deposits them in a data haven. Then she calls her boss's boss and offers a deal (whitemail ?). Either the part is redesigned, or she'll present the incriminating evidence to the New York Times. Even if Rockwell sends some goons to June's apartment while she's at work the next day, to reduce her laptop to solder, she still has the means to carry out her threat. "Rikki don't lose that number - send it off in a letter to yourself"-Steely Dan -L. Futplex McCarthy - --- [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 iQBFAwUBLxVwgSoZzwIn1bdtAQF0vwGAuLRLR9PVcj9Q8NCqNDvRf4bC5zUA4A/U m/9tT74hoQNEBNEzw1TqZTr0ZxHtciwd =uXUO -----END PGP SIGNATURE-----

2 1

Re: Reefer madness
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 9:35 AM 01/12/95, Russell Nelson wrote: >misdemeanor. I spoke to Bob Penna, the legislative aide who >researched and wrote up the bill for Bill Sears. He realizes that the >Internet cannot reasonably be censored, and that the solution is to be >able to punish people who do it (hence the felony) and to educate I dont' find that particularly reassuring. "being able to punish people who do it," is ultimately going to have to consist of preventing non-GAK encryption, in the minds of the Gubmint. You can't punish them if you can't catch them, and you can't catch them if they use strong encryption. Well, in reality you still can catch them, after all no one can sexually assault anyone over the internet (yet, anyway). Sometime they've got to do something in person, and there's no encryption in a physical meeting, where everyone sees your TrueFace. But I'm not sure how much I trust the gubmint types to take this all into account, instead of just abolishing crypto on the typical four horsemen platform.

2 1

Re: Data Havens..A consumer perspective
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 4:30 AM 01/12/95, Nesta Stubbs wrote: >> 4. It is no concern (only idle curiosity maybe) where the data is parked. > >it matters alot too me, that's the security of the dat, what if your data >is sem top secret plan to bomb the pentagon, and you are using the data >haven to distibute to your band of anonymous terrorists, I am sure you >woudln't want your data stored ona public access Unix system, or in >plaintext. You shouldn't ever give the operator the info in plaintext. Encrypt it, public or otherwise, and distribute the key to your Band of Merry Men. Then it doesn't matter even it's sitting on a public access Unix system, no one can read it anyhow. The main point of this kind of data haven seems to be providing you a remote location to store your data, in an anonymous way, so even if it does end up being found out, you can't be linked to it. I wouldn't trust the operator to do anything particular with the data other then keep it safe enough so I can retrieve it later, and I'd take the neccesary precautions to account for that lack of trust. The only reason I'd trust him to even keep it safe for me, is because of reputation market. If he routinely loses people's data, word is going to get around. On the other hand, if he routinely shows people's data to the FBI, no one is even going to know about it. I don't trust him not to routinely show the data to the FBI, or store it in public. Use encryption. Of course there are different purposes for data havens, which would require more trust of the operator. But I'm not sure how well those are ever going to work, because I'd much rather trust my encryption then trust the operator.

2 1

Re: How do I know if its encrypted?
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 12:01 PM 01/12/95, Hal wrote: >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. Hmm. I post through a long anonymous remailer chain to an appropriate newsgroup: "I have made an archive of state secrets (or trade secrets, for that matter, or pornography), available on data haven Wherever. Ask to receieve the following file for a list of contents." Seems it could be useful. Especially if you had some way of extracting digicash payment from it, in an anonymous way. But even if you didn't, perhaps you want to make this info available as a public service. I sure as heck wouldn't want it sitting on a hard drive in my bedroom.

1 0

Farewell for a bit
by dfloyd＠io.com 17 Dec '03

17 Dec '03

I need to work on the DH code, so I am unsubbing for a while. Please can the cheers, allright? ;-)

1 0

Re: Reefer madness
by Mark Grant 17 Dec '03

17 Dec '03

On Thu, 12 Jan 1995, Russell Nelson wrote: > I really *don't* think that New York State plans to > ban encryption, not now and not over this issue anyway. His thrust is > 1) to have the legal authority to sufficiently punish someone who goes > after children (which they don't have now), and 2) to educate guardians > about the risks of untoward communications from adults to children. But what happens if, say, a minor is solicited for sex when they are pretending to be older than they are ? Or if the solicitation comes via a remailer ? Or a minor with a grudge fakes email to show that someone attempted to get them to agree to sex/picture-taking or whatever ? Once you pass laws making some forms of communication illegal, you're immediately getting into dodgy territory requiring is-a-person credentials and so on. That isn't neccesarily a problem if it's voluntary (e.g. your kids accounts might be set up to only accept mail from people who're certified to be under 18 or whatever), but governments are unlikely to do things that way. Mark

1 0

Re: Chain and Shifting Remailer Addresses
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Offshore Assets writes: > I use Hal Finney's 'Chain' a lot: Uh, I think you probably mean Lance Cottrell, not Hal -- unless Hal's also written a similar utility with an identical name, about which I haven't heard. > [...] 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). Alex de Joode posted a copy of the usura key edited to reflect the domain name change to alt.privacy.anon-server. It's presumably on the keyservers.... Oh, and the flame remailer passed away with the closure of the jpunix remailer, as far as I can tell. (I vaguely recall something to the effect that sinet.org is/was registered as a subdomain of jpunix.com, but I might well be wrong.) Hope this helps. -L. Futplex McCarthy - --- [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 iQBFAwUBLxWIfyoZzwIn1bdtAQHcYwF/alAsviWQvyzf4Qg1JR+G0l1sP3o6AGZN xvaxIZsKhhX03RNogflWZPBah3y8DnCa =aVDR -----END PGP SIGNATURE-----

1 0

Re: Reefer madness
by fhalper＠pilot.njin.net 17 Dec '03

17 Dec '03

mark(a)unicorn.com wrote: But what happens if, say, a minor is solicited for sex when they are pretending to be older than they are ? Or if the solicitation comes via a remailer ? Or a minor with a grudge fakes email to show that someone attempted to get them to agree to sex/picture-taking or whatever ? Once you pass laws making some forms of communication illegal, you're immediately getting into dodgy territory requiring is-a-person credentials and so on. That isn't neccesarily a problem if it's voluntary (e.g. your kids accounts might be set up to only accept mail from people who're certified to be under 18 or whatever), but governments are unlikely to do things that way. Any person no matter their age should be wary if someone solicits them for sex. I'm 16 years old and have been on the Internet for a little more than a year and I haven't nor have I met anyone who has been approached by a pedophile. The examples used are isolated incidents, which could have likely been prevented had they discussed it with their parents or tried to obtain more info about the person they were going to meet. -RH --------------------------------------------------------------------------------- Reuben Halper I'm not growing up, I'm just burnin' out." Montclair High - Green Day - Montclair, NJ E-mail: fhalper(a)pilot.njin.net PGP 2.6ui Public Key available upon request ---------------------------------------------------------------------------------

3 2

LPF Statement on the GIF controversy
by Dean Anderson 17 Dec '03

17 Dec '03

[ Please repost this wherever you think is appropriate! ] Until now, most computer professionals and companies have ignored the problem of software patents. The GIF format for graphical images was adopted widely on the net, despite the Unisys patent covering the LZW data compression algorithm. The patent dates to 1985, but its enforcement has been carried out with private threats; most victims are afraid to talk about it. Now the patent has shown its teeth. For a few days, the Internet community was shaking with anger at the surprise demand to pay license fees for the use of GIF format. It turns out that the license being offered today is only for Compuserve users. Compuserve accepted an offer from Unisys that they couldn't refuse. Compuserve users can accept this offer now, or face Unisys later on their own. The rest of us don't have a choice--we get to face Unisys when they decide it's our turn. So much trouble from just one software patent. There are now over ten thousand software patents in the US, and several thousand more are issued each year. Each one may be owned by, or could be bought by, a grasping company whose lawyers carefully plan to attack people at their most vulnerable moments. Of course, they couch the threat as a "reasonable offer" to save you miserable years in court. "Divide and conquer" is the watchword: pursue one group at a time, while advising the rest of us to relax because we are in no danger today. Software patents may not seem like an urgent problem until you find one aimed at you. We all have other fires to fight, and most developers have hoped that the patents would never blaze up. In an ironic way, Unisys has done us a favor--by showing that the problem is too serious to ignore. What people first feared, could just as well have happened. Each of the thousands of software patents has the potential to devastate a segment of the community, both software developers and users. There will be more nasty surprises. They are part of a system. Unisys has given us a chance to work together to change the system--rather than waiting to be sued one by one for this patent or that. We can win the fight against software patents, if we speak loud and clear against them. What can people do? * Express your disapproval to Unisys by writing a letter to its CEO. Tell him what you think of his company's actions: James Unruh CEO UNISYS Corp. PO Box 500 Blue Bell, PA 19424 fax: 215-986-6850 Please use snail mail--a physical pile of letters is more impressive, psychologically, than a big file of email. Keep it short--ten lines is enough. Don't spend hours composing your letter; there's no need. But do write it in your own words, because sending a form letter written by someone else is not impressive. Make it clear that the usual excuses--"We're just exercising our property rights; look how reasonable we are being (compared to what we _could_ have done)"--won't wash with you. Avoid saying anything nasty that would give Unisys a chance to paint itself as the victim. Cold condemnation is more powerful than flames. Please email a copy of your letter to the League for Programming Freedom at gif-letters(a)lpf.org. We might ask you for permission to publish your letter. * Don't sign a license--stop using GIF. The World Wide Web consortium at MIT will probably be coordinating the move away from GIF, and offering advice and assistance. See `http://www.w3.org/'. * Join the League for Programming Freedom. The League is a membership-based organization whose aim is to bring back the freedom to write software. The League says that no one should be able to dictate what kinds of programs you can write. You can contact the LPF by email to lpf(a)uunet.uu.net, or look at its Web pages at `http://www.lpf.org/'. ** Note: the recent license demand came in the name of Compuserve; but the impetus for it came from Unisys. Compuserve developed the GIF format many years ago, not knowing there was a patent on LZW. (Most programmers have no idea what patents their programs are vulnerable to--there are too many patents to keep track of.) When Unisys threatened to sue them, Compuserve had to give in to Unisys's demands. Compuserve arranged to be allowed to offer Compuserve users a sublicense, but the "offer" was formulated in a way that was tantamount to an ultimatum. Compuserve may bear responsibility for some of the details of how this was handled, but the main responsibility falls on Unisys. It is Unisys that claims the power to dictate what kinds of software you can write. Unisys decided to use the power for aggression; Unisys forced Compuserve to participate. =++=+=+=+++==++=+=+=+++==++=+=+=+++==++=+=+=+++==++=+=+=+++==++=+=+=+++= Dean Anderson Dean(a)hi.com President League for Programming Freedom

1 0

Re: Reefer madness
by Blanc Weber 17 Dec '03

17 Dec '03

From: Sandy Sandfort Ever seen a Turkish prison film, Reuben? ......................................................... I don't get it. (I haven't seen one) Blanc

3 2

Re: Multiple symetric cyphers
by pdlamb＠iquest.com 17 Dec '03

17 Dec '03

>In article <199501120502.VAA29808(a)largo.remailer.net>, >Eric Hughes <eric(a)remailer.net> wrote: >> From: cactus(a)seabsd.hks.net (L. Todd Masco) (bunch of stuff deleted) >> I guess this reduces to: do strong cyphers have "signatures" of some sort, >> by which the type of encryption can be derived? >> >>If they do, they're likely not _strong_ ciphers. > >Great... that's the answer I was looking for, and what my gut feeling >was. I'm trying to determine how much rope is too much for a first pass. > >Related: is there, in general or in any known specific cases, any loss of >security in using sym. cipher A on ciphertext B (of another sym. cipher) with >the same key? With different keys (I would think not, but I vaguely >remember mention of something here long ago)? Is this asking the question, "Does DES form a group with IDEA?" (Substitute your favorite cipher.) Since it took about 15 years to figure out DES is _not_ a group, I suspect it will take a long time to figure out the answer to that question for each pair of ciphers you're going to substitute. Seems to me it's a good basic idea. If it costs, for example, a million bucks to crack a cipher; you have three ciphers that can be used; then the best-case cost to crack a message just tripled! Of course, if you choose two ciphers stronger than DES, it probably went up a little more (g). If the ciphers don't form a group, you just made your system unbreakable. Just use two ciphers. Then a brute-force attacker has to check each key for each cipher once when it is applied first, and once for each of the possible keys for the other cipher when it is applied second! Sounds too good to be true. Am I missing something? Pat

1 0

Re: How do I know if its encrypted?
by daleh＠ix.netcom.com 17 Dec '03

17 Dec '03

You wrote: >You don't always need the correct answer. You just need the correct >answer most of the time. You're trying to create a presumption about >behavior. Ensuring that you can't read almost all of the traffic is a >pretty good way to assure people that you don't try to make sense of >any of it. I'm still not making my point. Encryption is not a data 'state' that can be tested for in the way that liquid/solid/vapour are states of matter. Encryption is a data 'interpretation' for which there are an arbitrairly large number of interpretations available for any given dataset. There is no algorithmic test that can applied to a dataset that will be able to establish the existance or non-existance of a given interpretation. If you're given an unkown dataset and are asked the question, 'Is this an image file' or 'Is this an encrypted file' or 'Is this an audio clip', there is no algorithmic test that can answer any of these questions in either the affermative or the negative. This is just an alternate phrasing of Goedel's Undecidability Theorem. This problem lies permanantly outside the outer boundary of algorithmic capability. Let me now spin a little tale as to how this affects an operator of a re-mailer or datahaven. This tale has two characters, Paco the child pornogropher and Eric the honest RM/DH operater. Paco begins by inventing the new 'Foolproof Barometric Graphic Image Format' (aka FooBar GIF) of which only Paco knows the internals. A FooBar GIF has a statistical profile that looks remarkably like a PGP file, in fact it even comes with a PGP header! Nothing illegal here. Now Paco writes a FooBar GIF Viewer which he sales to child-porn types. Again, there's nothing illegal about the sale of such a piece of software. Paco now anonymously loads Eric's DH with lots of child-porn FooBar GIF's via Eric's anon-RM. These files of course sail right through Eric's filters with nary a scratch. As far as Eric knows he's holding PGP encrypt files. Now Paco advertises the availability of lots of 'good' picture on Eric's DH that can be used with the newly purchased FooBar GIF Viewers. Then the cops get ahold of one of Paco's FooBar GIF Viewers and downloads some FooBar GIFs from Eric's DH and the last words we ever hear from Eric are "I swear I thought they were PGP files, I swear to God I thought they were....." as the authorities drag his carcass off to jail. Whose going to believe Eric's protests of innocence? "After all", says the prosecutor to the jury, "wasn't Eric explicitly filtering out what he didn't want in. If fact", says the prosecutor, "his filter seems to have been designed specifically to allow these kiddie-porn files in and to reject all others." A sad end indeed! Dale H.

2 1

Re: Multiple symetric cyphers
by grmorgan＠freenet.vcu.edu 17 Dec '03

17 Dec '03

> >> But selecting a single cipher is just as much a fixed policy as a >> randomly selected one is. Far better to let the user pick a policy, >> both about sent and accepted ciphers. > >If you do give the user control, what is an acceptable mechanical >implementation? Let's say I have a file encryptor which allows the >user to choose between DES, 3DES, IDEA, Diamond, and RC5. Must I >require the user to tell that program what cypher was used to encrypt >the file she wishes to decrypt? > >Is storing the cypher type as part of the encrypted file a weakness? Perhaps an MD5 of the password could be encrypted along with the plaintext using the method(s) of choice. At the decryption phase, the password would be MD5 hashed again and the block of bytes the size of an MD5 hash would be "decrypted" with each of the methods... which ever one matches the original MD5 hash would be used to decrypt the rest of the cyphertext. This method wouldn't leave a known plaintext in the file to attack. -- ----------------------------------------------------------------------------- Greg Morgan <grmorgan(a)freenet.vcu.edu> | "I dunno Brain, me and Pipi

1 0

Re: Microsoft TrueName (tm) (fwd)
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 11:23 AM 1/12/95, NetSurfer wrote: >I wondered why one of the few registered hosts for Microsoft were called >"Bob" - now it makes sense. (But they've got a good sized chunk of >netblks registered...) Funny thing happened to me last night. I was talking to a guy who had seen Fidelity's new WWW server (shhh! don't tell!) and it turns out he was the guy who actually *had* bob.com. A third party approached him and asked him if he wanted to sell the domain name. He did. He picked another domain name, and last week someone called him if he wanted to sell his *new* domain name. He said no, and they asked him if he would *rent* it to them... Go figure. Cheers, Bob Hettinga Eric, what'll you take for "remailer.net"? ;-). ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

2 1

Available: Cash paper by anonymous FTP
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>From: brands(a)cwi.nl >Original-From: Stefan.Brands(a)cwi.nl >Subject: Available: Cash paper by anonymous FTP >To: www-buyinfo(a)allegra.att.com >Date: Thu, 12 Jan 1995 18:57:39 +0100 (MET) >Mime-Version: 1.0 >Status: U > > > I have made available for ftp-retrieval my paper > > "Off-Line Electronic Cash Based on Secret-Key certificates." > > This paper will be presented at the Second International Symposium of > Latin American Theoretical Informatics (LATIN '95), April 3-7, 1995. > > If you are interested in downloading a copy, login by anonymous ftp at > > ftp.cwi.nl > > The paper is in the directory pub/brands, under the name > "latin95.<ext>." The extension <ext> refers to dvi and PostScript > formats. > > Greetings > > Stefan Brands, > ------------------------------------------------------ > CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands > Tel: +31 20 5924103, e-mail: brands(a)cwi.nl > > ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

Paper on NetCheque and requirements of network payment services
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>From: bcn(a)ISI.EDU >Date: Thu, 12 Jan 1995 11:11:49 -0800 >Posted-Date: Thu, 12 Jan 1995 11:11:49 -0800 >Original-From: Clifford Neuman <bcn(a)ISI.EDU> >To: www-buyinfo(a)allegra.att.com >Subject: Paper on NetCheque and requirements of network payment services >Status: U > >There is a new paper available on NetCheque(TM) and requirement of >network payment services. The paper will be presented at IEEE Compcon >in March. The paper can be retrieved from prospero.isi.edu in > >/pub/netcheque/information/netcheque-requirements-compcon95.ps.Z. > >Clifford Neuman ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

San Diego CPunks Symposium
by Claborne, Chris 17 Dec '03

17 Dec '03

CPUNKS symposium Thursday, Jan 26, 1995 Invitation to all Cypherpunks to join the San Diego crowd at "The Mission Cafe & Coffee Shop" were I hope to get an update of weasel man's new anonymous e-mail server, "mixmaster", exchange keys, and generally shoot the shit. Don't forget to bring your public key fingerprint. If you can figure out how to get it on the back of a business card, that would be cool. Place: The Mission Cafe & Coffee Shop 488-9060 3795 Mission Bl in Mission Beach. Time:1800 Their Directions: 8 west to Mission Beach Ingram Exit Take west mission bay drive Go right on Mission Blvd. On the corner of San Jose and mission blvd. It is located between roller coaster and garnett. It's kind of 40s looking building... funky looking (their description, not mine) I will be wearing a BRIGHT PURPLE BICYCLING JACKET. Try to be their by 18:30 since we may move the meeting. See you there! Weasel man, don't forget to bring the latest info on mixmaster. Fish man, sweep the place for bugs. Anarchist, the FBI has already setup surveillance. Law man, bring the logo and your e-mail address of the month :) New guy, bring your fingerprint. NOTE: My e-mail address, "chris.claborne(a)sandiegoca.attgis.com" permanently replaces my .ncr.com address. Both address work for now but NCR address will eventually be killed. 2 -- C -- P.S. Tell your wife/husband you are going to a symposium. Unless she/he looks in the dictionary, she/he won't know that your are really going to a drinking party! ... __o .. -\<, chris.claborne(a)sandiegoca.attgis.com ...(*)/(*). CI$: 76340.2422 PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

1 0