[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