December 2003 - cypherpunks-legacy

punk hardware list possibilities
by jdblair＠nextsrv.cas.muohio.EDU 17 Dec '03

17 Dec '03

Relating to the discussion of setting up a cypherpunk hardware related list... I would be able to host a list on the machine here, most likely-- its a little used (relatively) and a pretty open system. Let me know if anybody is interested. -john

1 0

ID of anonymous posters via word analysis?
by jazz＠hal.com 17 Dec '03

17 Dec '03

This brings up the subject of how one can post without leaving an "ASCII fingerprint". I suspect the use of a spelling checker and grammatical checker would help. Perhaps running your text through a language converter, (say English to French) then back would remove many identifying characteristics. Two words: "jive"; "valspeak". Okay, two more: "swedish chef". Sure, it makes it a little harder to extract semantics from a message, and it can be hard to keep from giggling at the results, but those lex-based filters would work much better than some English->French->English translator program. You'd want to run the results through a reading-level checking program to make sure you knocked out the 64-dollar words; the size of ones vocabulary is one of those "identifying characteristics." Jazz

1 0

trusting software
by doug＠netcom.com 17 Dec '03

17 Dec '03

How does one know that one can trust the software that one is using on one's own machine for encryption, mailing, etc, or worse yet, how can one know whether to trust the software doing anonymous or other remailing on other machines? Web-of-trust schemes are only statistically reliable due to these concerns. These are rhetorical questions; the point is, I just realized that I didn't explain myself last month when I talked about an algorithm for verifying *intentions*. A number of people emailed me to complain that authentication should be a matter of establishing a person's *real* identity -- a valid issue, but I was off on a tangent and neglected to explain my actual point: Imagine you have a single piece of software which runs a dcnet over the internet by being instantiated on many nodes. Imagine that you're concerned that the NSA or someone will spoof a whole bunch of nodes, pretend to be the Real Software (which ordinarily helps guarantee anonymity, defeat traffic analysis, etc), but actually works to defeat the Real Software and the people who use it. One would like to somehow guarantee that when one talks to remote software as part of a web of trust scheme, that the software really is the One and Only True Software, and not some deceitful counterfeit. It is in *this* connection that one might wish to authenticate the unique identity of multiply instantiated *software* by a hypothetical process which ascertains the *intentions* of that software instantiation. I previously phrased this as if it were a person that the hypothetical algorithm was authenticating, leading to understandable objections. Apologies; I had gotten into a digressive train of thought about using it with people before I posted, and it's taken me this long to realize that I never communicated clearly. I still haven't described the algorithm ("this margin is too narrow" :-), but I hope it's more clear that such an algorithm is potentially more realizable for software than it would be for people. Doug

1 0

Remailers...
by csm2747＠NebrWesleyan.edu 17 Dec '03

17 Dec '03

Ok, Ok, I'll admit I'm a newbie to encryption and the like. This idea of remailers seems excellent. My only question how do I use them? Also where could I get more info about all this? The ftp at soda.berkeley looks like a good place to start...any suggestions on specific files or programs, beside PGP. Thanks. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Chad Mawson *-* Nebraska Weseleyan University <> Lincoln, Nebraska *-* | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ csm2747(a)hobbes.nebrwesleyan.edu

1 0

message depots
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

The mailing list has been pretty quite today. How about a new(?) idea to kick around... One of the main unsolved problems with anonymous remailer networks is that, somewhere, there has to be a remailer that knows the mapping from your anonymous identity to your real identity (or at least your real e-mail address). This means that you will have to trust the person running the remailer. It seems to me that as long as remailers use a message *delivery* paradigm, this problem is unsolvable. However, there is another paradigm that can be used which can solve this problem. I call it the "message depot" paradigm. It wastes a lot of bandwidth and cpu cycles. However, I believe that in the not too distant future we'll have more bandwidth than we know what to do with (Telecosm). Perhaps someday we'll also have more cpu cycles than we'll know what to do with (cray on a chip). When that day arrives, this idea will become practical. Until then, it will probably just be a toy. Still... Here how I see it working... Simplest case: One message depot Not too different from a message-only BBS where all messages are encrypted. If Bob wants to send a secure message to Alice and defeat traffic analysis, he will encrypt the message with Alice's public key and send it to the message depot. Alice (and everyone else) periodically grabs *all* new messages from the message depot and attempts to decrypt them. Alice finds that she can decrypt one of them; the one from Bob. If Bob signed the message before encrypting it, and Alice has Bob's public key, she can verify the signature. Of course, this doesn't means she knows who "Bob" is, just that "Bob" sent the message. Replace "Bob" with you favorite 'nym. Since everybody is periodically downloading all new messages, the message depot doesn't know which message goes to which person. Also, since the only clue to the sender's identity is the message signature, the message recipient may not know the identity of the sender. (It would depend on how the recipient got the sender's public key.) Scaling Up a Step: Multiple message depots Place a dozen message depots in the picture. They each publish a unique public key, which means that people can send encrypted messages to the depots as end points. The depots would poll each other for new messages to see if there is a message encrypted with their public keys. Example: Depot A polls depot B for new messages. Depot A attempts to decrypt the new messages. It finds one that it can decrypt. Upon decrypting the message, the depot sees a depot command and more message. The one and only depot command will be: "PUT THE REMAINDER OF THE MESSAGE IN YOUR MESSAGE POOL AS A NEW MESSAGE". Any message the depot cannot decrypt will be discarded. How is this useful? Well, by nesting a message in layers of digital envelopes, a sender can effectively move the message around the set of message depots until it reaches a depot that the final recipient polls. Lets say that Bob knows that Alice polls Depot E, yet, for some reason, Bob doesn't want to send the message directly to Depot E. What does he do? He first signs the message with his private key (if he wants to), then encrypts it with Alice's public key, appends the depot command and encrypts everything with Depot E's public key, appends another depot command and encrypts everything with Depot B's public key. He then sends the result to Depot B. Depot B decrypts the message, sees the depot command, strips it off and places the remainder in its message pool as a new message. Some time later, Depot E polls Depot B for new messages. Depot B obliges. Depot E attempts to decrypt the messages, finds that it can decrypt one of them. It sees the depot command, strips and posts the remainder of the message to its message pool. Eventually, Alice polls Depot E for new messages. And you can guess the rest. If Bob doesn't know which message depot Alice polls, he can send copies to a number of different depots and hope that Alice will find it. If he sent it to *all* depots, Alice will eventually get the message (unless she stops polling altogether). Messages depots will delete messages after a configurable amount of time. Also, the depots will not keep track of who has sucked down which set of "new" messages. This implies that the people polling the depots will have to tell the depot they want all messages since a given time. The client-side polling software can easily keep track of this for the user. Interfacing to the rest of the world: To support sending messages to specific e-mail addresses or news groups, somebody will have to run a remailer that polls the message depots. A sender will encrypt a remailer command and a message using the remailer's public key and direct it to the depot that the remailer polls. The remailer will find the message and interpret the remailer command. The command could be "SEND THIS TO <an Internet address>", or "POST THIS TO <a newsgroup>", or whatever. Replies would have to travel back through the depot net. The body of the message can indicate a message depot to "reply" to. I believe most of this message depot idea can be automated. As you can see, this mechanism consumes lots of bandwidth and lots of cpu. But it does not require that you trust any part of the system except the part that sits in front of you. I also believe that it successfully defeats traffic analysis. "All the smarts will be at the fringes of the network." - the guy who is writing Telecosm (and whose name escapes me). Jim_Miller(a)suite.com

3 2

pseudospoofing SF
by L. Detweiler 17 Dec '03

17 Dec '03

cypherpunks interested in identity mutations, perversions, and crimes like MPD, impersonation, pseudospoofing, etc., and developing a legendary anecdotes and a complex mythology regarding it all with e.g. compiled science fiction references, (who comprise the majority of the members, based on my mail and enemies) may be delighted by the masterpiece novella `Mefisto in Onyx' by Harlan Ellison in the Oct. 1993 Omni magazine.

1 0

ciphers and such
by Lloyd Cowling 17 Dec '03

17 Dec '03

Cipherpunks: I have a long running interest in ciphers. Could you put me on to your modis operundi and FAQ's, etc. Where I might find out more about you and what you do? Thx - Lloyd

1 0

Re: message depots
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

It seems the message depot idea is not terribly original. Oh well, I'm not too surprised. I suspected this and that's why I put "new(?) idea" in my post. I can at least pat my self on the back for reinventing it a few years late. :-) Jim_Miller(a)suite.com

1 0

Er?
by Johan Helsingius 17 Dec '03

17 Dec '03

Anyone have any idea what this is about? Anon.penet.fi is being bombarded by an endless flow of these... Julf ------- Forwarded Message X-Envelope-To: na26436 Received: from hydra.acs.uci.edu by anon.penet.fi (5.67/1.35) id AA21686; Thu, 4 Nov 93 16:42:48 +0200 Received: by hydra.acs.uci.edu id AA24199 (5.65c/IDA-1.4.4 for na26436(a)anon.penet.fi) Thu, 4 Nov 1993 05:47:52 -0800 Date: Thu, 4 Nov 1993 05:47:52 -0800 From: Mail Delivery Subsystem <MAILER-DAEMON(a)hydra.acs.uci.edu> Message-Id: <199311041347.AA24199(a)hydra.acs.uci.edu> To: na26436(a)anon.penet.fi Subject: Returned mail: Return receipt ----- Transcript of session follows ----- ----- Message header follows ----- Received: from orion.oac.uci.edu by hydra.acs.uci.edu with SMTP id AA24194 (5.65c/IDA-1.4.4 for <athomas(a)hydra.acs.uci.edu>); Thu, 4 Nov 1993 05:47:52 - 0800 Received: from relay2.UU.NET by orion.oac.uci.edu with SMTP id AA28377 (5.65c/IDA-1.4.4 for <athomas(a)orion.oac.uci.edu>); Thu, 4 Nov 1993 05:47:50 - 0800 Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04164; Thu, 4 Nov 93 08:45:13 -0500 Received: by toad.com id AA23509; Thu, 4 Nov 93 05:37:38 PST Received: by toad.com id AA23503; Thu, 4 Nov 93 05:35:10 PST Return-Path: <jik(a)security.ov.com> Received: from pad-thai.aktis.com ([192.231.148.11]) by toad.com id AA23499; Th u, 4 Nov 93 05:35:05 PST Errors-To: na26436(a)anon.penet.fi Received: from gza-client1.aktis.com by pad-thai.aktis.com (8.6.4/) with ESMTP id <IAA14324(a)pad-thai.aktis.com>; Thu, 4 Nov 1993 08:35:27 -0500 Received: from localhost by gza-client1.aktis.com (8.6.4/4.7) id IAA28688; Thu, 4 Nov 1993 08:35:26 -0500 Received: from relay2.UU.NET by pad-thai.aktis.com (8.6.4/) with SMTP id <WAA26264(a)pad-thai.aktis.com>; Wed, 3 Nov 1993 22:05:39 -0500 Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29104; Wed, 3 Nov 93 22:02:57 -0500 Received: by toad.com id AA18024; Wed, 3 Nov 93 18:57:31 PST Received: by toad.com id AA18012; Wed, 3 Nov 93 18:56:25 PST Received: from punisher.caltech.edu ([131.215.48.151]) by toad.com id AA18007; Wed, 3 Nov 93 18:56:20 PST Errors-To: na26436(a)anon.penet.fi Received: from alumni.cco.caltech.edu by punisher.caltech.edu (4.1/DEI:4.41) id AA29935; Wed, 3 Nov 93 18:56:14 PST Received: by alumni.cco.caltech.edu (4.1/DEI:4.41) id AA20137; Wed, 3 Nov 93 18:52:10 PST Date: Wed, 3 Nov 93 18:52:10 PST Message-Id: <9311040252.AA20137(a)alumni.cco.caltech.edu> To: XXXXXXXXXXXXXXX, cypherpunks(a)toad.com X-Mail-Duplicate-From: nobody(a)alumni.cco.caltech.edu Comments: This message is NOT from the person listed in the From line. It is from an automated software remailing service operating at that address. Please report problem mail to <hal(a)alumni.caltech.edu>. Subject: Re: ANON: mail concerns From: Eternal Optimist <na26436(a)anon.penet.fi> Return-Receipt-To: na26436(a)anon.penet.fi Reply-To: na26436(a)anon.penet.fi Errors-To: na26436(a)anon.penet.fi ------- End of Forwarded Message

3 2

ANON: random remailing...
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >if every single site knows the final address, so what? >how is this going to help them track down the original sender?? >anyone at the final destination who wants to track down the original sender >would need to hop-scotch backwards through the numerous sites and try to >track down the path the message took. this is of course, IF someone really Yes, this is true, but the key point in the anonymous remailers is they can be used for two-way communication. Presumably, both you and your friend intend to email each other. If mail proceeds randomly throughout the network, then the final destination must be available to every remailer. This may be fine if A only sends to B (announces to every remailer B's address), but when B responds to A, A's address is similarly announced to every remailer. Now it is simple to figure out A and B are communicating. If all you want is one-way communication (i.e. you just want to send and don't expect any replies), you may be better off faking mail with telnet, or using a newsgroup. Karl Barrus <klbarrus(a)owlnet.rice.edu> -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLNk0qoOA7OpLWtYzAQF17wP/eittrsJRkRuKSXH0V1bSiEEc1+ZAYGj9 4+aTctisX0QG2LholGDHqxti02SyEH+iQO8qjAkY5vyHNDVM6pH4tr2xzF2W9prx 1A91KNXHdiZPAvsUWgv32+B5IJYZqarRVmLjuI7PnydTiKX9/24bffl8TUtoidln syJ3O/cVoyA= =iz1j -----END PGP SIGNATURE-----

2 1