.NET核心程序集中非常特殊的PublicKey
我注意到核心.NET程序集有PublicKey = 00000000000000000400000000000000。它不仅比那些sn.exe允许生成的短（最少384位），而且还有很多零。
如何用如此奇特的公钥生成签名密钥？
I've noticed that core .NET assemblies have PublicKey = 00000000000000000400000000000000. Not only it's shorter then those sn.exe allows to generate (min 384 bits) but also it has a lot of zeros.
How to generate signing key with such a fancy public key?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是 ECMA 标准定义的公钥。
它是为了处理三个相互冲突的要求：
这三件事不能同时发生！
如果我创建一个.NET版本（第2点），那么我需要提供一个标准库版本（第3点），它需要被信任（第1点），所以我需要对其进行签名以证明我'我是微软。哦等等，我不是微软！ （呃，又是第2点）。
相反，发生的情况是：
我创建了一个公钥-私钥对。受信任在我的框架库实现中构建程序集的新发布版本的人员可以访问私钥，在 CLI 实现上执行任何工作的任何人都可以知道公钥。
我将相关程序集标记为已使用与公钥
00000000000000000400000000000000（在ECMA标准中定义）相对应的密钥进行签名，尽管它们实际上是使用上述私钥进行签名的。在 CLI 中的代码中，对声称已使用与公钥
00000000000000000400000000000000对应的密钥进行签名的程序集的任何检查都会使用真实的公钥进行检查。如果检查通过，则它只能由我们信任的构建这些程序集的人签名。当然，MS 的框架不会信任我们的程序集，Mono 的框架不会信任它们，我们也不会信任他们中的任何一个，因为我们都有与 ECMA 标准密钥相对应的不同真实密钥。这是应该的。
同时，
00000000000000000400000000000000与任何真正有效的公钥不匹配的事实意味着它不可能与任何其他公钥发生冲突。That's the ECMA Standard defined public key.
It's to deal with three conflicting requirements:
These three things can't happen at the same time!
If I create a version of .NET (point 2), then I need to provide a version of the standard library (point 3), which needs to be trusted (point 1), so I need to sign it to prove that I'm Microsoft. Oh wait, I'm not Microsoft! (eh, point 2 again).
Instead what happens is:
I create a public-private key pair. People trusted to build new release versions of the assemblies in my framework library implementation have access to the private key, the public key can be known to anyone doing any work on the CLI implementation.
I mark the relevant assemblies as having been signed with the key corresponding to the public key
00000000000000000400000000000000(defined in the ECMA standard), though really they were signed with the private key mentioned above.In the code in the CLI any check on an assembly that claims to have been signed with the key corresponding to the public key
00000000000000000400000000000000is checked with the real public key. If this checks out, then it can only have been signed by someone we trust in building those assemblies.Of course, MS's framework won't trust our assemblies, Mono's won't trust them, and we won't trust either of theirs, because we all have different real keys corresponding to the ECMA standard key. Which is as it should be.
Meanwhile, the fact that
00000000000000000400000000000000doesn't match any real valid public key means it's not possible for it to clash with any other public key.这不是问题的正确答案。这个答案提供的唯一内容是指向 ECMA 标准的指针，显然是带有 CLI 规范的 ECMA-335。但这个 ECMA 标准仅提供了唯一/固定值及其名称的基本定义。否则，它不会提供有关如何以及在何处找到实际公钥的任何信息。值 00000000000000000400000000000000 不是公钥，它只是一个称为标准公钥的标记，与真正的公钥无关。该值用于计算使用它的程序集的公钥令牌，但在处理程序集签名时，该值不用作 RSA 算法的任何公钥。您需要一个真正的公钥。这个问题的正确答案应该是如何以及在哪里找到使用它的程序集的实际公钥
This is NOT the proper answer to the question. The only thing this answer provides is the pointer to ECMA standard, apparently ECMA-335 with CLI specs. But this ECMA standard provides only a basic definition in terms of unique/fixed value and the name it should be called. Otherwise, it provides nothing about how and where the actual public key is found. The value 00000000000000000400000000000000 is NOT a public key, it is only a marker called Standard Public Key which has nothing to do with a real public key. This value is used to compute Public Key Token for the assembly that uses it but this value is not used to as any public key of RSA algorithm when processing the assembly signature. You need a real Public Key. The proper answer to the question should be how and where the actual Public Key is found for the assembly that uses it