On the other hand, this gives me an interesting thought.
If you could force private keys to be expensive to generate, this attack wouldn't work. It might be interesting to have a special kind of private key, which was expensive to generate but that had a relatively short secure ID. You could do this by accompanying the key itself with a proof of work bound to the key; for example, the key could be
(hardkey *key* *nonce*)
such that H((hardkey *key* *nonce*)) matches H(*key*) in, say, the last 25 bits; these bits are not used in generating the key identifier. That shaves 25 bits off the minimum secure length of the identifier for the key. With such a scheme I can imagine reasonably secure identifiers which were, say, 20 letters long, noticeably more convenient to match than the 40 hex digits OpenPGP uses.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
Re: Zooko's triangle
Date: 2007-03-01 11:47 am (UTC)If you could force private keys to be expensive to generate, this attack wouldn't work. It might be interesting to have a special kind of private key, which was expensive to generate but that had a relatively short secure ID. You could do this by accompanying the key itself with a proof of work bound to the key; for example, the key could be
(hardkey *key* *nonce*)
such that H((hardkey *key* *nonce*)) matches H(*key*) in, say, the last 25 bits; these bits are not used in generating the key identifier. That shaves 25 bits off the minimum secure length of the identifier for the key. With such a scheme I can imagine reasonably secure identifiers which were, say, 20 letters long, noticeably more convenient to match than the 40 hex digits OpenPGP uses.