Re: Comments on FC00 paper Mark S. Miller (
Mon, 01 Nov 1999 14:21:40 -0800

At 11:11 AM 11/1/99 , wrote:
>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:
> > ...
>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.

It depends on how you define the semantics of a public key encryption system. Let's take vanilla RSA as a canonical public key system. At the time when Joe generates an encryption/decryption key pair, only he knows both of these keys. Conventionally, he would make the encryption key public, hence the conventional name "public key", and he would keep the decryption key secret, hence the conventional name "private key". However, these are only patterns of use. For example, is a pattern in which both keys are treated as secrets, but can both be distributed in limited ways. The encryption key is effectively the write authority into a virtual communications channel, and the decryption key is the read authority.

What I take to be the defining semantics of public key encryption is that the two keys are inverse functions, and neither key can be inferred/generated given access to plaintexts, cyphertext, and the other key.

>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

If I were modelling signing/verification, I would provide my envelope object with a message for obtaining its contents (and I would rename it "postcard"). However, I need both the equivalent of authentication and encryption, since a client of a purse must not be able to obtain that purse's decr facet. Therefore, I need opaque envelopes.

>It would not need to be "public" key and could be a pure "secret"
>key cryptographic operation.

It is true that this code could use a single-key system instead. However, the public-key abstraction is generally more expressive, and as implemented locally (within the mint's vat) out of pointer operations and safe language techniques, it's no more expensive than the single-key equivalent.

>The description in terms of public key
>encryption/decryption becomes somewhat misleading.

Better phrasing would be most welcome. I arrived at this abstraction by reasoning from analogy with public key, but that doesn't mean it's the best way to explain it.

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

Correct, except for Alice's

                     define paymentForBob := AliceMainPurse sprout
                     paymentForBob deposit(10, AliceMainPurse)
                     bob foo(..., paymentForBob, ...)

and Bob's

                     to foo(..., payment, ...) {
                             BobMainPurse deposit(10, payment)
                             # proceed only if we got $10

All the purses being manipulated by the above code run on VatM.

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

Yes. The sealer/unsealer operation is not actually a cryptographic operation. It is implemented out of pointers using safe language material but, given trust in the vat a given sealer/unsealer pair runs on, it provides the same logical security properties as provided by asymmetric encryption/decryption keys.

At some point I am planning to write CryptoBrandMaker in E. CryptoBrandMaker will be polymorphic with BrandMaker, but when a reference to a sealer or unsealer of a key pair, or any envelope sealed by that pair, first gets encoded for transmission to another machine, then an actual cryptographic key pair is internally generated and the bits encoded are cryptographic. This is a big topic, and certainly irrelevant to the paper, but I thought I'd mention it in case you're interested.

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

I would be very interested in hearing more about this. I have had trouble communicating my ideas to some crypto types, including some I have extraordinary respect for. It's frustrating. I know I am communicating a different paradigm (sorry for using that word), and I sense that crypto people don't find the handholds they are used to. I seem not to have a good sense for which crypto-paper conventions are the important handholds vs incidental. Any help explaining this to crypto types would be greatly appreciated.

>It's not clear to me whether E is intended
>[#1] as a language for expressing and implementing these protocols, or [#2] as a
>high level language built upon certain cryptographic primitives which
>may then be used to implement certain other protocols, or [#3] something

If I understand #2, then #2.

May I forward our correspondence to the E list? Others may find it informative as well.