At 11:43 AM 7/12/00 , Jonathan S. Shapiro wrote:
> > >I agree that crypto capabilities are expensive to produce, but that may
>be
> > >reason to postpone creating them until they are actually needed.
> >
> > In E, we indeed treat cryptographic capabilities in the
> > lightweight and disposable fashion Norm describes as the KeyKOS style...
> > But please don't assume SPKI is representative of the
> > costs of cryptographic capabilities.
>
>The costs I was thinking about were not storage costs, but encryption time
>when fabricating the key. Is fabrication time really low enough that
>capabilities can be created willy nilly in E?
The short answer is yes. The only per-key cryptographic calculation is getting another 128 unguessable bits from the hosting vat's cryptographic pseudo-random-number generator. The only cryptographic cost of transmitting this over an already established secure connection is the cost of encrypting & MACing the key representation (detained in earlier email) with already established single keys -- exactly as it would be with an SSL connection. In both cases, the cost is so negligible that you'll have trouble finding it in a profile of any real system.
>Perhaps I should be asking: is the excessive capability creation time in
>SPKI a problem confined to SPKI?
Yup. But perhaps SPKI's costs are not confined to SPKI per se. It's possible that SPKI's costs are representative of off-lie capabilities with built in auditing & non-repudiation. By contrast, E is on-line, and does not by itself provide for auditing or non-repudiation. These features can be built in E, but at additional cost. Another contrast: SPKI relies only on authentication to implement its properties. E relies on both authentication and secrecy. Where E uses secrecy in place of SPKI's use of authentication, secrecy is a far cheaper solution.
Cheers,
--MarkM