A stab at the sealer in E
Sun, 7 Nov 1999 23:23:34 -0800
Mark S. Miller, <email@example.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
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 -