[tahoe-dev] DSA "intermediate"/"semi-private" keys, pycryptopp API proposal

[Brian Warner]

So, for a couple of months now, we've been discussing how DSA mutable
files could benefit from a clever "semi-private" key scheme that Zooko
figured out. In this scheme, instead of just privatekey->publickey,
you'd have privatekey->intermediatekey->publickey.

DSA mutable files would take advantage of this by using the privatekey as the
writecap, the intermediatekey as the readcap, storing the publickey in the
share, and using the hash of the publickey as the storageindex. The data
would be encrypted with a key derived from the intermediatekey (and a salt
that is changed each time the file is replaced, to avoid using the same AES
key twice).

I drew up a possible pycryptopp API to expose this sort of functionality. I
know that Zooko is looking at pycryptopp a little bit this week, so I wanted
to plant a seed in his brain as he looks through the code.

The diagram is here:

  http://webapi.allmydata.com:8123/file/URI%3ACHK%3Am54ibef32bqtyadpmnc5yk6yvy%3Apavnicxmuv2jxdynrlkwjkd6kie3xkfdl42sk4fwbkse6wctulza%3A3%3A10%3A180974/@@named=/semipriv-DSA-pycryptopp-API.png

 (and attached, just in case our mailing-list manager wraps that URL)

Basically, the SigningKey object would acquire a get_subordinate_key()
method, from which you could get the next key down the chain. SigningKeys
(and SubordinateKeys and VerifyingKeys) would need to be created knowing the
number of intermediate keys you planned to use, since obviously it determines
the public key that you're going to wind up with. Each of the SubordinateKeys
would have a serialize() method, and could be reconstructed from the
serialized string. You can call get_verifying_key() on anything to jump
directly to the VerifyingKey instance. Each object would get a hash() method
that would return a string, which could then be used as an AES key, possibly
hashed with a salt first.

Thoughts?

 -Brian

(PS: we should probably think about exposing encrypt/decrypt at some point
soon too, since that may be required to get away from connection-oriented
protocols in the future).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: semipriv-DSA-pycryptopp-API.png
Type: image/png
Size: 177547 bytes
Desc: not available
Url : http://allmydata.org/pipermail/tahoe-dev/attachments/20081015/72b85b5f/attachment-0001.png