August 1993 - cypherpunks-legacy

Private Message to BlackNet
by anonymous＠extropia.wimsey.com 24 Aug '93

24 Aug '93

1 0

Wimsey Remailer Alive!
by anonymous＠extropia.wimsey.com 23 Aug '93

23 Aug '93

M. Stirner said here: "OK. It seems that remail(a)extropia.wimsey.com (#15) is down. This is a shame, as it was the _only_ remailer that would function as an anonymous remailer for me. It worked beautifully while it was up. Its apparent demise has been reported by other users as well," Reports of the wimsey remailer's demise are premature. I just used it to post this message! One possible cause of problems might be use of PGP version 2.3 or 2.3a WITHOUT the following set in CONFIG.TXT: pkcs_compat = 0 # Use backwards-compatible formats The PGP in use by the remailer may be version 2.0 or 2.1, which will not read PKCS-compatible PGP Messages. The wimsey remailer has an ingenious method of returning error messages anonymously. Specify a subject in the message sent to wimsey that will be meaningful to you, but won't identify you (like a set of random letters). This subject does not appear in the remailed message. Then subscribe to the mailing list errors-request(a)extropia.wimsey.com by sending a message with Subject: subscribe. You will receive a msg for ALL errors detected in incoming messages and ALL bounced messages. Errors in incoming messages are identified by the subject field. Errors from bounced messages are identified by the subject in the bounced message, which is specified following the To: line in the encrypted message sent to wimsey. Wimsey also has an anonymous reply mechanism using a message pool. For more info, send "help" to pool0-request(a)extropia.wimsey.com I think wimsey is also the only Cypherpunks remailer which resides outside the USA (It's in Canada). This obviously makes it much more inconvenient for USA Law Enforcement to broach the physical security of the remailer. Stirner also says: ". All other cypherpunks remailers, reliable or not, retain the footer addresses automagically inserted by the host box here & are therefore not in any way anonymous for my purposes. There was a discussion of a "cut line" syntax before I temporarily lost access to cypherpunks, but as far as I know there was never any agreement or implementation (I shall be pleased to be corrected if this is not the case)." I think the Hall Remailer at <nowhere(a)bsu-cs.bsu.edu> recognizes a "cut line" of --ignore-- I tried this and it failed the first time, but worked the second. You should try a message to yourself before relying on it. Unfortunately this remailer doesn't support encrypted remailing requests. You also may be able to alter or eliminate the automatic signature or footer produced by your BBS. Check your local documentation or ask your SYSOP.

1 0

Attacks on remailers
by hfinney＠shell.portal.com 23 Aug '93

23 Aug '93

Chaum, in his first paper on "Mixes" (anonymous remailers) described protocols which were designed to resist several attacks. (See the February, 1981, Communications of the ACM, p. 84.) These can be understood by considering a series of attacks of increasing sophis- tication, with corresponding responses. Our opponent has as his goal to track a message through a chain of remailers. Attack 1: Just intercept the message from the sender, and look at the commands of the form: :: Request-Remailing-To: first-remailer :: Request-Remailing-To: second-remailer :: Request-Remailing-To: final-destination The final command shows where the message is finally going to go. Response: Encrypt the messages. Use "nesting", so that all that is visible as each message leaves a remailer is the destination of the next remailer. Attack 2: Look at the mail logs on the system running the remailer to see which message goes out from the remailer account shortly after each message comes in. Response: Run the remailer on a machine which does not keep mail logs, or on a machine to which you can deny the attackers access. Attack 3: Monitor the messages in real time as they flow into and out of each remailer machine, again looking for the message which comes out just after each incoming message. Response: Batch up many messages which arrive over a period of time, only sending them out at regular intervals or when a certain number have accumulated. Send them out in random order. Alternatively, delay each message by a random amount of time before the message goes out. (This response will also deal with the previous attack.) Attack 4: Look at distinguishing features of the messages which are preserved by the remailers, such as subject line or message size, to match up incoming and outgoing messages within each batch. Response: Do not retain any header fields through remailers, not even subject. Use an encryption mode in which messages are rounded up to some standard size so that all messages appear to be the same size. Attack 5: Record an incoming message to the remailer, and insert a copy of it into the incoming message stream, so that the batch will have two identical messages. Look for two identical outgoing messages. Remove one. This is the match to that incoming message. Response: Check for duplicate incoming messages in the remailer, and remove all but one copy of each duplicate. Attack 6: Insert a duplicate message multiple times in separate batches. Observe the outgoing batches and look for a pattern of destinations which are correlated with those batches in which the incoming message is inserted. Response: Check for messages which have been duplicated from earlier batches and remove them. Include time/date stamps on incoming messages with a time limit so that they are no good after a certain number of days; this way the check for duplicates only has to go back that many days. Attack 7: Look at all messages coming out of the first remailer, and follow them into their 2nd remailers; take all messages from those and follow them on, and so on. This will eventually lead to a number of destinations, one of which must have been the destination of the original message. Over a period of time, look for correlations between destinations and sources. Response: Use large remailer chains of popular remailers. With enough mixing at each stage of the chain, the number of possible destinations will become astronomically large, making correlations statistically impossible. Attack 8: Correlate messages being sent from person A with messages being received a certain time later by person B. Even without the ability to track messages through the remailers this can show a communication pattern. Response: Send dummy messages at regular intervals, which bounce through the remailer network and then die. When you have a real message to send, replace one of the dummies with this. The sender's traffic pattern is then constant and no information can be gained from it. Attack 9: Bribe or coerce one or more remailer operators into revealing their keys, or into decrypting the desired messages. Alternatively, run many remailers, pretending to be dedicated to privacy, while secretly gathering information on the messages. Response: Use many remailers in a variety of geographical locations, so that it is unlikely that all of them can be corrupted in this way. These are all the attacks I can remember being implicitly considered in Chaum's paper. Other people who have ideas for attacks should mention them so we can think of responses. Chaum also discusses anonymous return addresses. We have a simple form of these enabled in our encrypting remailers. The idea is to encrypt a series of remailing requests for the path the message will follow, with the last request directing the message to the user whose anonymous address this is. Some more attacks are possible in this case: Attack 1A: Look at the message content as it passes through each remailer, to correlate incoming and outgoing messages. Response: Encrypt the message at each stage to prevent this matching. This raises the problem of how to determine the encryption key in such a way that the final user can decrypt the message. Chaum suggested including the encryption key in the anonymous address (a different key at each stage of the chain), so that the user can decrypt the message. Eric Messick has proposed letting the remailer choose the key, with a protocol for the user to communicate again with the remailer to get the message decrypted. Attack 1B: Send two different messages to the same return address with different contents, and look for duplicate address blocks in the outgoing batches. Response: Apply some randomization to the address blocks at each stage so that messages to the same address don't look identical. (Chaum did not give this solution, as he viewed the next attack as being essentially unanswerable.) Attack 1C: Send many addresses to the anonymous address, and look for a destination which receives that many messages in a correlated fashion. Response: Chaum's response is that the remailer must not accept more than one message with a given anonymous return address, just as it must not accept more than one copy of a message in the regular case. This implies that anonymous return addresses must be use-once to be truly secure. This conclusion is uncomfortable, as the requirement that an address be use-once will severely impair its usability. But this attack appears hard to avoid. There is always the possibility of giving up on anonymous addresses in the Chaumian sense, and instead using other ideas which have been suggested here, such as posting to newsgroups, or message broadcast pools. All of these ideas have the problem that they expose everyone in some group to all of the messages intended for every group member, hence the number of messages will scale as the square of the number of group members. This will quickly become unmanageable for large groups, therefore providing only a limited amount of anonymity. It's also worth noting that our remailers are vulnerable to almost all of these attacks; at best we are safe against two or three of them. Hal Finney hfinney(a)shell.portal.com

2 2

Re: "Secure Voice"
by wcs＠anchor.ho.att.com 23 Aug '93

23 Aug '93

geoffw(a)nexsys.net (Geoff White) writes: > Anybody know about the voice capabilities of the ZyXel class modems? > I own a ZyXel 1496E which can digitize voice and also transmit > voice data that has been digitized. It would be easy to > first encript this stream before sending it out. > The 1496E+ also support CELP (or is it (CLEP?) but that one > cost about $400. (The 1496E is around $300) It also is a 14.4 K > baud modem and does FAX. The ZyXel has a 68xxx and a DSP chip. It's able to digitize and compress voice, and also to play back digitized voice, and also to do 9600/14400 modeming, but it can't do all three at once. To build a secure voice phone with Zyxels, you'd need either 2 or 3 modems - one to handle the modem functions, one to compress the voice, and either the same or a separate one to play voice. But it's a good start. What I'd like to see is a SoundBlaster followon with a DSP chip. It IS possible to get DSP boards for PCs and I think for Macs, so you could build a system easily enough with a DSP board and a SoundBlaster, but the last time I checked, the DSP boards tended to be expensive and packaged with lots of fancy waveform analysis tools. Bill Stewart

2 1

Munged account feeding old mai
by s.summers1＠genie.geis.com 23 Aug '93

23 Aug '93

Subject: Munged account feeding old mail? >From Paul Ferguson: >Am I the only one getting carbon copies of many of my own messages >from someone else's munged account? Nope. Even got it here (twice)... Sean

1 0

Digicash
by plmoses＠unix.cc.emory.edu 23 Aug '93

23 Aug '93

>From hughes(a)toad.com Sun Aug 22 20:06:38 1993 >To: plmoses(a)unix.cc.emory.edu (Paul L. Moses) >Subject: [plmoses(a)unix.cc.emory.edu (Paul L. Moses): Digicash....I think] >Date: Sun, 22 Aug 93 17:06:29 -0700 >From: hughes(a)toad.com > >Mail to owner-cypherpunks goes to the bounce box, where it gets looked >at occasionally. Mail to cypherpunks(a)toad.com to send to the whole list. > >Eric > >------- Forwarded Message > >Return-Path: plmoses(a)unix.cc.emory.edu >Received: from emoryu1.cc.emory.edu ([128.140.1.1]) by toad.com id AA06687; Fri, 20 Aug 93 19:36:07 PDT >Received: by > emoryu1.cc.emory.edu (5.65/Emory_cc.3.4.6) via MAILPROG > id AA19400 ; Fri, 20 Aug 93 23:49:26 -0400 >Return-Path: plmoses(a)unix.cc.emory.edu >Date: Fri, 20 Aug 93 23:49:26 -0400 >From: plmoses(a)unix.cc.emory.edu (Paul L. Moses) >Message-Id: <9308210349.AA19400(a)emoryu1.cc.emory.edu> >To: owner-cypherpunks(a)toad.com >Subject: Digicash....I think > > >I hesitate to mention this, since I have *NO* idea of any of the mathematics >behind the digicash articles you all have mention....BUT... > >I was out running errands today and used my ATM card for a cash purchase. >This led me to think, aha, I could simply get this card "charged" every >so often with another denomination ($20, $50, $200, $2000, whatever) and >go around spending my money without the Store having to phone in the transaction. This raises a couple of thought in my mind, namely > 1) Reverse the function of current ATM units, ie use them to >"charge" (as in, activate, add money to) the BANK CARD, rather than the >opposite that we do now... > 2) Find some way to ensure that the card itself does not contain >an identifier, so that the user is not recorded during the transaction. > 3) The card then becomes a bearer instrument of sorts. No big deal; >IT'S JUST LIKE MONEY. People have to be careful with money, so they ought >to be careful with these things too. You could still probably use PIN #s >(personal code), since they're pretty generic and can be selected and >changed by the end user himself....whoops no, on second thought, not unless >the user can encode the PIN himself. Hmm. I dunno. PIN could be OK as long >as it was never recorded in the transaction, but there's the danger of the >transaction program taking a look surreptitiously... > > 4) Digicash exists already. I buy a copy card at the library and >put money onto it, then use it at will in the copy machines. If I lose the >card, I'm outta luck, cos anyone who finds it can use it. Primitive, single >function, but basically what this is about, I think? > >So, what I'm trying to say is that it is possible now to do this, without >any huge breakthrough or legal innovations. If I have missed something obvious, >please enlighten me (gently!). > >- -Paul > >------- End of Forwarded Message > >

3 2

Secure Voice
by Brian J Harvey 23 Aug '93

23 Aug '93

On 8/22/93 Harry Bartholomew mentioned a new "secure voice" product from SVC in College Station, TX. Does anyone have more info on this product, ie a phone number? Question: He states that they offer "lifetime upgrades" but also that they do not mantain cust. records (for privacy), so how does one find out about new releases. Wouldn't one need to "poll the company" to learn of a new release and wouldn't that turn into a headache for the company? (Assuming they've sold significant numbers) Brian

1 0

Munged account feeding ol
by M..Stirner＠f28.n125.z1.FIDONET.ORG 23 Aug '93

23 Aug '93

-=> Quoting Uucp to All <=- Uu> From kumr!toad.com!owner-cypherpunks Uu> From: fergp(a)sytex.com (Paul Ferguson) Uu> To: cypherpunks(a)toad.com Uu> Date: Sun, 22 Aug 93 08:01:40 EDT Uu> Am I the only one getting carbon copies of many of my own messages Uu> from someone else's munged account? Uu> Uu> Error: User "dhaise" isn't on lebanon Uu> Uu> ----------returned message---------- I've received one of these too. ... Try to look unimportant because the bad guys may be low on ammo. ___ Blue Wave/QWK v2.12 -- M. Stirner - via FidoNet node 1:125/1 UUCP: ...!uunet!kumr!shelter!28!M..Stirner INTERNET: M..Stirner(a)f28.n125.z1.FIDONET.ORG

1 0

Remailers, pgp and SMTP.
by b44729＠achilles.ctd.anl.gov 23 Aug '93

23 Aug '93

Perhaps this has been discussed before (I am often guilty of Not Paying Attention(tm)), but would security not be improved for the remailers if people used some simple software to connect to the remailer via socket 25 and send the message that way, rather than leaving log files on their host? For remailers run from student account security could be increased by doing the same; preventing log files by using direct SMTP connections? Ex: (1) User composes message. (2) User encrypts to recipient. (3) User encrypts to remailer. (4) User then mails to remailer using a small program to handle the SMTP connection directly. (5) Remailer (perhaps running on a student account) decrypts message with its secret key. (6) Remailer manually (whenever it gets around to it (to guard against traffic analysis)) SMTP's the message to the recipients host. (7) Recipient decrypts message. Of course these security gains could be circumvented by root (on the remailer) in several different ways, but it would take much more work I would think. Hell, it could be that the remailers already do this (I don't have the code) but I doubt if many people send mail to the remailers by connecting to port 25 of the host. -Sam

1 0

indirect remailer
by cdodhner＠indirect.com 23 Aug '93

23 Aug '93

The indirect remailer <cdodhner(a)indirect.com> still has some bugs to work out with the pgp portion of the scripts etc. Therefore the logs and archive files and debug stuff will remain active until I have time to fix it, probably in a day or two. I'll be sure to let you all know when it's as secure as it can be (as secure as anything can be when I don't have root and somebody else does...) Happy Hunting, -Chris.

1 0