December 2003 - cypherpunks-legacy

Re: REMAIL: Cover traffic
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

Hal writes: > Several people have suggested that the remailers could send bogus > messages amongst themselves in order to allow more "confusion and > diffusion" of the other messages passing through the remailer network. > The remailers could then batch up incoming messages fairly frequently > and still have many messages in a batch. > > The problem with this that I see is that, looking at the remailer > network as a whole, you still may have one message in and one message > out a short while later. The fact that it was temporarily mixed up > with a bunch of other messages doesn't help much if this message is the > only one to leave the network. If the Opponent has the ability to > monitor all traffic into and out of all nodes of the network (as he > would have to do anyway to defeat remailers even without this cover > traffic) then he will easily be able to find the messages which are not > aimed at other remailers. > How about extending the "send bogus messages" idea all the way out to the users of the remailer system? Part of the price of using the remailer system is that you will occasionally receive a bogus message. How might this work? Assume remailers know the addresses of all (or most) of the other remailers. In other words, assume a given remailers knows if an inbound message came from another remailer, or came from a non-remailer address. All inbound messages to a remailer from a non-remailer address would be considered a "use" of that remailer. A remailer would maintain a list of the addresses of "users" and would occasionally send bogus messages to a randomly selected entry from its user list. Inclusion into the list would be automatic. The list would be a large, but fixed sized FIFO, with old entries dropping off the end automatically. If the remailer system uses Digital Postage, then perhaps the bogus message could be a token for a free Digital Stamp, good for one message. I'm sure many will object to tracking the users of a remailer, but I don't see how tracking can be prevented, other than by mutual agreement. Can we use tracking to *increase* privacy? Jim_Miller(a)suite.com

2 1

No Subject
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

Hi Perry, actually I was alluding to one of detweillers comments on cypherpunks no matter... oh and I am just a (he/she/it) for hire to obtain certain technical info for a Blacknet subscriber... I am told that this is the public pseudonym(Sam Hill) used for individuals like myself to protect our privacy while under contract to BlackNet Regards Sam Hill - Blacknet Researcher ------------------------------------------------------------------------- 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.

2 1

Randomness and context
by Jim choate 17 Dec '03

17 Dec '03

To talk about the randomness of a bit stream without keeping in mind the context of that stream will lead one to make assumptions that simply are not valid. An example is probably best. Consider I work as a musician and record my work on a floppy disk. In the context of a musician that data is highly non-random. However, if I then take it and put in a airplanes inertial navigation computer the lord only knows what the computer will do. From the pespective of the aircraft the data is random and senseless. Another example you can do at home is to take a computer CD and play it in your audio deck. If you measure the resultant you will find a musicly random stream of noise coming from your deck. The same can be had if you try to 'run' a music CD as a program. GIGO is not absolute but rather relative to the context of the data and the milieu that it was created and interpreted in.

1 0

Re: REMAIL: Cover traffic
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

jdblair writes: > Jim Miller writes, > > > All inbound messages to a remailer from a non-remailer > > address would be considered a "use" of that remailer. A > > remailer would maintain a list of the addresses of > > "users" and would occasionally send bogus messages to a > > randomly selected entry from its user list. Inclusion > > into the list would be automatic. The list would be a > > large, but fixed sized FIFO, with old entries dropping > > off the end automatically. > > > > > > However, there would be a record of addresses which > anonymous mail had been sent to- probably not a good idea. > Julf's anonymizer has such a record, but I thought part of > the idea of the cypherpunk remailers was to eliminate > these records. > I assume the bad guys can generate their own record of remailer usage. The record could include the addresses used to send messages to remailers and the addresses receiving messages from remailers. They can record when a message enters the system from the outside, and they can record when a message leaves the system. Given they can know all this by just monitoring the remailer system, then there is no reason why the remailers can't also use some of this information. Besides, the "user list" maintained by a remailer only needs to contain the non-remailer addresses used to send messages to the remailer. It does not need to contain any time information or information about the messages passing through the remailer. It also doesn't need to contain destination addresses. Jim_Miller(a)suite.com P.S. After sending my previous message I realized the proposed mechanism still doesn't help Hal Finney's degenerate case where there is only one sender and one receiver, but I've come to believe it is not necessary to solve for that case.

1 0

remailer wailer
by Mark Hittinger 17 Dec '03

17 Dec '03

Please do not pay attention to the arguments by some that improvements which do not solve something *completely* should be forgotten. Please do make some of the changes that the e-vil Det has suggested. If some of them don't work out you can always unwind them. Det strikes me as just another guy who can't keep his mouth shut when he notices an emp-error with no clothes on. :-) Watching internet security is a window on what your remailer situation could be like in 5 years. Right now you have a lot of overpaid network administrators who have not put in important fixes that were stale when the Berlin wall came down! :-) Right now you have a lot of overpaid operating systems "developers" that have cemented and calcified a mass of kludges into the commercial rigor mortis known as Unix. The weakness of these systems is so well known that virtually anyone who wants to take a shot at it can do so. Please do something to raise the difficulty level of screwing around with your anti-police-state tools such as remailers. You don't need to write or devise the end-all solution - just raise the wall a little each year. The kids get their game-genie codes to make video games do things that the original designers did not intend. The kids don't know why the codes do what they do and they don't care to experiment too much to find out what else can be done. A precious and valuable few do. The kids on the internet are like the game-genie kids in many ways. They avidly wait for the next phrack so that they can get the latest SUNOS game genie code. Perhaps this month its another sendmail flaw, or maybe a /dev/nit problem. In any event, there will be a recipe for doing it and the kids don't care why it does what it does, or what else can be done. We have an entire generation of "hackers" who are of little use to "us" because they can't blue sky, read source code, theorize about a hole/race condition, and set up a test to exploit it. All they care about is having the latest "how-to" sheet. If the operating systems developers and network administrators had been raising the difficulty level all along the kids would either drop out or get better. The ones that got better would be of use. Don't let the remailers go the same way. Please do some of the minimal things to cover some of the common ideas. If someone comes up with a neat twist and still pulls something - *great*. At least it will be fun. There is nothing more boring than a continual series of attacks using a stale technique. You guys could breed that for the future if thats what you want. Some kid with a remailer genie code could get the press or government interested in your toys before you want them to know. It would really be funny to see you guys form a "RERT" modeled after the highly successful "CERT". Remailer emergency response team. Do something! You have no clothes! You live in a glass house! A stitch in time saves nine! Finally - an old system administrator experience is to never delete the accounts of trouble makers. Always leave their favorite accounts be. It is much easier to keep tabs on them. If you harrass them they will go underground and you will miss things. --------- Whats back with the wrong-ups? Finger me for pee gee pee

1 0

clipper pin-compatible chip
by rarachel＠prism.poly.edu 17 Dec '03

17 Dec '03

Here's an idea right out of the Intel-Cyrix-AMD wars. Once the clipper chips are common place, perhaps we could get some company to build IDEA chips that are pin compatible with the clipper chip itself, and perhaps even some switching socket where if you're calling a device and want to use the clipper chip (due to compatibility reasons of course) you activate the clipper chip socket. If not, you flip the switch the other way, and activate the IDEA chip. All we need are pinout, timing/signal specs and a few cypherpunks who are/were EE majors. :-) The chip switching mechanism itself is no big deal. In the worse case we could adopt an Atari/Nintendo type solution where you have a socket for a plug in cartridge which contains the encryption chip of your choice. You then call up your friend and tell him to use his IDEA cart and you do the same. Or RSA, or anything you like. If we could convince hardware manufactures to include chip sockets, this won't be an issue any longer. Which would Joe Bloe using a celular phone prefer? The clipper chip when he knows any spook can listen to him, or a third party IDEA chip which is quite secure? The IDEA cartridge could have some rotary switches with numbers on them to set for a 128 bit key. Sort of like the push button SCSI device ID selectors on external cases. Perhaps the cartridge might even have a touch tone like keypad for typing in a pass phrase.... etc. This could be done quite cheaply. Hell, you could probably just use a 68000 a ROM and a say 64K of RAM and not need a special IDEA chip.

2 1

Re: REMAIL: Cover traffic
by rarachel＠prism.poly.edu 17 Dec '03

17 Dec '03

Why can't the remailers themselves send encrypted mail to each other totally masking the incoming messages? Each remailer can have a public/private key associated with every other remailer on the network, with full pgp type signatures to prove they came from a remailer and not a spook or nym? Each remailer has a fingerable public key. When remailer x sends a message to remailer y, it encrypts it with y's public key after fingering y, and also signs the message. Y could also be a paranoid remailer, and if it doesn't know X, it could tell it to go stick its message up its SCSI port. :-) All these ideas along with trash junk mail being sent every few minutes could work. Even better, have each remailer send a specific number of messages to each of the other remailers on the network. These messages would be bogus messages, however, there would be a fixed number of them. If a real nym message arrives, it is sent to the next mailer up the chain, as part of the n (n-1 now) that are bogus. That way a spook couldn't tell where a message was going since he couldn't count the number of messages going out of the mailer. Also if a target remailer has n real messages to be sent to, any messages over that assigned packet size of messages get spooled for the next round of bogus mail. This way each remailer will send exactly n messages to every other remailer on the net every specified period of time. What kind of analysis can be done with this sort of scheme?

1 0

Re: Randomness of a bit string
by doug＠netcom.com 17 Dec '03

17 Dec '03

Tim May said: >I stand by my point that no number or sequence can be proved to be random. To expand a bit on Perry's arguments, the bottom line of all this research is that a claim regarding randomness can only be made *relative* to a particular system for specifying algorithms. In that sense, Tim's statement can be regarded to be correct, iff one assumes that a context (an algorithmic specification system) is not given. That is a huge qualifier, though, and not one to be taken for granted. A trivial example of this: pick some constant bitstring of length 32 or less. Call it K. Now look at the class of algorithms specifiable by the C code fragment printf("%x", K) --- i.e. print K as a hexadecimal number. Relative to that particular set of (one) algorithms, that value of K is trivially nonrandom, in the sense that the probability of of finding that bitstring produced by that class of algorithm is precisely 1. Next consider a program that computes an output by multiplying some input by two. The probability that the output will be K, given any possible (but unknown) input, is exactly zero if K happens to be odd. If K is not odd, then the probability depends on the distribution (randomness) of the inputs. Proceeding in this fashion, it becomes increasingly clear that the randomness of the output of an algorithm can only be measured relative to the properties of the class of algorithms being considered. Randomness in isolation is meaningless. The best sources of intuition regarding randomness usually derive from systems which shift the burden into an existing intuition on a slightly different subject. For instance, flipping a coin can be regarded as a random process in an intuitive sense, but only because it appeals to existing intuitions about equiprobablistic outcomes. Therefore one sees confused appeals to intuition about randomness, probability, entropy, or related ideas, in cryptography, quantum mechanics, information theory, statistical mechanics, philosophy (in regard to free will versus determinism versus randomness), etc, etc, but given Chaitin/Kolmogorov/et al, no intuition from any such subject should be taken at face value. There's more, but I'll pause to allow flames. :-) Doug

2 1

Mondex digital cash press release
by Stanton McCandlish 17 Dec '03

17 Dec '03

This may be of interest to those of use following electronic money issues. Forwarded message:

1 0

Mondex digicash system
by Mike Ingle 17 Dec '03

17 Dec '03

Are there any technical details as to how it works? It is supposedly anonymous, divisible, transferrable, and offline. I've never seen a practical protocol like this. The message said you could put cards in an electronic wallet and transfer money between them. How can you do this, without losing anonymity? Is it possible this system is security through obscurity or observer-based, as opposed to a pure cryptographic protocol? If the security is non-cryptographic, it will probably be hacked eventually.

1 0