AssemblyHashAlgorithm指定强命名程序集中用于计算清单哈希的加密算法，如SHA256，确保程序集的唯一性、完整性和防篡改，是CLR加载时验证身份和安全性的关键机制。
.NET中的
AssemblyHashAlgorithm枚举，简单来说，它指定了在创建强命名程序集时，用于计算程序集清单哈希值所采用的加密算法。这就像给你的程序集盖一个特定的“指纹”章，确保它的身份和完整性。这个指纹是强命名机制的核心组成部分，对于程序集的唯一性、版本管理和防篡改至关重要。
解决方案
当我们在.NET中对一个程序集进行强命名签名时，
AssemblyHashAlgorithm就登场了。它不是用来哈希你的实际代码二进制文件，而是针对程序集的元数据，特别是它的清单（manifest）。这个清单包含了程序集的所有关键信息，比如引用的其他程序集、导出的类型等等。选择一个合适的哈希算法（比如SHA256），系统会用它来计算这个清单的哈希值。接着，这个哈希值会用你强命名密钥对中的私钥进行加密，生成一个数字签名。
这个签名和公钥一起嵌入到程序集中。当CLR（Common Language Runtime）加载这个强命名程序集时，它会重新计算清单的哈希值，并用程序集中的公钥来解密签名，然后比较这两个哈希值。如果一致，就说明程序集是原始的，没有被篡改；如果不一致，那么程序集加载就会失败。这是一种非常有效的防篡改机制，也是为什么强命名程序集可以被放入全局程序集缓存（GAC）并被多个应用共享而不会冲突或被恶意替换的原因。可以说，它就是程序集信任链条上的一个关键环节。
强命名程序集为何需要AssemblyHashAlgorithm？
嗯，这个问题问得很好，毕竟不是所有程序集都需要强命名。但一旦你决定给程序集打上“强命名”的标签，
AssemblyHashAlgorithm就变得不可或缺了。这背后有几个深层的原因，不仅仅是为了一个形式。
首先，它提供了唯一性。理论上，两个不同内容的程序集，如果它们的强命名密钥相同，但没有哈希算法的参与，就可能导致冲突。而哈希算法生成的是一个“指纹”，即使内容只有微小的改动，这个指纹也会截然不同。这保证了在GAC这种共享环境中，每个强命名程序集都有一个全球唯一的标识符，避免了DLL Hell（DLL地狱）的困扰。
其次，也是更关键的，是防篡改。想想看，如果一个恶意用户拿到了你的程序集，修改了其中的代码，然后分发出去。如果没有强命名，或者强命名没有有效的哈希校验，那么你的用户可能就会运行一个被感染的版本。有了
AssemblyHashAlgorithm，每次加载程序集时，CLR都会重新计算其清单的哈希值，并与存储在签名中的原始哈希值进行比对。任何哪怕是单个字节的改动，都会导致哈希值不匹配，从而阻止程序集被加载。这就像给程序集贴了一个防伪标签，一旦被撕毁或伪造，就立刻失效。
最后，它支持了版本策略和安全策略。在企业级应用中，你可能需要确保某个特定版本的组件被使用，或者某个组件只能由特定的发布者提供。强命名结合了版本号、文化信息和公钥令牌，而公钥令牌正是从强命名密钥对派生出来的，其有效性又依赖于哈希算法的完整性。所以，这个算法的选择，间接影响了你整个应用的安全性和可维护性。我个人在处理一些遗留系统时，就遇到过因为哈希算法选择不当（比如还停留在MD5或SHA1）导致安全审计不过关的情况，那时候就得费劲去重新签名和部署。
AssemblyHashAlgorithm如何影响程序集加载与安全性？
这个影响其实是相当直接和深远的。当CLR尝试加载一个强命名程序集时，它会执行一系列的验证步骤，而
AssemblyHashAlgorithm的选择直接决定了其中一个核心环节的强度和可靠性。
具体来说，加载过程是这样的：CLR读取程序集中的公钥和数字签名。它会用程序集清单中指定的
AssemblyHashAlgorithm（比如SHA256）重新计算当前程序集清单的哈希值。同时，它会用公钥来解密数字签名，从而得到原始的哈希值。接着，这两个哈希值会进行比较。如果它们完全一致，那么CLR就认为这个程序集是完整的、未被篡改的，并且确实是由持有对应私钥的发布者签名的。程序集得以顺利加载并执行。
但如果哈希值不匹配呢？这就是安全性发挥作用的地方了。CLR会立即抛出一个
FileLoadException或
SecurityException，拒绝加载该程序集。这意味着，即使有人成功地替换了你的DLL文件，只要他们没有你的私钥重新签名，或者他们修改了文件内容导致哈希不符，你的应用程序就根本不会运行那个被篡改的版本。这有效地阻止了各种形式的DLL注入、恶意代码替换等攻击。
从性能角度看，不同的哈希算法在计算速度上会有差异，比如MD5通常比SHA256快，但这种差异对于程序集加载而言通常是微不足道的，因为哈希计算的对象是程序集清单，而不是整个巨大的二进制文件。更重要的是安全性上的考量。一个弱的哈希算法，比如MD5或SHA1，可能存在碰撞攻击的风险，这意味着攻击者有可能制造出两个不同的文件，但它们却拥有相同的哈希值。虽然在程序集签名的具体场景下，制造一个能通过强命名验证的恶意程序集非常困难，但理论上的风险依然存在。所以，选择一个足够健壮的哈希算法，是提升整体安全性的必要步骤。
AssemblyHashAlgorithm有哪些常用值，我该如何选择？
AssemblyHashAlgorithm枚举提供了一些选项，这些选项代表了不同强度和类型的哈希算法。理解它们并做出正确的选择，对于现代软件开发来说至关重要。
常用的值包括：
-
None
: 这个值表示不使用任何哈希算法。它通常用于非强命名程序集，或者在某些特殊情况下，你明确不希望有哈希计算。但对于强命名程序集，你基本不会看到它被显式使用，因为那会失去强命名的核心意义。 -
MD5
: 这是Message-Digest Algorithm 5的缩写。它曾经非常流行，但现在已经被认为是不安全的。MD5存在严重的碰撞漏洞，这意味着理论上可以找到两个不同的输入产生相同的MD5哈希值。因此，对于任何需要安全性的场景，强烈不推荐使用MD5。 -
SHA1
: Secure Hash Algorithm 1。比MD5更强，但在2017年，Google成功演示了针对SHA-1的实际碰撞攻击。所以，和MD5一样，SHA1也已被弃用，不应再用于新的强命名程序集。许多旧的.NET项目默认可能还是SHA1，这是需要注意并考虑升级的。 -
SHA256
: Secure Hash Algorithm 256。这是目前推荐使用的标准。它提供了足够的安全性，且在性能和安全性之间取得了很好的平衡。对于绝大多数强命名程序集，SHA256是最佳选择。 -
SHA384
: Secure Hash Algorithm 384。提供了比SHA256更高的安全性，哈希值更长，碰撞抵抗性更强。 -
SHA512
: Secure Hash Algorithm 512。与SHA384类似，提供了最高级别的安全性，哈希值也最长。
我该如何选择？
我的建议是：
-
对于所有新的强命名程序集，无脑选择
SHA256
。 它既安全又高效，是行业标准。 - 如果你有极其严格的安全要求，或者你的应用部署在对密码学算法有特殊规定的环境中，可以考虑
SHA384
或SHA512
。但在大多数情况下，它们提供的额外安全性对于程序集签名而言，可能带来的收益并不明显，而计算成本略有增加（虽然通常可以忽略不计）。 -
坚决避免使用
MD5
和SHA1
。 如果你的现有项目还在使用它们，强烈建议升级到SHA256
。这通常涉及到重新签名程序集，并可能需要更新引用它们的项目。这听起来有点麻烦，但从长远的安全角度来看，绝对值得。
选择合适的哈希算法，是确保你的.NET程序集在整个生命周期中保持完整性和可信度的重要一步。
