implement Sealers/Unsealers

[Brian Warner]

Sealers and Unsealers are the object-capabilities equivalent of public key operations: encryption, decryption, signing, verifying. It would be useful to have them available in a Foolscap environment.

(note, #19 is about making the Tub's public/private key available for use as a sealer/unsealer. This ticket is about creating and using new keys, not the Tub's SSL key).

The API that I'm imagining for this is:

   s,u = tub.createSealerUnsealerPair(brand)
   d = s.seal(obj)
   d.addCallback(lambda sealed_box: u.unseal(sealed_box))
   d.addCallback(lambda new_obj: yay)

The big questions in my mind right now are how to handle interesting objects. I want the contents of the box to be an arbitrary object graph (almost anything you could pass to callRemote), but things things like live references may or may not work. Handling live references will certainly require access to a Tub, which is why create() is a method of a tub instance rather than a top-level Foolscap function. seal() and unseal() return Deferreds for the same reason.

My plan is to implement the serialization by using the normal banana code, but with a different root Slicer that provides alternative Slicers for the things that get handled differently here (i.e. ones that reject liverefs, or turn them into sturdyrefs, or something).

There are two different forms of sealers: cryptographic-based and reference-based. The first can be copy-by-value, the latter must be copy-by-reference (and requires a connection to its host to use). Both have their uses.. I'm not yet sure if I should implement both or just the cryptographic one.

In E, each sealer/unsealer has a distinct "Brand" object, which also have non-distinct string names (i.e. there could be two Brands with the same name but which are completely unrelated). I'm not sure if I should do that here or just attach a string name to the sealer/unsealer.

Here is a useful thread on cryptographic sealers/unsealers in the objcap world: ​http://www.eros-os.org/pipermail/cap-talk/2007-March/007595.html

[Brian Warner]

I just did the first step towards this: adding Tub.serialize and Tub.unserialize, which can handle Referenceables.

[Brian Warner]

For reference the properties of a Sealer/Unsealer? pair are:

• Sealers take an object(graph) and return a sealed Box
• Unsealers take a sealed Box and return an object(graph)
• once sealed, the only way to open a sealed Box is with the right Unsealer (encryption)
• the only way to get an Unsealer to return an object(graph) is with a Box created by the corresponding Sealer (signature)
• Boxes can be queried for an identifier that describes which Sealer produced them. I believe this is called a Brand, and that both Sealers and Unsealers will return their brand, and that Brands are useful if you have to search through a large set of Unsealers to figure out which one you want to unseal with.

This means that cryptographic Sealer/Unsealer? pairs actually have two keypairs. The first is for confidentiality, and the Sealer holds the public (encrypting) key, and the Unsealer holds the private (decrypting) key. The second is for integrity, and the Sealer holds the private (signing) key, while the Unsealer holds the public (verifying) key.

I still haven't figured out how to get access to the crypto primitives I need. For Tahoe, we're using zooko's excellent ​pycryptopp package (which is a python wrapper around the even more excellent ​Crypto++ library). But I don't want to add new dependencies to Foolscap, so I'll probably need to find a way to get the functionality I need out of pyopenssl.