Geeks With Blogs
Ramesh Blog .NET Dash

Hashing is used to create a unique, compact value for a plaintext message. "Message" is a very broad term here; in terms of assemblies, the message is the assembly itself. The message is used as an input to the hash algorithm (in the case of strong naming, the SHA1 algorithm is used).

File.dll---->SHA1 Hash Algoritm---->Hash Value(SDFSDFJG2345ASDHFAS23)

Hashing is a one-way street: you can't decrypt the hash value once it has been computed. However, hashing is very useful for comparing values. If two assemblies produce the same hash value, you can assume that the assemblies are the same. Conversely, if hashing an assembly produces a value that doesn't match a previously-calculated hash, you know that something in the assembly has been changed.

Knowing the hash value for an assembly lets you check that no one has tampered with the assembly. But how do you prevent someone from tampering with the hash value? That's where digital signing comes in. While the mathematics of digital signatures are complex, the concept is fairly simple. A digital signature depends on a pair of related numbers, the public key and the private key. When data is encrypted with the public key, it can only be decrypted with the private key (and vice versa)

Strong Naming for Assembly IdentityThe combination of hashing and digital signing allows .NET to protect your assemblies from tampering. Here's how it works. First, a hash value is created from the assembly. Then, the hash value is encrypted with your private key and placed, along with your public key, in the assembly itself.

My.dll--->SHA1--->Assembly Hash--->Public Key--->My.dll+Digital Signature.

The CLR validates assemblies at runtime by comparing two sets of hash values. First, the public key is used to decrypt the encoded version of the hash. Second, a new hash is computed from the current contents of the assembly. If the two hashes match, all is well.

My.dll--->SHA1--->New Hash
My.dll+Digital Signature--->Public Key--->Original Hash

What happens if an assembly has been tampered with after it was signed? In this case, the new hash value calculated at runtime won't match the stored hash value that was encrypted with your private key. Under those circumstances, the CLR will refuse to load the assembly.

Note that the strong name guarantees the integrity of the assembly, not necessarily its safety! There's nothing to prevent someone from creating a malicious assembly and signing it with a strong name. You can use a strong name to verify that an assembly came from a particular source, and that it wasn't tampered with after it was signed. It's up to you to decide, based on whatever information you choose, whether to trust code from that source.

What's in a (Strong) Name?
In addition to a hash derived from the assembly's contents, the strong name includes three other pieces of information:

The simple text name of the assembly

The version number of the assembly

The culture code (if any) of the assembly

All of this information works together to supply a unique identity for each assembly. The CLR uses this information when deciding whether a particular assembly is the one called for by a reference from another assembly. When you set a reference from one assembly to another, the calling assembly stores a representation of the called assembly's public key. At runtime, the CLR can use this to check that the referenced assembly comes from the correct vendor.

O'Reilly Network: The Secrets of Strong Naming [Apr. 28, 2003]
Posted on Thursday, October 30, 2003 12:33 PM | Back to top

Comments on this post: Hashes and Signing

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Ramesh Arimilli | Powered by: