1 September 2014
Hal Finney Messages on Cypherpunks 1992
Excerpted from
http://cryptome.org/cpunks/cpunks-1992.zip
These messages alone do not convey the lively discussion of early public
cryptography of which they are a part over five years, and continuing today,
among thousands of participants. Finney continued to post to cypherpunks
at least through 1997.
Cypherpunks mail list archive 1992-98:
http://cryptome.org/cpunks/cpunks-92-98.zip
(81MB)
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 10 Oct 92 11:04:58 PDT
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Mr. Squirrel?
Hi, I've just joined this list.
Interesting confusion about Mr. Squirrel. That's one of the problems
with anonymity. How do you know you're talking to the right person?
What you should do is to use a public key. The pseudonym is not
really the name "Secret Squirrel"; anybody can use that. The pseudonym
is the public key. Any message signed by that particular key is from
that particular squirrel. Any message you encrypt in Squirrel's public
key is readable only by him. If Squirrel changes his key, he should
sign the message so you know it's really _that_ squirrel who's changing
his key (and not some other squirrel telling people to use a new key).
A pseudonym is a public key.
Hal
P.S. Here's my key, signed by PRZ:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.01
mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d
sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8
JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR
tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu
M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs
0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0
xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2
=fF6Z
-----END PGP PUBLIC KEY BLOCK-----
From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 13 Oct 92 08:55:18 PDT
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Re: Mr. Squirrel
||ugh Daniel raises some questions about using public keys to
verify pseudonyms:
> Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone
> can use any public key they want also.
But, once person A creates public key X, nobody else can sign messages
using X. So if all messages from A are signed under X, we can know
that they are all from the same person, even if they are sent anonymously
or under a pseudonym.
> So, in a many-to-one scope (as
> in a maillist) where the sender can not use the one-on-one signed
> signiture method how do we have proff of who the sender really is?
You can use signatures even in a many-to-one scope. Messages from
a particular person could be signed and the signature appended to
the message. Then anyone who has the public key can check to see
who the message came from. The process is a little unwieldy now
in PGP because you have to separate the signature and message into
separate files and run PGP on the signature file. This should be
streamlined.
> [Good points about keeping track of key-pseudonym pairs]
> But all this needs to be done automaticly by the mailers and
> interfaces, else the system will be mis-used and folks will tire of
> the extra work that gets them little advantage.
Absolutely. The most crying need now, IMO, is to better integrate the
cryptographic tools into mail readers and senders, so that it's not
such a pain to use these things. People should be able to give a single
command or press a button to decrypt an incoming message or encrypt an
outgoing one. Only then will these features be used by average people.
There was a message posted on alt.security.pgp describing how to
use PGP with the Emacs mail reading program. I'd like to see more
messages telling how to use it with other systems.
Hal
74076.1041@compuserve.com
From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 13 Oct 92 13:37:43 PDT
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: New remailer...
I have been experimenting with Eric's remailing software on
the Sun 4 I use at work. This is what I've found.
First, Eric's descriptions of how all the different software
components work together have been very helpful. The software
has gone through three revisions as Eric added new features, so
I implemented them in that order - first the basic remailer,
then adding the "##" and "::" support for header management.
(I had to get perl and slocal before I could get started.
Luckily my system already uses sendmail.)
Basically, I was able to put the parts together the way Eric
described and have it work. I was able to send messages and
have them remailed. I even did some tests bouncing mail between
my remailer and Eric's.
Then I tried adding a new feature to the remailer - automatic
message decryption using PGP. It's not really very secure since
anyone with root privileges at my site can see my pass phrase,
but my site is pretty isolated (a 2400 baud modem is the only link
to the outside world). For this I had to add one line to Eric's
model .maildelivery file to invoke my PGP filter, and had to write
about a five line shell script to run PGP in a useful way. I
am still tuning this a little bit but I can send the exact scripts
out when people are ready for them.
One nice thing about this is that, with my remailer plus Eric's,
and with the decryption option, you can now send anonymous messages
for which no one person can tell that you did it. What you would
do is to send the message first through Eric's remailer, so I
don't know where it came from, then through my remailer, but with
the message encrypted so that Eric can't tell where it's going after
it leaves me. If more people will run remailers then we'll have
much more security.
I will now tell you how to use it, in case you want to experiment.
But remember that all messages are going across an intermittently-
polled 2400 baud modem, so don't expect fast turnaround and please
don't send a large volume of messages. Also, please don't pass
information about this remailer beyond this list, for now.
The remailer is at hal@ghs.com. The basic remailing operation is
as Eric has described: either put "Request-Remailing-To: <dest>" in
the header of the message, or put, as the first two lines of the
body of your message:
::
Request-Remailing-To: <dest>
And follow these two lines with a blank line, then the message to
be forwarded.
Decryption is just a little complicated. The thing to remember is
that you want to do more than just have me decrypt the message. You
want me to then remail the message after decryption. This means
that you should prepare a message with remailing instructions as
above, then encrypt the whole thing, including the "::" and
"Request-Remailing-To:" lines. Encrypt using PGP with the public
key I show below, and use the -a flag for Ascii output.
This will create a PGP output file, typically with the extension .asc.
The first line will be:
-----BEGIN PGP MESSAGE-----
Now, you can send this message to me, but you have to do one more
thing. You have to mark it as an encrypted message, by putting the
line "Encrypted: PGP" in the header. If you can't put stuff into
the headers of messages, then use Eric's "::" feature and add the
following two lines, then a blank line, before "-----BEGIN PGP MESSAGE-----":
::
Encrypted: PGP
Don't forget the blank line after these two.
Now, this message can be sent to my remailer. It will be decrypted
and then remailed to whomever you requested.
I know this sounds complicated, so let me break it down into steps:
1. Create the message.
2. Add "::" and "Request-Remailing-To: <dest>" and a blank line to the
top.
3. Encrypt the whole file using PGP and the public key below.
4. Add "::" and "Encrypted: PGP" and a blank line to the top of
the encrypted file.
5. Send it to hal@ghs.com.
That's not so bad, is it?
Now, if you're really adventurous, here's how to do the double-remailing
process I described above, the one which keeps any one remailer from
knowing who's talking to whom.
1. Create the message.
2. Add "::" and "Request-Remailing-To: <dest>" and a blank line to the
top.
3. Encrypt the whole file using PGP and the public key below.
4. Add "::" and "Request-Remailing-To: hal@ghs.com", then a blank line,
then "##" then "Encrypted: PGP", then a blank line, to the top of
the encrypted file.
5. Send it to hughes@soda.berkeley.edu
The only complicated step is step 4, where you put in the remailing
request to go from Eric's system to mine, and use the "##" line so
that the outgoing message has "Encrypted: PGP" in the header.
If you want real security, encrypt the message using your friend's
public key after step 1 and send that. Then nobody will even know
what you're saying, let alone who you're talking to.
As promised, here's the public key for my remailer:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.01
mQBNAirY9EoAAAEB/iuDBqpeJ8gsNQwJNRYWBxH7uP95ApQ92CDhCmuSEJ0Tta0l
oCrC+8Br+D7Nfotb7hJlI0A1CYGAlmCsRO8VEmkABRO0H1JlbWFpbGluZyBTZXJ2
aWNlIDxoYWxAZ2hzLmNvbT6JAJUCBRAq2ISQqBMDr1ghTDcBARYlBADCjkCkIDvA
7QFtpYUlYjz/2U+/oDuMZBDlmAw8BCg3sdJG7hnxPE4yVgKoH/ozsb23pbFTPB8H
WNEjqTqixNybOKSKH9T8iCaRDA8+bS6xPN4YlWKD/Wg2EiyuOjD3v/vWgiZXzMR5
hpe0CYVJ6bM++hptXu+JxqDReJIot5FFbQ==
=p8FS
-----END PGP PUBLIC KEY BLOCK-----
Hal
74076.1041@compuserve.com
P.S. Coming soon: anonymous return addresses!
From: Hal <74076.1041@CompuServe.COM>
Date: Wed, 14 Oct 92 08:27:57 PDT
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Game items...
I'm trying to think in terms of things which were illegal but
which have good moral connotations today.
Crosses and other Christian symbols were supposedly outlawed
during the Roman empire (leading to the adoption of the fish
as a symbol of Christianity). Posing as early Christians smuggling
crosses ought to make the right-wingers happy!
Abolitionists had to smuggle runaway slaves out of the South
on the so-called "underground railroad". Perhaps cryptography
would have helped them coordinate their efforts.
Much of the support in the U.S. for freedom and privacy comes from
our revolutionary heritage. I'm embarrassed at how little I can
recall of what things were restricted in those pre-revolutionary
days. I recall the Stamp Act and a few other laws, and I imagine
that seditious materials were restricted. Perhaps the game players
could be early revolutionaries trading items forbidden under British
rule.
Hal Finney - 74076.1041@Compuserve.Com
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d
sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8
JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR
tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu
M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs
0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0
xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2
=fF6Z
-----END PGP PUBLIC KEY BLOCK-----
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 24 Oct 92 09:02:41 PDT
To: <cypherpunks@toad.com>
Subject: Multiple messages + entropy
The Internet PEM (Privacy Enhanced Mail) standard uses the
concept which Dean Tribble mentioned of multiple encryption
(using each recipient's public key) of a single session key
which encrypts the message. PGP's data structures do not
currently provide for this but could be extended pretty easily
to allow it.
On the entropy measure - I thought entropy was how many bits
of information you get per character. Encrypted binary text
would be pretty close to 8 bits per character. The RFC1113
Ascii encoding used by PGP reduces this to 6 bits per character
(e.g. a character set with 64 printable characters) neglecting
line separators and message beginnings and endings. So there
should be a little less than 6 bits per character for encrypted,
Ascii-encoded messages.
Hal
74076.1041@compuserve.com
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 24 Oct 92 21:47:19 PDT
To: <CYPHERPUNKS@TOAD.COM>
Subject: Re: remove from mailing list
What we _ought_ to do is to remind people that they should send
their unsubscribe notices to cyherpunks-request@toad.com, _not_
to the list address. That way we wouldn't all have to be bothered
by reading these messages, and the list volume would be that much
lower!
From: Hal <74076.1041@CompuServe.COM>
Date: Mon, 26 Oct 92 09:23:21 PPE
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Registering Keys...
This proposal to register keys was also mentioned in the July, 1992
Communications of the ACM, in an article by Ron Rivest, one of the
creators of the RSA algorithm. He was mostly criticizing the proposed
government Digital Signature Standard, stating that he thought that
the NSA was purposely trying to get "weak" cryptography installed as
the standard. Then he goes on to say,
"Are there technical alternatives that would satisfy all parties?
Perhaps. It is certainly the case that the formulation of the problem
to be solved has never been made explicit for the cryptographic
community to work on. I suspect that a solution based on 'escrowed
secret keys' might be workable, wherein each user is legally required
to depost his or her secret key with a trusted third party, such as
the user's bank. Cryptographic hardware and software would only
operate with public keys that were certified to having their corres-
ponding secret keys appropriately escrowed. A federal agency could
then obtain the secret key, or its use, with an appropriate warrant.
Once their secret keys were escrowed, multinational corporations could
even operate across borders with a high degree of authentication and
privacy (except perhaps from court-ordered wiretaps). Cryptographic
hardware and software manufactured in the U.S. would not operate
abroad without public keys suitably certified as having their secret
counterparts escrowed in the U.S. In an extension of this approach,
users can escrow their secret keys with several trusted third parties
in a 'secret-sharing' manner, so that no single third party can com-
promise the user's key. While this approach may have its own difficulties,
it does illustrate that weak cryptography is not the only technical
approach available. There may be much better techniques for achieving
a compromise between a number of conflicting national concerns."
At the time that I read this, I thought it was largely a rhetorical
device, making the point that if the government wants to infringe on
people's privacy, it should come out in the open and do so, rather
than skulking about. (Like saying, "if the government _really_ wants
to stop sexual immorality it would have to put a TV camera in every
bedroom".) And of course (I thought) this kind of proposal would never
be taken seriously. I'm shocked that Denning is now advocating it openly.
This proposal makes it illegal for people to communicate so secretly
that the government can't find out what they are saying. It could
apply to postal mail as well as email - it would be illegal to send
a message via post which the government couldn't interpret. If this
is really the government's purpose, then it should also require that all
private conversations be recorded, and the resulting tapes be "escrowed"
similarly in case the government needed to find out what was said,
for which it would have to get a court order.
As Tim suggested, this is probably a "trial balloon" being floated to
see what the reaction is. Let's see that it gets shot down.
Hal
74076.1041@compuserve.com
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 31 Oct 92 09:42:14 PPE
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Why I Don't Use PGP...
The best way to integrate PGP into other software is a tough
question. There are so many different ways in which people read
and send mail.
A lot of people receive their mail on some other machine, often
a multi-user machine. So, the first question is, should the mail
be crypted there, or should it be crypted on your personal machine.
The second choice is preferable from the security point of view,
but that means that you need to download at least your PGP mail
in order to decrypt it, and it means you have to compose your
mail on your home machine before encrypting, uploading, and sending.
(Phil Zimmermann had an idea for multi-user systems in which the
RSA portion of the decryption, which involves your secret key, would
be done on your personal machine, then the decrypted session key
would be uploaded to the multi-user machine and the IDEA decryption
done on the message itself. This way you only have to upload and
download a couple hundred bytes regardless of the length of the
message. This would require PGP to be integrated into a terminal
program.)
If you _do_ download your mail before reading it, you could get in
the habit of downloading _all_ of your mail into a big file, then
running a word processor or some more specialized program to
read the messages, one at a time, and compose replies. Then, when
you were done, you could upload and send the replies.
If you worked in this mode, which probably few people do, you could
integrate PGP by running it on the downloaded mail file before running
your WP to read it. I have a Perl script which runs PGP on a file,
finding the PGP messages in it, decrypting them, and replacing them
_in_the_file_ with their decrypted versions. (Normally PGP outputs
its decrypted contents to another file, which is a little inconvenient.)
This can make PGP pretty transparent for decryption if you actually
read your mail in this way.
Another possibility is to use a WP or mail reading program which has
a "filter" mode, one which lets you pass incoming or outgoing mail
through some program, and replace the mail with the results of that
program. I don't know which programs can do this. A lot of Unix
programs can, like VI and EMACS, but I don't know about PC's or other
home machines. PGP has a filter mode which is designed to be used with
WP's which can do this. There have been a couple of messages on
alt.security.pgp which have advice on using PGP with various Unix mail
reading programs. Mark Riordan's soon-to-be-released RIPEM program
(an alternative, incompatible, RSA public-key program) has some ideas
in its manual on how to use its filter mode with Unix mail, which mostly
apply to PGP as well.
One other point: regarding a Mac port: There have been at least a couple
of messages on alt.security.pgp over the past couple of months from
people who have successfully compiled the PGP sources under Think C
on the Mac. However, as a Unix/PC program, it ends up using a character
window for I/O, which you type into just like you would on a PC.
This is unacceptable for Macs, so nobody has released one of these.
Still, compared to what Tim has to do, it would be an improvement. I
think people should release their executables which work like this as
an interim crutch version until the real Mac version is available.
Hal
74076.1041@compuserve.com
From: Hal <74076.1041@CompuServe.COM>
Date: Thu, 12 Nov 92 13:18:01 PST
To: cypherpunks@toad.com
Subject: No Subject
Bcc: Blind Recipients List:;
Subject: Why hardware random numbers?
Message-ID: <921112211037_74076.1041_DHJ46-1@CompuServe.COM>
I don't understand the desire for hardware-based random number generators.
It seems to me that a decent software RNG would be adequate for
the main uses that I have heard of for RNG's (mostly session key
generation).
Seed the RNG initially with a nice random set of characters typed in
by the user, plus timing information based on the rate of timing of
those characters. Also use the local system clock, and possibly a
hash of some sectors of the disk or some files on /tmp. Create a pool
of random numbers in this way.
As you use them, refill the pool, making the refilled bytes a function
of the current system clock, and whatever message you are encrypting
(or some other appropriate global state).
Use a nice strong RNG based on DES, MD5, IDEA, or some other cypher or
hash function.
I don't think anyone could break the resulting random stream without
a physical attack on your computer. Why pay $50 to $200 for a hardware
device when you can get the same effect in software that already exist?
Both PGP and RIPEM, I think, use the above techniques for their random
numbers.
Hal
74076.1041@compuserve.com
From: Hal <74076.1041@CompuServe.COM>
Date: Sun, 15 Nov 92 17:37:40 PST
To: CYPHERPUNKS <CYPHERPUNKS@TOAD.COM>
Subject: Why remailers...
Tim mentioned that not many people on the list have expressed
interest in the remailers, and it occurs to me that maybe people
don't all share the vision of why this crypto technology is important.
I'm trying to recall how I learned about the possibilities of this
technology. I recall reading "True Names" a few years ago. Vinge had
his netters exchanging mail anonymously. The hero downloaded a big
batch of messages from a BBS and tried decrypting all of them to see
which were for him. Okay, I thought, that would be a way of disguising
which messages you were _receiving_. Then Vinge said something like
"and using more elaborate techniques, the sender of a message could
be hidden as well." Hold on, I thought. That will never work. If
they tap your line, they're going to know exactly what messages you're
sending. Too bad. Vinge had a clever idea going, but it's flawed.
I only learned about Chaum's crypto stuff last year. Somebody on the
Extropians list mentioned PGP, and I'd always had a casual interest
in crypto, so I downloaded it and played with it some. I thought it
was great and really got into it in a big way.
This got me interested in crypto in general, so I started doing some
library research. When I found Chaum's stuff, it just blew me away.
The first article I found, I think, was his CACM paper which is an
overview of many of the things that are possible. I started trying to
track down other papers by Chaum. Here were all the technologies
needed to make Vinge's world work, technologies which Vinge apparently
knew about long before I did.
It seemed so obvious to me. Here we are faced with the problems of
loss of privacy, creeping computerization, massive databases, more
centralization - and Chaum offers a completely different direction to
go in, one which puts power into the hands of individuals rather than
governments and corporations. The computer can be used as a tool to
liberate and protect people, rather than to control them. Unlike the
world of today, where people are more or less at the mercy of credit
agencies, large corporations, and governments, Chaum's approach balances
power between individuals and organizations. Both kinds of groups are
protected against fraud and mistreatment by the other.
Naturally, in today's society, with power allocated so disproportionately,
such ideas are a threat to large organizations. Balancing power would
mean a net loss of power for them. So no institution is going to pick
up and champion Chaum's ideas. It's going to have to be a grass-roots
activity, one in which individuals first learn of how much power they
can have, and then demand it.
Where do the remailers fit in? They represent the "ground floor" of this
house of ideas - the ability to exchange messages privately, without
revealing our true identities. In this way we can engage in transactions,
show credentials, and make deals, without government or corporate databases
tracking our every move as they can today. Only by securing the ability to
communicate privately and anonymously can we take the next steps towards
a world in which we each have true ownership and control over information
about our lives.
Chaum's ACM paper is titled, provocatively, "Security Without Identification -
Transaction Systems to Make Big Brother Obsolete." The work we are doing
here, broadly speaking, is dedicated to this goal of making Big Brother
obsolete. It's important work. If things work out well, we may be able
to look back and see that it was the most important work we have ever done.
Hal Finney
74076.1041@compuserve.com
From: Hal <74076.1041@CompuServe.COM>
Date: Sun, 15 Nov 92 23:37:38 PST
To: Cypherpunks <cypherpunks@toad.com>
Subject: Chaum's papers
A couple of people have asked for references to Chaum's papers.
The August, 1992 issue of Scientific American was mentioned here, I think.
The ACM paper I referred to is "Security Without Identification:
Transaction Systems to Make Big Brother Obsolete", October 1985.
The "DC-Net" is described in "The Dining Cryptographers Problem:
Unconditional Sender and Recipient Untraceability", Cryptology, 1988,
volume 1, p65-75.
The "Mix-net", which is similar to the remailers we are experimenting
with, is described in "Untraceable Electronic Mail, Return Addresses,
and Digital Pseudonyms", CACM, February, 1981.
Chaum also frequently presents papers at the Crypto conferences, so
if you can get access to the proceedings of these at the library you
will usually find one or two papers by him in each volume. However,
in recent years he has published on other topics which don't seem as
relevant to the freedom/privacy issues we are concerned with.
Hal
74076.1041@compuserve.com
From: Hal <74076.1041@CompuServe.COM>
Date: Wed, 25 Nov 92 09:17:58 PST
To: cypherpunks@toad.com
Subject: Remailers...
I think the remailing idea expressed via Tim (from David?) had
some nice features. It would be very easy to do replies to someone
whom you didn't know but from whom you'd received some anonymous mail.
As I understand it, if I send mail anonymously to David, he won't
(of course) know who sent it. If he replies, the mail will bounce
back to the forwarder. And the forwarder has remembered my forwarding
request so that it can send the reply back to me. After that it
deletes the remembered forwarding request for security.
I wouldn't object to this that much on security grounds; as David
pointed out, even a full implementation of Chaum's "mix" remailer
would fall to infiltration. Instead, I think there are some issues
involving usability.
For one thing, it sounds like this system is use-once as far as the
anonymous return address. If David replied to me, then thought of
something he wanted to add, his second message wouldn't get through to
me.
Another problem is, what if two people send anonymous mail to David
via the same forwarder. Then, when he replies, how does the forwarder
know which of the two to forward the reply to?
It's also asymmetric, in that it will only work if one of the two
communicants knows the true address of the other. A lot of the
interesting features of Tim's "crypto anarchy" only arise if
people can communicate without either one knowing the other's true
address.
Let me mention a couple of other ideas which I've heard of for anonymous
return addresses. One idea was posted several months ago on the
Extropians list by Eric Messick. (Is he on this list?) It used
a "pseudonym-based post office box". You would send a message to
a remailing server saying, "Please save mail addressed to pseudonym
XYZ123. I will pick it up later. Here is the public key I will
use to authorize the pick-up, and here is some digital cash to
pay for your trouble. Thank you." Then you send mail anonymously
giving XYZ123@remailer.com as your return address. This mail
stacks up at the remailer which saves it for you. At some later
date you send a signed message to the remailer saying, "OK, send XYZ123's
mail to me@me.com."
Eric Hughes had an idea which was somewhat like this but without
the delay aspect. You would just set up an account with a remailer
whereby all mail to XYZ123 would be forwarded to yourself. Then
XYZ123@remailer.com would be your return address. This could include
David's idea if you asked the server to delete your pseudonym after
using it once.
All of these anonymous return address proposals can be enhanced by
using a cascade or chain of remailers for your A.R.A.
Chaum's "mix" remailer would save up a batch of cryptographically
protected messages, decrypt them, rearrange their order randomly, then
send them out. This way if the remailer itself is secure but the
network connections to it are being monitored, the correspondance
between incoming and outgoing messages is lost. The other ARA
suggestions could also benefit from this enhancement.
Chaum's idea for an anonymous return address was a somewhat more
complicated form of the ARA I've implemented for my remailer. My
ARA is simply a forwarding instruction, encrypted with the public
key of the remailer. The advantage of this system is that you don't
have to "register" with the remailer(s) in advance. It's less
convenient than the other proposals, though, and there is the danger
that the public key(s) of the remailer(s) involved would be revealed
at some time in the future, which would then reveal that that old ARA
really was you.
Hal
74076.1041@compuserve.com
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Wed, 25 Nov 92 13:04:57 PST
To: cypherpunks@toad.com
Subject: Electronic Banking
Some time back Tim May suggested that we should do some experiments
with electronic cash. He offered to do some Xeroxing if people would
"pay" him.
There are lots of proposals for electronic cash in the literature,
mostly very complex. I think one of Chaum's simpler proposals would be
adequate for email "banking". This proposal, from the beginning of
his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like
this:
1. Alice chooses a random x and r, and supplies the bank with
B=r^3*f(x) mod n, where f is a one-way function (like MD5), and n is
the modulus for the bank's public key.
2. The bank takes the third root of B (e.g. via an RSA decryption) and
sends it back to Alice: D = r * f(x)^(1/3), and withdraws one dollar from
her account.
3. Alice extracts C = f(x)^(1/3) by dividing D by r. (Note that
division can be done mod n without knowing the factors of n, but it's
rather complicated.)
4. To pay Bob one dollar, Alice gives him (x, C).
5. Bob can verify that C = f(x)^(1/3), but he still has to send (x, C)
to the bank in order to make sure that x hasn't been used before.
Otherwise Alice could spend (x, C) twice. The bank increases Bob's
account by one dollar.
This scheme is pretty simple and provides untraceability - the bank
saw B and D but not C, so although it can verify that (x, C) is legit,
it can't correlate that with Alice's withdrawal.
The main disadvantage of this approach is that Bob has to send (x, C)
to the bank right away (or at least before sending Alice anything in
return for her cash) to verify that the cash hasn't been used before.
But in email, where turnarounds of a day or more aren't unusual, this
should be tolerable.
Alice and Bob could be pseudonyms, using anonymous addresses to
communicate with each other and with the bank.
Different denominations of cash could correspond to different
exponents than "3" in the example above. (That is, $1 would use
C=f(x)^(1/3), $2 would use C=f(x)^(1/5), $4 would use C=f(x)^(1/7),
and so on.)
Technically, this would be quite easy to implement, using the code in
PGP for the arithmetic, and MD5 for the one-way function. We'd need
to define a few message formats. The RFC1113 ascii encoding from PGP
could be used as well.
The "social" problems are more challenging, it seems to me. What is
the backing for this electronic money? Why do people care what their
bank balances are? Is this stuff really worth anything?
One possibility is to base digital cash on real money. People would
open a pseudonymous account via email, then postal-mail dollars to the
bank, enclosing their account number so the bank would know whom to
credit with the deposit. Later, if someone wanted to withdraw "real
money" from their account they would have to give a real postal
address where it could be mailed. Now the electronic money is worth
real dollars. Even if people didn't deposit or withdraw very often,
it still has value because of the backing.
Unfortunately, this approach would currently be illegal (at least,
unless you actually were a real bank!). If there were some way the
bank itself could be anonymous, it might survive, but I don't see how
to mail it money while keeping the anonymity. Still, we could
consider experimenting with this on a small scale with accounts of no
more than a few dollars. As long as it was clearly an experiment I
doubt that any prosecutions would result even if it attracted
government attention, because the expense involved in court costs
would be so disproportionate to the few dollars involved in this
technically illegal act.
Another approach would be not to try backing the digital cash at all,
or rather backing it implicitly by the determination of various people
to accept it and perform services or supply goods in return for it.
Tim's offer to Xerox papers in return for digital cash would be one
example. Perhaps others could provide some other services. It would
be great if some shareware author would accept digital cash as a
symbol of support for crypto anonymity.
One problem that I see with this approach is how you determine the
size of the money supply. Or, in other words, how does new digital
cash get started circulating? How do people get new accounts, and how
much money is in them?
If these problems can be solved, a big advantage of this approach is
that the banker can be anonymous. He would be known only by his
anonymous address and his public key(s). This would provide some
safety in the event that even a small-scale experiment like this
was targetted for a crackdown.
Another issue is the prospect of multiple "banks", each issuing their
own (incompatible) cash. How would they compete? Perhaps in terms of
rapid turnaround? Some might choose to be anonymous, others would go
public. The latter would have the advantage that people might trust
them more, but OTOH there is more chance of your bank account
disappearing after a crackdown for a public bank than an anonymous
one.
Lots to think about here!
Hal
74076.1041@compuserve.com
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Wed, 25 Nov 92 16:07:41 PST
To: cypherpunks@toad.com
Subject: Re: An easy-to-reply anonymous mail scheme
The problem with the idea of posting anonymous mail to a newsgroup is
sheer volume. Remember, we aim at a system where a large fraction of
mail is potentially being done this way. Imagine if almost all email
was done today by posting to newsgroups! There is probably thousands
of times as much email traffic as news traffic now. It would totally
swamp the system. You'd literally have to send every email message
sent by any user in the world to _every_ user in the world, in effect.
As Yanek says:
> You are guaranteed anonymity because no-one can find out who decrypted
> the alt.w.a.s.t.e message, since everyone received it.
This really won't scale to large numbers of users. Yanek also writes:
> > Here is an example of how to use the cryptographic remailer at
> > <hal@alumni.caltech.edu> to implement an anonymous return address.
>
> > But the again do you trust hal@alumni.caltech.edu...
>
> With conventional remailer schemes such as this one, you are announcing
> your True Name (or at least your True Internet Mailbox) to someone you
> must trust. With my scheme (posted earlier today) you don't need to trust
> anybody except yourself (to not make a dumb mistake like including a
> signature).
This is why you would want to use a chain of remailers as your return
address, what Chaum calls a "cascade". No single remailer sees the
correspondance between your anonymous address and your real address.
Only by breaking all of them can the bad guys find out who you are.
Ideally, remailers would operate in a variety of countries with
different laws, making it difficult to crack them all.
Remailers could be designed to periodically flush themselves, deleting
old keys and/or pseudonym maps. This way anonymous addresses would
have a limited lifetime if desired, and the attackers would have only
a finite time window to break all the remailers involved. (Different
keys/pseudonyms could have different lifetimes as needed.)
We could also imagine that there are lots of remailers - not just
dozens, or hundreds, but millions of them. Maybe almost everyone runs
a "cheap" remailer on the side, collecting a few cents in digital cash
for each message they pass, enough to pay for their own messages.
Putting all this together, you could have an anonymous address which
passes through, say, 10 remailers which might be any of the millions
of remailers in the world. It could have a limited lifetime of only a
few hours for some ultra-sensitive applications, with the remailers
involved flushing their databases after that time. To break this, the
enemy would have to sequentially break into machines all over the
world, one after another, defeat any physical barriers (locks, men
with guns), overcome tamper-resistance in the computers, break the
encrypted files, and find out what the next step is in the address
cascade, all in a couple of hours. This doesn't seem possible.
Hal
74076.1041@compuserve.com
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Wed, 25 Nov 92 16:25:25 PST
To: cypherpunks@toad.com
Subject: Unlabelled PGP messages
Peter Shipley points out that PGP messages are labelled with an
identifier of the person they are sent to. This hurts the anonymity
of the messages somewhat.
What PGP actually puts in the cleartext message header is the "Key ID"
of the recipient. This is the low-order 64 bits of the RSA modulus
"n" of his key. (PGP displays only the low-order 24 bits when it
shows key ID's, but it keeps 64 bits internally.)
I understand that there was some discussion during the development of
PGP 2.0 of having a mode where this wouldn't be done. One possibility
would be to output a key ID of all zeros for a message which wanted to
hide who it was for. Then, as Peter suggests, it would either be
trial-decrypted by all of the secret keys you have, or, more simply,
it would just try your "default" secret key. Most people only have
one secret key so both methods would be the same in most cases. Doing
it the second way would be a pretty easy patch to PGP.
I'm not so sure now that this feature is that helpful. First, you
don't have to put your real name in the "user name" field. You could
use a pseudonym. So you really don't have to give much information
away about yourself the way it is now.
Also, if someone is sending a message to you using encrypting
remailers, they would encrypt it using your key, add remailing
instructions for the last remailer in the chain, encrypt that using
that remailer's keys, add remailing instructions for the next-to-last
remailer, encrypt it again, and so on. (This would be done
automatically by some future software - you wouldn't want to do this
by hand!) The result is that the mail you send does not expose the
key ID of your recipient. That information is only revealed when it
comes out of the last remailer in the chain. And by that time, it's
no secret, since that last remailer is using the true email address of
the recipient anyway. So it's not giving anything away.
For the other kind of anonymous messaging, where you just post to a
newsgroup or use some other kind of "broadcast" system, the key ID is
revealed and for this case it might be better to hide it. But, the
key ID can be useful in this application by letting you know which
messages you should decrypt. No one has to know that a particular key
ID is "you". You can still download 1000 messages and only read yours
without anyone knowing which ones you read. But with key ID hidden
you would have to decrypt them all to see which are yours. Do you
want to decrypt all 1000? This will take minutes, hours, or days,
depending on your key size and computer speed. (Most of the decrypt
time is spent doing the RSA step, at least for most messages, and you
can't tell if it's for you without doing that step.)
This still might be a good idea, but I'm not sure...
Hal Finney
74076.1041@compuserve.com
From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 28 Nov 92 10:23:07 PST
To: cypherpunks@toad.com
Subject: Misc. Items
A few random points related to messages from the last few days.
(First, a "meta" point - whenever I post to this list, I get from
3 to about 10 messages over 2 or 3 days reporting on delivery errors.
It would be nicer if these went to someone else. Some of the messages
include as many as 20 or 30 names of list subscribers who were apparently
included in the same "outgoing batch" as the bounced mail.)
On PGP key verification: I understand that Branko hopes to get version
2.1 of PGP out in a week or so. One of the new features will be a
mode to display a MD5 hash of each PGP key to facilitate read-aloud
over the telephone. This should make it easier to phone-verify PGP
keys, so we can have more _good_ sigs.
On pseudonyms and reputations: Several people have suggested that it
would be easy to conjure up dozens of fake personalities who would
then vouch for each other, giving the illusion of a well-founded and
trusted pseudonym. This would be ideal for con men and cops.
This can be defeated by the use of the is-a-person credential, which
Chaum describes in a couple of his papers, including CACM Oct 1985.
This is a signed document given by an organization which makes you
come in and give your thumbprint. The document is "re-blinded" a la
Chaums' proposals for electronic cash, so that there can be no linkage
between your is-a-person document and your actual thumbprint. However,
the thumbprint makes it so you can't get more than one is-a-person
document.
Now, when you go to apply for credit, and you say, here are signatures
from dozens of people that I've done business with in the past, and
I've paid them all off on time, the first thing the creditor is going
to ask is, who are all these people? Are they legit? Can you at
least show me is-a-person creds on them? You won't be able to. You
only have one is-a-person credential, and you can't make more.
Again, these credentials do _not_ hurt crypto anonymity. There is no
linkage between your credential and anything else about you.
On electronic banking: The interesting thing about electronic banking
is digital cash. The key feature of digital cash is anonymity of
payments. There is nothing subversive about this. Ordinary cash
has (nearly) this property. Are you being subversive when you buy
a newspaper without paying by check or credit card? Of course not.
The point is, we want to use digital payments so that we can transact
business over the net. But the more things get computerized, the more
possible forms of monitoring there are, by businesses as well as gov-
ernments. There's nothing immoral in trying to keep VISA from knowing
whom I like to do business with. Digital cash is designed to allow
the convenience of electronic shopping, while keeping the privacy of
ordinary cash payments. Conceptually, it's a simple idea.
Technically, what has to be done to turn an electronic banking proposal
such as Don Bellenger's into electronic cash is some way to make it
so that withdrawals can't be paired up with deposits. You also need,
of course, to prevent cheating such as spending the same piece of cash
twice. It's not trivial to meet these requirements. The Chaum proposal
I described is the simplest one that I know of that achieves this.
On remailers: I haven't yet succeeded in doing a doubly-encrypted
remailer test using Bill O'Hanlon's and mine. Once this works, I'll
post instructions on how to do this, and possibly a script or two to
make it easier. With two encrypted anonymous remailers, you can for
the first time send anonymous messages such that no one person can
know whom you are sending to. Bill and I would have to collude to find
out who sent a particular anonymous message. If more such remailers
can start operating, such collusion will become that much more difficult.
On John Draper: I just wanted to say publically that the famous
"Captain Crunch" was an inspiration to me when I was in college in the
1970's. Although I did not become a "phone phreak" or "cracker" he
represented to me the spirit of questioning authority and exploring
beyond the accepted bounds of the system. I have followed his career
to some extent over the years and I think he has more than paid for
any sins he may have committed in his youth. I for one am thrilled
to have the idol of my younger days on the list.
Hal
74076.1041@compuserve.com
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Mon, 30 Nov 92 11:19:02 PST
To: cypherpunks@toad.com
Subject: Re: Electronic Banking
Eric Hughes points out that the blind signatures used to provide
anonymity in Chaum's digital cash schemes are patented (by Chaum
himself). This is a problem for an official, legal, profit-making
business which wants to engage in electronic banking.
However, such a business would face many other problems. Chaum's
digital cash system could be construed as using the RSA algorithms,
since it is in effect an RSA signature which makes the cash
unforgeable. So a license for RSA would have to be obtained as well.
(RSA licensing would also be needed for secure communication between
the bank and its customers.)
In addition, the acceptable use policies of NSFNET, which would
probably have to be involved in most communications with the bank,
are inconsistent with this kind of commercial activity, from what I
understand. I believe new policies are in the works to allow
commercial activities on the net, but these again will involve
licensing costs.
There is also the question of the legality of private cash in any
form, electronic or otherwise. Nobody seems to have hard evidence on
this. On the one hand, people can legally exchange certain types of
securities, and they could perform services for each other in return
for such exchanges. This is legal, but they are supposed to report
the income on their tax returns. Our digital cash would seem to fit
this model. (But are such securities transfers as untraceable as
digital cash? Perhaps not.)
On the other hand, I read several years ago that casino chips in Las
Vegas were starting to be used as cash substitutes, but that the
government cracked down on this practice. Perhaps this was too
conducive to money laundering, especially with the reputed underworld
activity in that city.
I do think, though, that an informal digital cash system, presented as
a research project or an educational game, would be able to slip
between the cracks of the legal system, much as PGP has done. And I
think this presentation would be legitimate. Digital cash is new
(actually, nonexistant, as far as I know), and any use of it would by
its very nature be research and be educational.
I would suggest that anyone who proposes to implement such a game
might want to consider releasing it anonymously (actually,
pseudonymously). Sign the release with a PGP or RIPEM key, and let
that be your pseudonym. Let people post messages to alt.security.pgp
or some other newsgroup to discuss it, so that you can read them
without revealing yourself, as proposed by Yanek. Post your replies
anonymously using our remailers.
This way there won't be a single-point target for anyone wishing to
punish users of the game.
Hal
74076.1041@compuserve.com
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Mon, 30 Nov 92 19:50:44 PST
To: cypherpunks@toad.com
Subject: Re: remailers
Fen Labalme quotes some messages with concerns about people needing
permission from the sysadmins to run remailers.
The current remailers, based on Eric Hughes' approach, don't have this
problem. I don't even know who the sysadmin is on the system where I
run the remailer. They don't know anything about it. Eric's
remailers don't require continual processes to be run, root
privileges, hacking the mail tables, or anything special.
All you need is to be on a Unix system which supports the ".forward"
file. This is typically implemented by the mail programs which
deliver mail to the user's mail file. The programs check to see if a
file called .forward exists in the user's home directory, and if so
they treat its contents as either a program to pipe the incoming mail
into, or a user name or list of user names to send the mail to.
This is the hook by which Eric's remailers operate. The .forward file
is set up so that mail is piped to a program which sorts the mail
based on its headers, using the mh utility slocal or, in my case, a
perl script which provides some of the same functions. Each message
is checked like this, and if it doesn't contain any of the special
stuff which activates the remailer software, it is simply deposted in
the user's mailbox file as usual. Otherwise the remailers run and
forward it as requested.
With this solution, there's no need for anybody to be aware that you
are running a remailer, as long as it's not too much of a load in
terms of extra message traffic.
Hal
74076.1041@compuserve.com
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Thu, 3 Dec 92 18:36:43 PST
To: cypherpunks@toad.com
Subject: Re: digital banking
I enjoyed seeing Karl's walk-through of Chaum's digital cash
algorithm. The numbers looked right. One point is that doing
different denominations isn't that much harder, you just need to have
more exponents. As you generate your primes p and q, make sure that
p-1 and q-1 aren't divisible by any small primes (other than 2). This
will ensure that phi = (p-1)(q-1) is not divisible by small primes, hence
that gcd(e, phi) will be 1 for those same small primes, in fact for
all the odd numbers.
Karl also quoted a comment from Ray Cromwell expressing concern over
proving deposits. Ideally you'd get a signed receipt from the bank
for every deposit you make. In the case of electronic deposits, there
exist protocols for "gradual secret exchange" that might be suitable
for this purpose. What you'd like is to send the bank your deposit
"gradually", while the bank simultaneously gradually sends you a
digitally signed receipt. I don't recall the details of these
protocols. Gradual exchange would not be very convenient for email
because of the long turnaround times in mail systems, but if you had a
better connection it might be useful, especially for large deposits.
Another way to look at it is, what stops the local merchant from
taking your payment, putting it in his pocket, and then denying that
you've given him anything? It would just be his word against yours.
One answer is, if he does that to multiple people, their multiple
stories would have more credibility than his denials. Similarly, a
bank which made a habit of cheating its customers would find itself
publically exposed. So it may be reasonable to trust the bank for
routine transactions.
Hal
74076.1041@compuserve.com
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Fri, 4 Dec 92 09:55:49 PST
To: cypherpunks@toad.com
Subject: PGP questions
It's probably good to discuss how PGP works here, for educational
purposes, but I would expect people to get the source code if they
really are interested. I can give some pointers here to answers to
some of the questions people have asked.
Steve Witham asks several questions. I think the crypto glossary
which Tim posted a couple of weeks ago tells how RSA works, so I won't
reiterate that here. Steve, if you didn't get it, maybe Tim could
send it to you.
PGP's signature algorithm creates an MD5 message digest of the
message, then signs that digest by raising it to the secret exponent
"d", mod "n". MD5 is a public-domain message digest algorithm created
by RSA Data Security, Inc, which breaks messages into blocks of 64
bytes as input and produces a 16-byte (128-bit) digest. PGP then pads
this 16-byte number to be about the size of n, and does the
exponentiation.
PGP does not do its decryption/signature exponentiation by actually
raising the number to the power of d mod n, but by doing a
mathematically equivalent operation involving two exponentiations, one
mod p and one mod q. Since p and q are half the length of n, and
exponentiation takes roughly the third power of the number of bits in
the modulus, this reduces the amount of time by a factor of 4.
The random number generator has several different modes, and I can
only suggest looking at random.c.
The data-compression algorithm is not really relevant but is based on
zip. The binary-ascii translator is also not important but is a
variant on the PEM standard.
Steve asks a lot of questions about the speed of different versions.
Maybe asking on alt.security.pgp would produce some representative
values. I'm not sure whether anyone has a database with all these
numbers.
I understand that PGP 2.1 may have a faster version of the Upton
modmult. Preliminary timings suggest that it's still slightly slower
than the Merritt modmult on the Sparc, but if Merritt really is
unreliable (I haven't heard about this) then switching to Upton will
not involve much of a penalty. PGP is very fast on Sparcs anyway and
I don't think making it 10% slower would matter.
Profiling indicates that yes, during the RSA encryption phase, most of
the time is spent in modmult. An interpreter could be built to do a
modular exponentiation using a C implementation of modmult and it
would be about as fast. However, that still leaves the generation of
the random session key, padding it with random numbers so that it is
suitable for RSA operations, converting the RSA-encrypted session key
into a format suitable for writing to a file, doing the IDEA
encryption, wrapping this all up with control information so that it
can be decrypted, looking up key information from a key ring file or
some other data file (possibly decrypting it on the fly), converting
to ASCII, etc. All these are part of an encryption/decryption cycle
and can't really be skipped.
Hal
74076.1041@compuserve.com
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Fri, 4 Dec 92 10:03:39 PST
To: cypherpunks@toad.com
Subject: Re: Weakness of the PGP scheme ?
Vanguard@gribb.hsr.no asks about trying all the IDEA keys. If you
will look in idea.h you will see that the IDEA key is 16 bytes long,
which is 128 bits. This is long enough to make trying them all
impossible. Trying to predict one IDEA key by knowing the previous
one also looks hard, as PGP basically cycles IDEA on random input and
takes the output as the keys. If you could predict this output it
would be similar to breaking IDEA.
On the other hand, PGP normally keeps its random information in a
small file called randseed.bin. It uses the contents of this file
plus the current time of day in seconds as the input to generate the
IDEA key. If you stole this file from someone (it's not
cryptographically protected, unlike the secret key ring), and you know
within several hours or a day when he sent each message, you could
probably calculate all possible IDEA keys in a feasible amount of time
(by trying all plausible values for the time of day in seconds). This
would also let you calculate the new contents of the randseed.bin
file. As long as you didn't miss any messages he sent, you could keep
doing this and break all of his outgoing messages.
You can prevent this by removing your randseed.bin file and
substituting an empty file (or one that is less than 16 bytes long) in
its place. This will cause PGP to prompt you for random keyboard
input each time you send a message, which would make it impossible for
the attack above to work. It would mean less convenience, though.
The relevant routines are make_random_ideakey() and
strong_pseudorandom() in crypto.c, as well as the code in random.c.
Hal
74076.1041@compuserv.ecom
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Sat, 5 Dec 92 17:25:29 PST
To: cypherpunks@toad.com
Subject: Anonymous address problems
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@compuserve.com
From: ghsvax!hal@uunet.UU.NET (Hal Finney)
Date: Mon, 7 Dec 92 19:51:29 PST
To: cypherpunks@toad.com
Subject: Anonymous address problems, etc.
Chris Hibbert sent me a solution for the problem I mentioned about the
last remailer in an anonymous address chain being able to discover the
true name for the address. He suggested making your own remailer be
the last one in the chain. If you added a little padding, so the
second-to-last remailer couldn't tell (from the small size of the
encrypted address) that yours was last, this sounds pretty good. And
it's another reason to run a remailer, even if you had to do it
manually.
On the digital cash issue - I think we should get some kind of
implementation of digicash (oops, "electronic money") out for people
on the list to play with. Then, we should think of some kind of
experimental email-based game to play which would use the special
characteristics of anonymous cash. Maybe we could use the remailers,
too. Players would send cash back and forth to each other as part of
the game. Even if the tools are sort of rough at first, this could
show where the most work is needed.
Can anyone think of a good kind of game that we could play? As Eric
Hughes pointed out, the cash doesn't have to be "cash", it could
represent "gold" or "carrots" or any other material which exists in
limited quantity.
I think it was on the extropians list that Eli Brandt pointed out the
need for a shorter term than "digital cash" for this cryptographic
money. He suggested "cryps". I thought of "emoney" or "ecash" by
analogy to "email". Here's another one: "crydets", based on
"credits". Or maybe we should call them "Chaums". That way he'd be
less likely to sue us for infringing on his patent. ;-) I notice he
managed to cleverly name DC-nets after his initials so maybe he'd like
this.
Hal
74076.1041@compuserve.com
P.S. I hear PGP 2.1 is coming out today.
|
