[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:
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.