Re: A stab at the sealer in E hal@finney.org
Sun, 7 Nov 1999 23:23:34 -0800

Mark S. Miller, <markm@caplet.com>, writes:
> Let us call implementations like Ping's or MarcS's "pointer-based public
> key" as opposed to "cryptographic public key". Why do we also need a
> cryptographic public key implementation of sealer/unsealer? To provide the
> power of cryptographic public key to the E programmer in the inter-vat
> case. What is this power, over that of using pointer-based public
> key? *Only* the removal of the mutually trusted third party.

I think I understand. With the PassByProxy model, VatS, which holds the BrandMaker, gets access to the capability being sealed, even though that capability may only be intended to be delivered to Bob. VatS must be trusted not to misuse that capability. With a crypto based PassByCopy model, the sealing is done locally and no one other than Bob will be able to unseal it (other than people he gives it to).

In terms of your auditors, would it be that the PassByCopy BrandMaker would be accepted as confined (or some similar security property) while the PassByProxy version would not? You might have two flavors of BrandMaker in the system, the crypto one which is slow and bulky but passes the auditor for cases where that is needed, and the PassByProxy one you have now, which is very fast but does not pass the auditor? Then, you want to make sure that they are semantically equivalent other than this auditor test?

One problem I still see is that the PassByCopy version could leak information about how big the sealed data is. Imagine that instead of passing the sealed envelope directly to Bob, Alice first passes it to Ted who gives it to Bob, and Ted isn't supposed to know what is inside. It is supposed to be opaque to Ted. But the PassByCopy version lets Ted know how big the encrypted data is, potentially, while the PassByProxy version would not, I think. (Maybe this would only happen if the data being sealed was itself PassByCopy?)

Is it anticipated that user-written objects would ever be PassByCopy? The security properties of such an object would be very different from those under the PassByProxy model, because the object would not be able to keep secrets from whatever Vat it runs on. It would be necessary to be very careful in writing such code, and the security analysis would be completely different than for PassByProxy code. The mint code, for example, would obviously be completely unsafe if the purse were PassByCopy.

On the other hand it would be quite useful if such objects could exist, whereby you could bring in some code from a foreign machine, audit it for safety, and then run it locally. You would feel safe in giving your secrets to this piece of code because you'd know that there was nothing harmful it could do with them.

Thanks for the helpful discussion -

Hal