Comments on FC00 paper

by way of "Mark S. Miller" <markm@caplet.com> hal@finney.org
Mon, 01 Nov 1999 14:20:07 -0800


[Forwarded with permission.  --MarkM]

Hi - I recently read your draft paper for FC00 and had a couple of
comments.  I am someone not familiar with E but with knowledge of crypto
protocols, which would be typical of many in your audience.

The one thing I found which did not seem consistent with my understanding
was the description of the seal/unseal operation:

 > Sealer/unsealer pairs are similar in concept to public/private key
 > pairs. The sealer is like an encryption key, and the unsealer like a
 > decryption key. The provided primitive, BrandMaker, makes and returns
 > such a pair. When the sealer is asked to seal an object it returns an
 > envelope which can only be unsealed by the corresponding unsealer.

Later, where they are used in the cash example:

 > Whatever we get back from getDecr we then unseal with the unsealer of
 > our creating mint. This will succeed only if the argument is an envelope
 > sealed with the corresponding sealer. One can only get such an envelope
 > from a purse created by the same mint, and therefor of the same currency.

This behavior is not that of public key encryption/decryption.  With PKC,
anyone can encrypt, and only the holder of the private key can decrypt.
The fact that the decr object unsealed (decrypted) successfully is NOT
a guarantee that it was sealed by the mint.  Anyone could potentially
have sealed it, by the semantics of public key cryptography.

Now, it may be in this case that the sealer never left the mint, in
which case you would be right and the fact that it unsealed OK would be
proof that it came from the mint.  However in that case the seal/unseal
operation is more like an authentication operation than an encryption
one.  It would not need to be "public" key and could be a pure "secret"
key cryptographic operation.  The description in terms of public key
encryption/decryption becomes somewhat misleading.

I think part of my confusion is with what part of this code runs on
the mint and what part runs on the client's machine.  Reading on in
your article, it appears that everything runs on the mint.  The clients
have only references (pointers, capabilities) to their purses.  They make
requests to the mint to run the methods associated with the purse.  But in
that case it doesn't seem necessary to use a cryptographic operation to
confirm that two purses come from the same mint.  It would seem that the
mint would be able to tell whether two purses both were created by it,
without the need for a cryptographic step.  Perhaps I am misunderstanding
this part.

I am still studying the rest of the paper.  It is interesting but I am
finding it somewhat difficult to relate to the issues normally addressed
by cryptographic protocols.  It's not clear to me whether E is intended
as a language for expressing and implementing these protocols, or as a
high level language built upon certain cryptographic primitives which
may then be used to implement certain other protocols, or something
else.

Hal Finney
hal@finney.org