From: catalyst-remailer@netcom.com
Date: Mon, 14 Mar 94 08:51:22 PST
To: cypherpunks@toad.com
Subject: Magic Money Complaints / ATTN Warlord
Message-ID: <199403141652.IAA20000@mail2.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

Message to Warlord:

- -----BEGIN PGP MESSAGE-----
Version: 2.3a

hGUCOHQrXMGwavEBAsQIisQa4G1UakyzJXvV0MuEUUQT3K8y2k0ox7x6LPdfSozu
V0/IRkUM1peH07i6FK7WY19MunhfkZh2K9rVR+UzuVKp4bG7w+S4bjQk3DRsjiyH
1u58JcGtVaYAAAB0FFCAeBcjzwoH4yRD8GyNyjHPhAE5HPudT1IvenINfDc0HD5I
qZs1FhNctxMsukhVJvoK5xtUhBOuCR6CtVxjeVtxniR1kq2sd7RO3sg7FknIuHer
l88hJYcZqFpfcb5c+7m3tKjvqzMw2keRSsydVxXQY+M=
=rBux
- -----END PGP MESSAGE-----

Hal Finney wrote:

>I hate to complain.  Magic Money is something that people have been asking
>for for a long time, and it's a very nice implementation.  A lot of aspects
>have been really well thought out, particularly the money aging and replace-
>ment.  But I've been playing with it off and on lately and there are some
>improvements needed IMO.

I'd rather have people playing with it and complaining about it, than
ignoring it. I'd about given up hope that anyone would do anything with
the program. Someone please set up an emailable server!

>I'll just assume interested readers know how the program works and jump
>right into it.

> - The program handles encryption of messages to and from the bank auto-
>   matically, but makes the user have to handle encryption of messages to
>   other people.  I can see some justification for this - maybe the message
>   (that is, a coins.dat file) will be sent via secure means like a direct
>   or IR connection, so encryption is not needed.  But most of the time it
>   is needed, in which case the user has to use PGP or something as a sep-
>   arate step.

I was lazy. To do this properly, you would have to have the ability to
include a message along with the coins, and encrypt it with someone's
PGP key, then decrypt it and display it at the receiving end and separate
the message from the coins. You would about have to rewrite PGP within the
Magic Money client. I could have written a perfect digital cash system,
in which case I'd still be designing it and no code would have been written
at all yet. But I was lazy.

> - The program distinguishes between bank messages, which are signed blinded
>   coins, and user messages, which are raw coins, by whether they are in
>   ASCII text or not.  This is not the significant distinction between these
>   two kinds of messages.

Yes, it assumes you are going to feed it the message in the same format
it was output in. A bank message is signed and encrypted, while a coins.dat
is a raw binary file. User-to-user communication is left up to the users.

> - Bank messages look just like other PGP messages.  But the user has to
>   know not to try to run them through PGP and instead give them directly to
>   the MM program un-decrypted.  The only way he can tell is to notice that
>   the sender address is the bank.  If the bank ever sends him a real coin
>   file (which it may to prime the pump) then the user just has to know
>   to treat these messages differently.

Ummm, true. What should I do about this? I wanted Magic Money messages to
look just like any other PGP messages, to avoid the possibility of people
using the program being singled out. Doing what you suggest would require
the server having the ability to encrypt with someone else's public key,
unless the bank uses PGP to encrypt a coins.dat file. 

> - There is no way to know which bank an incoming coin file is for.  I think
>   this is one of the biggest weaknesses of the system.  If more than one
>   bank is competing I have to know which bank a given coin file is
>   associated with and go to that directory to process that coin file.

If you were using multiple banks, that would be a problem. So far there
aren't any banks at all, so... but a future version could have the bank's
key id in front of a coin file. Then you would have multiple bank public
keys in bank.pub, and multiple coin files, and multiple elists. And you 
would have to know what bank the person you're doing business with uses, 
so you could send him the proper coins...the complexity grows exponentially.

> - There is no way to put coin files directly into your allcoins.dat file.
>   There are a couple of cases in which you might want to do this.  First,
>   you might pay out some coins and then change your mind before sending
>   them, and want to put them back.  Or second, you might receive some coins
>   from a trustworthy person (your mum, say) and just want to add them
>   without going through the bank.

This is easy to include, and I considered doing it, but it is dangerous.
It would be easy to put coins back into allcoins.dat and then forget and
send them out, thus double-spending. If you take coins out and then want
to put them back, you can always exchange them with the bank yourself.

> - More generally, it is difficult to use the program in a safe way which
>   deals robustly with errors of various types.  When I was first building
>   the program I had some bugs which caused coins to appear to be double-
>   spent, to not signature-check properly, to not be found in 
>   the proto file,
>   etc.  The program did not appear to handle all of these errors safely,
>   sometimes aborting in the middle of a file.

Where are these bugs? Are they still present in the latest version?
I'd like to get rid of them - what did you change? Error handling is a
bitch - in most cases, I just didn't know of a good way to handle an error.
What do you do if a signature fails, or a coin is not in the proto-file?
Ignore the coin and go on? Then you have the wrong amount of money.

>   In addition, the program always calls its output files coins.dat and
>   output.asc.  If you run it twice without renaming these files you can
>   lose data and lose money.  Then, when you send the files, you need to
>   manually keep backups in case the email fails.  Again, otherwise you will
>   lose money.

Should it use an incrementing name: coins.000,001,etc. so no files will be
lost? This would be an easy change to make.

> - The money data structures do not allow for expansion.  I'd like to see a
>   way of adding new fields in the future which will be ignored by older
>   versions of the program.  For example, in regard to the above, I'd like
>   to see a "bank email address" and possibly a bank key added to the
>   coins.dat file.  Then you could mail the coins to someone without 
>   including
>   a lot of out-of-band data about the bank they were for.  It would be nice
>   if this could be done without totally breaking the current program.  At
>   a minimum a version number could be stuck at the front so that old 
>   programs
>   would recommend that users upgrade.

Yeah, a mode byte at the beginning so later versions could be downward
compatible with the earlier ones. The coins do have an identifier byte
before each coin type. Later versions could use different bytes.

> - The program uses PGP algorithms and data structures, but not its files.
>   The bank's key and user's keys are kept in separate files.  There might
>   be advantages in putting these keys into PGP's regular files.  

Since the keys are only used for digicash purposes - why?
See my complaint above about how these changes would require a whole PGP
inside the Magic Money client. I can only write so much code.

>   Also, the
>   random number generation in PGP looks stronger than MM, since it keeps
>   much more state from run to run.  MM seeds based on a very, very 
>   elementary
>   hash on a file called rand.dat, which will tend to be fixed, and the 
>   time of day.

Ahem...this I will take issue with. Magic Money (and PGP Tools in general)
uses an MD5-based random number generator which works as follows: the
program takes some input random data and cyclically XOR's it through a
buffer, whose size is determined at compile time. At present, it is set
to 256 bytes. Then, for each 16 bytes of random data requested, the program
takes the MD5 of: the time, a counter, and the 256-byte buffer. Now, if an
attacker does not know the contents of the seed file, knowledge of the time
and the counter value gets him nothing. The fact that the file does not
change is irrelevant, because the non-reversibility of MD5 prevents the
attacker from finding out anything about the file.

> - None of the MM files are encrypted on the disk.  The money files could
>   be stolen by someone with access to your computer, and your secret key
>   used for communications with the bank could be stolen as well.  This
>   would be a major security flaw in some situations.

Yeah, true. For serious use (real money) you would want either an encrypted
filesystem (I use SecureDrive) or a passphrase on your allcoins.dat file
and the secret key. The server's secret key, which is the most valuable
of all, can't be encrypted because the server has to be able to read it
without a user present.

>Having made these complaints, let me reiterate that I am very pleased with
>this program overall.  I also appreciate mpd@netcom.com's efforts in 
>running a server.  

Is his server e-mailable? How do you access it?

I have built a Mac client for MM which is not too mac-like but
>lets you drag-n-drop incoming files onto the MM icon and it handles 
>them right.  I'll tweak that a little more then upload it with the 
>other clients.

How much trouble did you have compiling it big-endian?

Magic Money was not intended for serious real-money use. For a real-world
usable program, the crypto core would have been buried in many thousands
of lines of support code, and the program would never have seen the light
of day. It was intended to serve as a minimal but usable digicash program,
so people could play with digicash. It is not perfect, but it is the best
digicash system in the public domain. (It's the only digicash system in
the public domain, but that's beside the point!)

                                                 Pr0duct Cypher


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLYQjjsGoFIWXVYodAQEh+AP/eJhhTuNuf82eYvKc4Q7z8wz1wE3rkjwU
K3Ca7pmggMq8bIeGmdkNJgLLDZ9llY/WaNKdT43nd9/PoTvUsQLxd4oXNAnk/4ud
4vGRKsI3bOoTmlhOepgjMAUy7w2yCu4niEh0WwZstj2t0lWLqU7YdZK5uleuvk8g
fof2Ebl7PEY=
=k16k
-----END PGP SIGNATURE-----