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