mutable files: pre-generate public keys in the background

[warner]

I was describing my concerns to robk today, that the new mutable-file code in tahoe may be too slow, specifically because a new public key pair must be created for each new slot. This involves making a large prime or two, and my rough tests suggest it takes a second or so for each one, which is fine for human time scales but becomes a problem if you tell your node to make a deep copy of some folder tree and it needs to create a hundred dirnodes all at once.

robk had the brilliant idea to pre-generate these pubkeys. Just have the process quietly create a new one every minute until it has a stash of a few hundred, then drain from that pool as necessary. Pickle them into a (private) file on disk.

Note: the keys must be carefully protected against accidental disclosure. Also, we must manage them carefully to make sure we never use the same key for two different dirnodes. (I don't remember offhand if we're using the keys in such a way that duplicate use would leak crypto secrets, but we should pay attention to things like that).

Also, as usual, we should try to get as good an entropy source as we can, since the RNG is important to making these keys secure. This may influence the scheduling of key pre-generation: you might wait until the system entropy pool is not empty or something.

I like quiescent agents, but I also like not waiting two minutes for a large copy operation :).

[zooko]

I'll bet if we use ElGamal? or DSA, this key-generation time will be small enough to not worry about for now.

See also #217, about how to have smaller URLs. One-crypto-value URLs can be made to work with either RSA, DSA, or any other sort of public key signature scheme, but I used DSA as the example there and DSA makes certain parts of that proposal nicer.

See also #220 which suggests that we have an automated measurement of this issue.

[zooko]

We've agreed to go ahead with #217 for more efficient crypto and #220 to measure the same, so closing this one.