Split Capabilities: Making Capabilities Scale

[Mark S. Miller]

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