Public Key Crypto

Connections with Public Key Crypto

Mark Miller observed an important conceptual link between capabilities and public key cryptography such as RSA. The map is that knowing the public key of a key pair, is like holding a capability to an object and thereby being able to send messages to the object, whereas knowing the private key of that key pair is like being that object so as to be able to decipher and interpret those messages.

One difference is that a capability is normally implemented to locate the intended object so as to efficiently deliver a message. There is not usually a presumption that knowing someone’s public key helps to find the person in order to deliver a message. Also it is usually thought that public keys need not be kept secret.

There is no sense of “non-repudiation” as provided by public key signature here. Diffie-Hellman can thus be used in place of RSA as non-repudiation is not required.

Some applications of the concept bridge from capabilities to crypto:

Consider designs that solve problems by limiting the distribution of public keys. Deliver public keys only to those that should be able to request the services of some agent that knows the private key. Agents then know to act on a request ciphered by the public key without further authorization. When a message arrives that is deciphered by the private key, it is necessarily from someone with the authority to ask for the service. (But beware!) In purely crypto terms the observation is that one key pair can provide both secrecy and authentication if the distribution of the public key is suitably limited.
Build directories that map public keys to physical locations of the private key holder. The public key would then suffice to both encipher and route the message. This map may be one-to-many. A moving agent can insert the new address and later delete the old address.

Some languages such as Joule and systems such as Mach (I think) separate the authority to receive messages from the identity of an object. I may pass you the authority to receive on a channel (Joule) or port (Mach), whereupon you will receive the messages. This is like multiple people knowing a private key.

This concept bridge is also useful in the design of distributed capability systems or distributed object systems. See Distribution.

Mixing the two schemes suggests the following. Imagine objects in an infrastructure where there is relatively reliable delivery service but no communications privacy. We want to build reliable systems. Each object chooses a key pair upon creation and disseminates a bundle consisting of the public key and a locator suitable to the infrastructure. This bundle serves as a capability to the new object. The bundle suffices to send a message to the object that only the object can read.

A variation on the above bundle it to bundle the locator with a hash of the public key, perhaps the key’s standard fingerprint. Perhaps a 70 bit hash will do if there are no birthday attacks. Otherwise about 140 bits might be needed. There is a latency penalty here as X, the bundle holder, must first send a message to Y, the private key holder, to get the public key of Y. This message can include X’s public key so as to protect Y’s public key in the return message. I assume here that objects have public keys with which they make such queries that are distinct from the public keys whose dissemination controls who is permitted to ask service of an object. The fingerprint becomes the authority to invoke the object. If elliptic curve public keys are as small as promised then this scheme has little to recommend it.

Synergy

Sealing and unsealing present another pattern even more like public key crypto. Both public key patterns, secrets and signatures, have matching sealer analogs:

Signature: If the sealer is closely held and the matching unsealer is more broadly held then box contents can be ascribed to the code with the sealer by anyone with an unsealer. Holding the sealer closely has the same incentives as holding the private crypto key closely. This is a form of non-repudiation. Morris hints at this in his paper.
For the Eyes of …: A broad collection of code, that holds a sealer, is able to prepare objects so that only a narrow collection of code that holds the matching unsealer can access those objects. For better or worse delivery is a separate matter, and that makes the sealer pattern even more like public key crypto.

This is a different sort of isomorphism between public key crypto and capabilities.

Assume a system with mailboxes for each of which there is a capability to withdraw messages, and a different capability to insert messages. Each mailbox has an internal message queue. Some capability systems bottom out this way. The isomorphism with sealers is closer in this case, but the mailboxes arrange for delivery while the sealers do not. Just now it is not clear to me whether one can be built on the other.

There is some math to be done here.

See this and this.