ECDiffieHellmanCng PublicKey总是一样吗？ [英] ECDiffieHellmanCng PublicKey always the same?

问题描述

我正在玩C＃ECDiffieHellmanCng类，并使用样本：
任何项目中生成的每个公钥都一样！

I'm playing around with the C# ECDiffieHellmanCng class and found a (in my opinion strange) behavior using the code from the sample: Every generated public key in any project ist the same! Is this correct and a desired behavior?

示例：

using (ECDiffieHellmanCng bob = new ECDiffieHellmanCng())
            {
                bob.KeyDerivationFunction = ECDiffieHellmanKeyDerivationFunction.Hash;
                bob.HashAlgorithm = CngAlgorithm.Sha256;
                Trace.WriteLine(Encoding.UTF8.GetString(bob.PublicKey.ToByteArray()));
            }

跟踪将始终以 ECK5B作为输出。使用不同的构造函数只会使输出有所不同，而不会导致输出始终相同。
我是否会误解某些内容，并且此结果符合预期，并且没有机会提供随机的公共密钥？
我只是认为系统会使用更多的随机性。

The trace will always have "ECK5B" as output. Using a different constructor will only differ the output a bit but not the fact, that it is always the same. Do I missunderstand something and this result is as expected and there is no chance to provide a random public key? I just thought the system would use some more randomness.

推荐答案

ToByteArray（） 方法，返回（特定于Windows的）描述密钥的CNG Blob 。

The ToByteArray() method, returns the (Windows-specific) CNG blob describing the key.

Blob布局为

UINT32 Magic
UINT32 cbKey
<cbKey bytes of public key>

BCRYPT_ECDH_PUBLIC_P521_MAGIC 的值是 0x354B4345 ，如果以Little-Endian顺序（ 45 43 4B 35 ）查看，则是ASCII字符串 ECK5 。 NIST P-521曲线上的点的 x 坐标最多需要521位，即（（（521 + 7）/ 8）== 66字节。 Little-Endian中的（UINT32）66 是 42 00 00 00 。因此，所有字节数组（对于基于NIST P-521的公钥）都将以

the value for BCRYPT_ECDH_PUBLIC_P521_MAGIC is 0x354B4345, which if viewed in Little-Endian order (45 43 4B 35) is the ASCII string ECK5. The x coordinate of a point on the NIST P-521 curve needs up to 521 bits, or ((521+7)/8) == 66 bytes. (UINT32)66 in Little-Endian is 42 00 00 00. So all of the byte arrays (for a NIST P-521-based public key) will start with

45 43 4B 35 42 00 00 00

（然后还有66个字节的ECPoint X字节）。由于ASCII字符串在读取第一个 0x00 时将终止，因此它将（作为字符串）解释为 ECK5B 。

(and then have 66 more bytes of the X component of the ECPoint). Since the ASCII string will terminate when it reads the first 0x00, this gets interpreted (as a string) as ECK5B.

您已经发现，该值实际上不是字符串，因此，要将该值视为一个字符串，必须将其编码为字符串安全格式，例如hex或Base64。由于十六进制是1 => 2编码（或1 =>〜3带空格），而Base64是3 => 4编码，因此大多数应用程序最终都使用Base64。

As you've already discovered, this value isn't actually a string, so in order to be treated as one it needs to be encoded to a string-safe format, such as hex or Base64. Since hex is a 1=>2 encoding (or 1=>~3 with spaces) and Base64 is a 3=>4 encoding, most applications end up using Base64.

这篇关于ECDiffieHellmanCng PublicKey总是一样吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！