Asymmetric Cryptography, Public keys and Strongly-named assemblies

Chronicles of .NET runtime - Part 5

Hi there! 👋

This is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you missed the previous article on Weakly and Strongly-named assemblies, I’d recommend checking that one first. If you haven’t seen any of the past articles - I’d recommend you start from beginning. Finally, if you’re here just for asymmetric cryptography - enjoy :)

Last time I mentioned that Strongly-named assemblies are ones that are digitally signed by the owner. I also promised to share more details on what that means at all. And this is what I want to do now :)

As usual - infographic goes first and more details below:

I hope that wasn’t too much to digest? If it is - please let me know and I’ll do more graphics to break this down even further.

The thing with asymmetric cryptography is that it might look spooky and confusing at first. And it most certainly felt so for me when I encountered it for the first time, some 5-6 years ago. But just like everything else - it’s REALLY simple. And I’ll make sure to explain it properly.

Let’s first start with symmetric cryptography. In symmetric crypto, what you have is ONE key (think of it as a password if you want) that can both LOCK and UNLOCK the data. It’s literally like a physical key - you can put the data into a box, lock it and whoever wants to unlock that box would need to have the exact same key. This also means that if your key gets stolen you’d have to change the whole lock. Some of the popular symmetric crypto algorithms are AES, DES, 3DES, etc. (do note that DES is now deemed insecure).

Generally speaking, symmetric cryptography and symmetric ciphers are great and really fast, but the problem is the distribution of the key. In order to use encrypted communication, you would first have to exchange the key with the party you are trying to talk to, but how do you do that over an insecure network, like Internet? Hint: you don’t.

This is something that Asymmetric Cryptography aims to solve. Instead of having ONE key that you’d have to exchange, somebody came up with an awesome idea - why not have TWO keys? They’d work in pairs (i.e. one wouldn’t make sense without the other) but one would have to be kept Private and another one should be publicly shared (e.g. you can put it in your email signature). They were named Private and Public keys respectively.

So the way it works is really simple. Think of it as having a lock that can be locked with ANY of the two (either private or public key) but in order to be unlocked - the OTHER key has to be used; using the same key to unlock wouldn’t work. And if you think that’s impossible - I have some good news for you - it most certainly is!

Let’s say you have two parties that want to communicate - Joe and Maria. Furthermore, they want to ensure that their communication is secure. How do they do that?

Simple! If Joe wants to talk to Maria, he’d just ask her for her public key. Given that the whole purpose of it is to be public, Maria can freely send it to anyone, including Joe. Now that Joe has Maria’s public key, he uses it to encrypt the message that he wants to send. And here’s the interesting thing — once you lock the message with Public key, the only way to unlock it is by using, you guessed it - the Private Key! So Joe is free to send the encrypted message over Internet because nobody except Maria will be able to decrypt it! It’s just beautiful! And if Maria were to contact the Joe, she’d take his Public key, encrypt the message and send it over insecure network.

Now the real beauty of this all happens once you reverse the process. Imagine you have a piece of information that can be unlocked with somebody’s Public key. What does that tell you? It tells you that whoever encrypted it - has the Private key :) Meaning that the only person who could have created and encrypted that is the owner of the Private Key. So this effectively means that by encrypting anything with your Private key is a very simple way of claiming ownership and identity.

For example, if I wanted to claim that email was sent by myself, and if I were to give you a way to confirm that, what I’d do is write an email, encrypt it with my private key and publish it on internet. Anyone can now take my public key, decrypt the email and confirm that, indeed, it was made by myself, because no one else has my Private key.

This exact process is how Digital Signatures work. What you do is you create something (e.g. a DLL file), and then you encrypt piece of it (usually the hash value of the file’s content) and store it alongside the DLL. You also want to pack your public key so that anyone can confirm the ownership, but it’d be totally valid as well to ask them to find your public key on a reputable source (e.g. your Website) and use that to confirm the ownership.

Consumers of your DLL can then calculate the hash value of that same file, and then use your public key to decrypt your signature and compare the two. If the current hash version matches the one that you digitally signed - file is genuine. If there’s a mismatch - file is not genuine.

And that’s really about it :) As I said - it’s really simple and I think it’s just beautiful; honestly. And hopefully it wraps up the story on why Strong-named assemblies contain the public key alongside them.

Anyway, in future articles I’ll slowly move my focus from assemblies towards Stacks and Heaps in .NET and CLR, with a special focus on Boxing & Unboxing. And if you havent’t subscribed already, now might be a good time to do so :)

Thanks for reading!

---

Other articles from the CLR series:

• What is Common Language Runtime (CLR) and why should I learn about it?

• What is a .NET assembly?

• What is Assembly's Manifest?

• Weakly and Strongly-named Assemblies