- cypherpunks-legacy - lists.cpunks.org

another remailer!
by nobody＠pmantis.berkeley.edu 08 Dec '92

08 Dec '92

I set up another remailer. All in all it took me about 30 min to compile perl and set up Hal's script. It's too easy! Just do the standard thing: mail to hh(a)pmantis.berkeley.edu with the line in the header Anon-To: or Request-Remailing-To: Have fun! e

1 0

Anonymous address problems
by ghsvax!hal＠uunet.UU.NET 08 Dec '92

08 Dec '92

We've had some discussion of anonymous addressing, which allows someone to post an address at which mail can be sent to them without people being able to find out exactly who they are. I showed how the current remailers could, somewhat clumsily, allow anonymous addresses. The problem is, with a single-remailer anonymous address that remailer sees whom each anonymous address corresponds to, so you have to trust it. Now that other encrypting remailers are up it's possible to have anonymous addresses which go through more than one remailer before going to the final destination. This, I thought, would provide a more secure address since a whole group of remailers would have to be "broken" in order for someone to find out where a given anonymous address leads. However, with the current implementation, there is a security weakness. Whomever owns the last remailer in the chain for your anonymous address can find out who you are. They do this simply by sending an anonymous message with known contents, like "test number 1598293". They then watch all messages going through their remailer, looking for one whose contents match what they sent. If they are the last remailer in the chain, when they see this message go through them, they can look at whom it is being sent to, and so they then know your true name. So, a multi-remailer anonymous address is really no more secure than a single-remailer one. Chaum, in his "mix" paper, avoided this problem by having the anonymous addresses include a random number which each remailer sees as it decrypts the incoming message. (There is always such a number, it turns out, for the RSA encryption to be secure.) He had the mix, as it passes the message through, encrypt the contents with a single-key algorithm (like DES) using this random number as the key. This way the message is transformed at each step and so if it later comes back through the same mix, it won't be recognizeable as the one it sent earlier. So the attack above fails. For this to work, the user has to save the random numbers that were used to construct his anonymous address, and decrypt the message using DES with these as keys before going on to read it or public-key decrypt it as usual. This would be quite a bit less convenient. Chaum goes on to say that these return addresses can only be used once. I was a little puzzled by the exact attack that he is trying to defend against in applying this rule. Chaum doesn't always make the attacks clear, leaving that as an exercise for the reader. I believe the problem is that, say, the last remailer in the chain could send 100 messages to a given anonymous address (all would have different contents). Then, after working its way through the remailer chain, it would see 100 messages going to the same final destination. It could guess that those 100 were the 100 it sent, especially if it repeats this test every few days with different numbers. Chaum's rule of allowing each anonymous address to be used only once makes them much less useful. These complications just go to show that real security doesn't come easy or cheap. There is still work to be done before we achieve the goal of crypto anonymity. Hal 74076.1041(a)compuserve.com

2 1

pgp2.1 released
by nobody＠alumni.cco.caltech.edu 08 Dec '92

08 Dec '92

PGP 2.1 is released. It's on soda.berkeley.edu, for your convenience, in directory pub/cypherpunks. The 2.1 release has the ability to sign a message as leave the message in plaintext. This should be used by all the pseudonyms in the group to prove continuity of authorship.

1 0

ocf remailer
by Eric Hollander 08 Dec '92

08 Dec '92

For various reasons, my remailer on the ocf is going down indefinitely. It was fun while it lasted, I laughed, I cried, but now it's over. e

1 0

Just in case you haven't heard (PGP 2.1 released)
by Derek Atkins 08 Dec '92

08 Dec '92

-----BEGIN PGP SIGNED MESSAGE----- PGP 2.1 Available - ----------------- Pretty Good Privacy (PGP) Version 2.1 is now available, from Europe. This new version of the world's most popular and politically controversial public key encryption program has numerous bug fixes over version 2.0, and several new features. For example, you can now display the MD5 hash of a public key, to facilitate verifying it over the telephone with the owner of that public key. Also, it is now possible to send via email an unencrypted signed message without putting the whole message in Radix-64 format, to make it possible to read without PGP. This is analogous to the PEM MIC-CLEAR signed message functionality. PGP 2.1 incorporates many patches from the user community to port it to more platforms. And it runs faster. Also, a lot of annoying bugs and ergonomic oversights have been fixed. PGP 2.0 fans will find many rough edges have been smoothed out. The filenames are pgp21.zip for the MSDOS executable release, and pgp21src.zip for the source code release. You must have PKUNZIP version 1.1 or later to unzip them, or they won't unzip. The primary initial FTP sites that have it are: Finland: nic.funet.fi (128.214.6.100) Directory: /pub/unix/security/crypt/ Italy: ghost.dsi.unimi.it (149.132.2.1) Directory: /pub/security/ As previously, this prohibited and politically popular program will probably propagate through the same channels as PGP 2.0. Of course, if you live in the USA, you really shouldn't be using it. If you have any questions about where else to get it, contact Hugh Miller, at hmiller(a)lucpul.it.luc.edu. Hugh can send you the latest evolving list of FTP sites, BBS phone numbers, and other sources. Philip Zimmermann Phil's Pretty Good Software -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyLbAuJ13g7/Z/cLAQFxoAP+OqIqZu2zfA7LycuBJmaF0cms6xyYYok+ ifFW5hIKYUDqvVwLQg5kSXRIUY9fbSXaox6bnww+2YCoEacbzMAAVgTiw8TU7QG0 JryTOHsUIihq9JNBOQ5ONfmHzH0w2gaQ5SGEcJK93typoyvNQMtdtVSeIfkl6ImJ vs/OHzY5LiU= =nV70 -----END PGP SIGNATURE-----

1 0

No Subject
by wendtj＠jplpost.Jpl.Nasa.Gov 07 Dec '92

07 Dec '92

ruthere

1 0

CHATTER Re: Broadcast/Filter vs. "Fetching"
by fnerd＠smds.com 07 Dec '92

07 Dec '92

(I put "CHATTER" in the subject line as a clue that this is general talk off the subject of directly implementing crypto stuff.) Yanek Martinson <yanek(a)novavax.nova.edu> sent an interesting message to me--I think he meant to post it--in response to my gripe: >> (I mean, while I'm at it, I hate the broadcast-and-filter model of netnews, >> CD ROMs, and cable TV. I want things available for me to go fetch.) > >But if you have the disk space and bandwidth to spare, it really does >make sense to receive everything and then decide what you want. Perhaps our company could make room for a couple days worth of the complete netnews. But, o That's hardly all the information there is. o I could never read it all, and I don't trust computer filters much. o I don't want to be a slave to the newsfeed/use-it-or-lose-it deal; I want to follow threads into the past, at my leisure. I want to let some discussions cook and then come back to them. >In your "fetch" scenario, what if I don't like (strongly) what Joe wrote. >So I can nuke Joe (or his archive) and no-one can "Fetch" the article. This is what I found interesting. You would really like the network (some network) to support distributed redundant archives, preferably with cross- checking. It would be even nicer if information could be stored, with storage cost charged to the owner and/or readers, and yet not have it knowable where the information was. Somehow a backwards mix setup. Put on your crypto thinking caps, kids. >On the other hand with the current set-up, it has already propagated >to hundreds of thousands of sites and it's impossible to stop. Yes. But, say, tens of untraceable sites would be okay. The flip side of 100K x redundancy is the little emily postnews handslap--"ARE YOU SURE?"-- and the rigamarole over creating new groups, and whether all the machines between you and the center of the universe get all the groups, etc. Plus the fact that most sites delete the stuff after a week or two, and all the effects on people's writing that has. >Also, if you want to filter stuff, then you should pay for the CPU >that does the filtering for you. My brain filters my mail! Boy do I pay for it! >Why would you expect someone else >to run your filter on their machine just so you would know if you >wanted to fetch their article. ?? I don't want machine filtering at all. Mostly I want references I can follow up easily. That's what fetching means. >Maybe I did not understand what you meant by "fetching". Hope it's clearer. >Could you describe your idea in more detail? >I absolutely agree that most of what comes in over my >newsfeed is junk, I just don't see a good way of >fixing this problem while retaining the robustness >and widespread communications capability. > >> -fnerd >> quote me...within *reason* of course > >(I guess 4 lines (including the sig) is well within reason) -fnerd quote me fnerd(a)smds.com (FutureNerd Steve Witham)

1 0

yet another remailer
by nobody＠ocf.Berkeley.EDU 07 Dec '92

07 Dec '92

I've set up another remailer, this one on my ocf account. It's also based on Hal's (very easy to use and useful) script and does not yet have encryption because pgp201 is not the most portable thing around. To use, just do the standard thing: send mail to hh(a)ocf.berkeley.edu with the line: Anon-To: or Request-Remailing-To: and it will do the rest. Have fun! e

1 0

No Subject
by nobody＠soda.berkeley.edu 06 Dec '92

06 Dec '92

Cypherpunks! Like several people (I guess), I am working on an implementation of digital cash. Because of the possible legal repurcussions, I'd prefer to remain anonymous at this time. Thanks to the efforts of the people on this list, this is now possible. My implementation is pretty far along. It uses PGP modules for the arithmetic, so the speed is good. It works on Unix and I should be able to get it working on MSDOS in a day or two. Sorry, I don't have the ability to work on a Mac version. Here are some of the features. The basic cash algorithm is the Chaum system which was posted here. Multiple denominations are supported, using different exponents for each denomination. The program is presented in the context of a package to be used for an email based game like Monopoly where the program would be used to allow cash transfers. One player is the "banker", and he uses a different execution module than the other players. The banker program keeps a database of used note numbers which is used to detect money reuse. The database is maintained using a freeware version of the "dbm" package, so it should be fast even for large note number databases. The mapping between exponents and values is as follows: exponent value 17 1 19 2 23 5 29 10 31 20 37 50 41 100 43 200 47 500 53 1000 59 2000 61 5000 67 10000 and so on, up to a value of 2e9. The exponents are ascending primes starting with 17. This was chosen because you want them to be smallish for fast note checking, but it was too slow to find primes p and q for the bank key such that (p-1)(q-1) was not divisible by any small primes. The program chooses random p and then tests p-1 to make sure it passes the divisibility test, and rejects it if not. Too many were being rejected when I started with an exponent of 3. Starting with 17 rejects about 1/2 the exponents, compared to something like 80% when I started with 3. The "value" fields are presumed to be cents, but could be whatever you like. The code I've written does not do anything other than the basic electronic cash algorithms. It does not do bank account maintenance. It doesn't do PGP encryption. It doesn't send mail. (It does have some functions to scan and check the files created by the program.) Cash generation is a 3 step process. First, the user creates what I call a "withdrawal request" packet. This is a set of triplets of the form (e, s, refx), where e is the exponent from the table above, s is a 16-byte "unique identifier" used solely to link these withdrawal requests with the returned messages from the bank, and refx is r^e * f(x). f(x) is MD5 of x, padded to the size of the bank's modulus n using the PGP routine which pads MD5 signatures. This padding helps make sure the arithmetic is more "mixing". x is the random input to MD5, which I've chosen as 64 bytes since that is the block size MD5 works on. (The output of MD5 is 16 bytes.) r is the blinding factor. This is now 128 bits long; longer r's take too long to calculate r^-1 in the third step, below. (It takes longer for PGP to calculate r^-1 than to do an RSA decryption, for r = n = 1024 bits!) Second, the bank program converts the withdrawal request packet into what I call a "withdrawal" packet, by just RSA-decrypting the third entry using the inverse exponent "d" for the value exponent "e". (These "d" values are calculated at keygen time and stored with the bank's key information in a private file.) I call the return triplet (e, s, rfxd), where e is the value exponent again, s is the same unique identifier, and rfxd is r * f(x)^d. (As I said above, the code I've written does not try to maintain account balances or do any other banking functions. It just does the cash algorithms. There is a routine to scan a withdrawal request and return the total value being requested for withdrawal. The idea was that this could be used as input to a banking program to decide whether to allow the withdrawal.) Third, the "player" (e.g. user) program transforms the withdrawal packet into a "money" packet, by un-blinding it. To do this, it has to recover the x and r which correspond with each triplet. This is done by the use of a dbm database of "pending withdrawal requests" which is written during step 1, above. The database entries are keyed by (e, s) and return the corresponding (x, r) which were generated during step 1. Using x and r, the user transforms (e, s, rfxd) into (e, x, fxd), the digital cash. e is the value exponent, x is the random 64-byte number, and fxd is f(x)^d, the signed version of the MD5'd and padded x. There are also player functions to scan and check a money file (comparing a calculated f(x) to fxd^e), merge money files, and extract some items from a money file into another money file (this last is what is to be used for payment). There are banker functions to check incoming money and compare against the used-note database, and to add incoming money to that database. (The database consists of the 16-byte f(x) values for each note.) I am pretty happy with the basic routines, but the user interface needs work. There are three kinds of files floating around (withdrawal requests, withdrawals, and money files) and I'm worried that this will be confusing to the user. If he accidentally deletes one at the wrong time he could lose money permanently. Or if he accidentally reuses one he could be accused of fraud. I'm not sure what the best model is for the user. The specific issues of creating withdrawal messages and extracting "bills" from a money file are areas where the user interface should be made nice. We want to make it easy for the user to specify exactly what denominations he wants to work with. One possibility is to simply have him input the amount (e.g. $10.55) and the program calculates that that's a 1000, a 50, and a 5, but this isn't really flexible enough. A nice system would be to give him a list of options and let him fill out a form on-screen, but that's hard to do portably. Another idea I've had is that there should be a special money file called the user's "wallet" which is the default place where incoming money from the bank should go. This might help organize things. He still needs to be able to create other money files for paying other people, and remembering to delete them after he sends them. Any suggestions or thoughts on these interface issues, or comments about how this program could or should be integrated into a larger system, would be appreciated. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAisiUPkAAAED/i1Pf1DaubveDsgjh360rNJ7kWkhssobaVmmWa70l4lOTwy/ sGwhJaA+JdScO9g3B66DIAaU0GiNrTS4YEl/b5ohNDZFdqKlxZ7NW9A5JYjUlhGE a53cRwqUXs42kbPbMh/uKxXBgbUnKrKZnWAh29irDWb+G8OEPQrkCJ6S8691AAUR tAl4UGhhZWRydXM= =HVRq -----END PGP PUBLIC KEY BLOCK-----

1 0

this is a test
by nobody＠soda.berkeley.edu 06 Dec '92

06 Dec '92

igonore this message... e

1 0