[E-Lang] MintMaker with ACLs

Mark S. Miller markm@caplet.com
Thu, 01 Feb 2001 13:25:45 -0800


At 11:49 AM Thursday 2/1/01, Marc Stiegler wrote:
>Though quantum computers can attack the encryption algorithms required for
>all current forms of secure distributed programming (not just capability
>systems), 

Ok, here's one for the Ripley's Believe it or Not of Capability Security.

As Vernor Vinge so vividly pointed out in A Fire Upon the Deep, there is one 
form of cryptography that remains strong in the face of arbitrarily huge 
increases in compute power -- one time pads.  In his novel, one time pads 
were the only reliable form of encryption, and were the main reason for 
engaging to interstellar travel -- to courier them.

In deploying any cryptosystem, initial connectivity is bootstrapped via 
(hopefully) trustworthy channels in previous media, such as sharing of PGP 
keys on business cards at parties (with physical meat presence), or sending 
"cap:" URI strings over PGP encrypted email.  The power of cryptography, at 
least from a capability point of view, is to then continue to have trusted 
interaction in the new medium, leveraging only the *initial* connectivity of 
the old medium.

By comparing the essences of Pluribus 
http://www.erights.org/elib/capability/ode/ode-protocol.html (our PK-based 
crypto capability protocol), and Unibus 
http://www.erights.org/elib/object-pluribus/unibus.html (our 
symmetric-key-only crypto capability protocol) shows that, as far as "the 
key distribution problem" is concerned, there's much less fundamental 
difference between PK and symmetric key than is normally thought.  PK is 
better, and Pluribus enables certain patterns of external (outside Pluribus) 
initial introductions that Unibus does not.  But they are both workable 
crypto capability protocol.  (Unibus was invented precisely to make this 
point in a debate on another list.)

Can we do yet worse?  I believe I have a wildly impractical but 
theoretically sound design in my head for a crypto capability protocol that 
relies only on one time pads.  Like the others, it depends on external 
introductions to bootstrap.  However the burden it places on those who would 
make bootstrapping introductions scales so horrible that I couldn't bear to 
calculate it.  OTOH, we only have this problem in a world with exponentially 
greater computation, so maybe that world could afford this solution.  I can 
explain it if anyone's interested.  But if you're really interested, try to 
figure it out first. Hint: the Unibus design isn't a bad starting point.


        Cheers,
        --MarkM