> > 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?
Yeah, Keith Brown and I were exploring down that road. And the question we came up with was, "Do they really have to be a valid key pair, or could I choose some other pair of numbers that has the right set of properties but doesn't provide the same strength of encryption that a proper key pair does?" In other words, "Can I cheat when generating fake pairs?" And the unfortunate thing was that neither Keith nor I have the math (maths for you, Ian ;) to know what the real story is. Maybe someone else does? So it might be the case that it's a factor X more expensive than just calculating 2^63 hashes, but it might not. I don't know for sure. And without argument, it would have been more secure for them to record the whole public key, rather than the public key token. I don't buy the argument that they were saving space - 1024 bits versus 64 is not a huge amount of data. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
