No, I'm not imagining dumb attackers, thank you very much. I do adhere to the Rational Attacker paradigm in my security analysis.
I know that enumerating DSS keys is relatively cheap. Moreover, there is an even simpler way of enumerating 2^32 OpenPGP keys of any kind, since the date of creation (which, is, by the, way unused by modern implementations -- they use the timestamp in the self-signature) is represented in 32 bits and hashed into the key ID. But just hashing 2^32 times roughly half a kilobyte is difficult enough to prevent most casual attacks.
FYI: the fast way of enumerating RSA keys is to make them asymmetric: one of the primes is chosen to be small. Thus, one trial implies one multiplication and one hashing (and a small prime sieve).
Your second assertion does not hold much water either. You're talking from the point of view of theoretical cryptography (where the goal is to make attacks computationally infeasible), whereas I am talking about practical security (where the goal is to make attacks economically unattractive). From your point of view, putting a lock on your front door doesn't make any sense, since affordable locks are easily picked and the door can be kicked down anyway. In reality, having a lock on your front door vastly increases your security, because it raises the costs sufficiently to keep casual attackers out. Sufficiently determined attackers will find their way in anyway. Yes, an 2^44 enumeration is within the range of a lone, unfunded attacker (albeit on the very far end of it), but he has better things to do with his resources than generating a key with the same ID as another random key for which he probably has no use whatsoever.
Thus, I hold on to my assessment of the security of 32 and 64 bit identifiers. I challenge you to generate a feasible-looking V4 PGP key with the same 32-bit ID as mine. It's 0x34F5BB91, as you can see from my user profile.
As for the second paragraph. There can be many additional security measures: the system can refuse to register keys with already taken 32-bit IDs, the system can provide facilities for verifying 64-bit IDs or even fingerprints, there can be some PKI-ish thing in place (WoT, CA hierarchy, whatever). And so on and so on.
Giggle all you want, but take look at the really successful security system. For instance, paper money. It has many security measures in place and it is up to the users to decide which ones are worth checking in every particular situation. Yes, there's some fraud in the system, but its overall security is sufficient to keep the economy afloat. The '90s ideal of unbreakable security for every joe (for free!) is just that: a pipe dream. It's time to get back to Earth.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
Re: Zooko's triangle
Date: 2007-03-03 05:56 am (UTC)I know that enumerating DSS keys is relatively cheap. Moreover, there is an even simpler way of enumerating 2^32 OpenPGP keys of any kind, since the date of creation (which, is, by the, way unused by modern implementations -- they use the timestamp in the self-signature) is represented in 32 bits and hashed into the key ID. But just hashing 2^32 times roughly half a kilobyte is difficult enough to prevent most casual attacks.
FYI: the fast way of enumerating RSA keys is to make them asymmetric: one of the primes is chosen to be small. Thus, one trial implies one multiplication and one hashing (and a small prime sieve).
Your second assertion does not hold much water either. You're talking from the point of view of theoretical cryptography (where the goal is to make attacks computationally infeasible), whereas I am talking about practical security (where the goal is to make attacks economically unattractive). From your point of view, putting a lock on your front door doesn't make any sense, since affordable locks are easily picked and the door can be kicked down anyway. In reality, having a lock on your front door vastly increases your security, because it raises the costs sufficiently to keep casual attackers out. Sufficiently determined attackers will find their way in anyway. Yes, an 2^44 enumeration is within the range of a lone, unfunded attacker (albeit on the very far end of it), but he has better things to do with his resources than generating a key with the same ID as another random key for which he probably has no use whatsoever.
Thus, I hold on to my assessment of the security of 32 and 64 bit identifiers. I challenge you to generate a feasible-looking V4 PGP key with the same 32-bit ID as mine. It's 0x34F5BB91, as you can see from my user profile.
As for the second paragraph. There can be many additional security measures: the system can refuse to register keys with already taken 32-bit IDs, the system can provide facilities for verifying 64-bit IDs or even fingerprints, there can be some PKI-ish thing in place (WoT, CA hierarchy, whatever). And so on and so on.
Giggle all you want, but take look at the really successful security system. For instance, paper money. It has many security measures in place and it is up to the users to decide which ones are worth checking in every particular situation. Yes, there's some fraud in the system, but its overall security is sufficient to keep the economy afloat. The '90s ideal of unbreakable security for every joe (for free!) is just that: a pipe dream. It's time to get back to Earth.