Previously¹ I suggested a disposable key design using a merkle tree that would commit to a set of pubkeys. The downside of course being that each signature needs a merkle tree path to prove the pubkey was in fact part of the original set. In the context of timestamping, we might need a pubkey per second, which works out to 2^27 seconds for a 4 year key lifetime, a 864 byte merkle path. That's actually pretty big!
Here's a simpler system: create a set of delegation signatures from a master pubkey in advance, each signing a commitment to a index and a secondary pubkey. Then delete the master secret key. As with the merkle-tree based scheme, the private key for the secondary pubkey's can be deterministically generated. A signature for the sceme is then the secondary pubkey's signature, the secondary pubkey, and the delegation signature. Pubkey recovery could even be used, allowing the secondary pubkey to be omitted; with secp256k1 using pubkey recovery signatures could be as little as 129 bytes in size. For 2^27, 4 years, worth of disposable keys, we need to pregenerate and store just 8.7GB of signatures - not a big deal! Even 2^32 keys is just 279GB, which can do 13.6 years at 10 pubkeys/second. While this is nearly the same security model, there is one nuance: in the event of a ECC break, unlike the merkle tree version, destroying the secret keys does *not* prevent an attacker from creating more false signatures for previously unused indexes. I don't think this actually matters though, as in the timestamping use-case you'd be using a secondary, non-ECC dependent, form of timestamping on the trusted signature anyway (e.g. w/ Bitcoin). Re: backups, I don't see any reason why the pre-generated signatures need to be kept secret. In fact, it's possibly better if they aren't, allowing anyone to verify that the intended pubkeys got used. # References 1) https://lists.opentimestamps.org/pipermail/ots-dev/2017-May/000001.html -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: Digital signature
