Craig Andera wrote: > There is an additional weakness in this scheme. Because > most compilers don't actually record the public key in the > client, but rather a 64-bit hash of the public key (the public > key token). Which is hard to attack with brute-force, but > (I believe) not impossible. I expect someone has already > launched just such an attack against the MSFT and > ECMA public keys, so they can find other public > keys that hash to the same token. It may take a few > years, but if it's less than five, that's still a problem.
Actually if they find other public keys that hash to the same problem that's not really a big problem - they still don't have a private key that will match... So the brute force attack would, strictly speaking, be to generate public/private key pairs until you came up with one where the public key hashed to the correct value. > I think the problem comes down to calculating the SHA-160 > hash of 2^63 (on average) public keys. Someone else might > know how much CPU that would take. Presumably it's not > prohibitively expensive, since MSFT makes the CLR do it > once every time it loads a signed assembly. But you also have to generate that many key *pairs*. And MSFT don't generate a key pair every time you load an assembly. Isn't generating key pairs significantly more expensive than generating 160 bit numbers? -- Ian Griffiths DevelopMentor You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
