What is the role of public key token?

I would like to add to the previous answers (especially to the one with the quote from Wikipedia) that the strong naming via public/private key doesn't protect you from getting a changed assembly or prevent someone from tampering with your assemblies.

First of all, strong name doesn't guarantee that assembly can be trusted. You just have a public key/public key token, but you don't know the person who signed it (except if they somehow announce that they own the assemblies public key).

For example, the hacker could take yours assembly, remove strong name from it (there are tools which do it), and sign it with its own strong name. For the trust there is a different kind of digital code signing with the certificate. It involves third party checking you and your company and is not free. Check out Authenticode technology:

https://msdn.microsoft.com/en-us/library/ms537359(v=vs.85).aspx

Secondly, In the following discussion briefly described a brute force attack method to get public/private key pair with the same public key token which would produce the same hash for a tampered assembly:

https://groups.google.com/forum/?hl=en#!topic/microsoft.public.dotnet.security/Jo6PqypxJN8

I must note that this could have been addressed by the enhanced strong naming https://docs.microsoft.com/en-us/dotnet/framework/app-domains/enhanced-strong-naming

There were also a bug mentioned in the discussion which allowed to skip the validation of assembly and load a tampered assembly at runtime. The detailed research is here, the bug was fixed in the later versions of .Net framework(so the bug present for the old .Net 1):

http://www.grimes.nildram.co.uk/workshops/fusionWSCrackThree.htm

Thirdly, starting the .Net 3.5 sp1 to increase the performance of the load of the assemblies are not validated by default for full trust assemblies.

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature

The condition for assemblies: https://blogs.msdn.microsoft.com/shawnfa/2008/05/14/strong-name-bypass/

The discussion about it on Stack Overflow: Are signed .net assemblies ever fully verified when loaded, to check they haven't been modified?

As I understand, this means that assembly is not hashed during load to check if it

Lastly, I would like to mention that there is a debate about pros and cons of strong naming since they require that you specify an assembly version. Microsoft removes strong name from some of their products: https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/

In conclusion, I wanted to summarize all of the mentioned points. When I encountered strong naming I was misguided by the MSDN and Wikipedia that it could provide some sort of defense for the assemblies. I thought "Cool" and the strong naming remained in my memory as a protection mechanism. Until the moment I had to think about the safety of my snk file with private key and then my colleague told me that it's not so "Cool". So I did a little research. The first thing I learned was that strong name doesn't mean trust, you should use the certificate for it. Still, I thought that if I keep my private key safe then the tampered assembly won't be signed by me, meaning that if someone will modify my assembly then he has to modify the sign too and the modified assembly won't be loaded by the CLR. Now I don't think that strong naming guarantees that. So you should rely on it only to guarantee the uniqueness of the assembly.

PS. Sorry for the long post with a lot of references.