Diffie-Hellman 椭圆曲线私钥的长度

发布于 2024-11-30 18:09:39 字数 1346 浏览 1 评论 0原文

我使用 FIPS 186-3 推荐的 Diffie-Hellman 椭圆曲线曲线。我试图确定私钥的最大长度,根据 RFC 5915,它应该是:

上限 (log2(n)/8) ,其中 n 是曲线的阶数

对于 P-256 曲线,我得到最大长度32 对应于我在代码中看到的内容(假设是无符号表示)。然而,对于 P-521 曲线,我得到的最大长度为 65,但我在代码中得到的私钥长度为 66。以下是 P-521 曲线中的 66 字节私钥示例:

536779417579317602788996982811301460315734489420812664337904971338878196233844 6363455749219733919077469072043715066195336337088038146192289964998476049182286

十六进制:

01 90 59 2F 64 1C 73 AB F8 57 C4 F0 F2 A3 17 DD 5E 5F 64 B1 3C 61 15 8F E2 AC 34 DD 3F FC 6F 9B F1 38 9B 66 0F 27 34 60 75 E3 32 B0 B2 80 DF 9F 2A FE AC FF 82 BE 36 00 77 7A 92 B1 CB F7 7F 98 6E 4E

其公钥为(不带前导 0x04 字节):

01 F0 64 36 14 25 89 F8 7E 0D 5F 0E F9 26 36 D7 5C 4A 45 D7 9C 86 BD F8 C5 B9 A7 AA C4 C2 EB 56 52 DD BD BE E1 A0 5B DD A1 1F D8 79 D8 BA 2A 18 68 56 C0 D7 0A 4D D6 2B AB BD 8E D9 33 7F B1 FF E5 18 00 B2 06 21 D9 DA C1 BA A2 E7 43 69 06 FF 03 2F 05 FC 0E 44 74 A1 A3 3B 2E 7E B1 68 01 B2 7F B9 94 EB 8C C7 47 D7 02 A5 46 4E 88 32 59 DD 27 DE 72 C2 6D 8D B4 3B D0 45 67 31 AF 8E 1C 30 87 42 38 9F

有谁知道为什么可以获得66字节长度的私钥?根据 FIPS 186-3 文件,P-521 曲线的阶数为:

n = 686479766013060971498190079908139321726943530014330540939446345918554318339765 5394245057746333217197532963996371363321113864768612440380340372808892707005449

给出上限 (log2(n)/8) = 65。

问候, ——马丁·兰斯勒

I am using the FIPS 186-3 recommended curves for Diffie-Hellman Elliptic Curves. I'm trying to determine the max length of the private keys, according to RFC 5915 it should be:

ceiling (log2(n)/8) ,where n is the order of the curve

For the P-256 curve I get max length 32 which corresponds to what I'm seeing in my code (assuming an unsigned representation). However for the P-521 curve I get max length 65, however I am getting length 66 private keys in my code. Here is one example 66 bytes private key from the P-521 curve:

5367794175793176027889969828113014603157344894208126643379049713388781962338446363455749219733919077469072043715066195336337088038146192289964998476049182286

in hex:

01 90 59 2F 64 1C 73 AB F8 57 C4 F0 F2 A3 17 DD 5E 5F 64 B1 3C 61 15 8F E2 AC 34 DD 3F FC 6F 9B F1 38 9B 66 0F 27 34 60 75 E3 32 B0 B2 80 DF 9F 2A FE AC FF 82 BE 36 00 77 7A 92 B1 CB F7 7F 98 6E 4E

The public key for this was (without the leading 0x04 byte):

01 F0 64 36 14 25 89 F8 7E 0D 5F 0E F9 26 36 D7 5C 4A 45 D7 9C 86 BD F8 C5 B9 A7 AA C4 C2 EB 56 52 DD BD BE E1 A0 5B DD A1 1F D8 79 D8 BA 2A 18 68 56 C0 D7 0A 4D D6 2B AB BD 8E D9 33 7F B1 FF E5 18 00 B2 06 21 D9 DA C1 BA A2 E7 43 69 06 FF 03 2F 05 FC 0E 44 74 A1 A3 3B 2E 7E B1 68 01 B2 7F B9 94 EB 8C C7 47 D7 02 A5 46 4E 88 32 59 DD 27 DE 72 C2 6D 8D B4 3B D0 45 67 31 AF 8E 1C 30 87 42 38 9F

Does anybody know why it's possible to get 66 byte length private keys? According to the FIPS 186-3 document the order of the P-521 curve is:

n = 6864797660130609714981900799081393217269435300143305409394463459185543183397655394245057746333217197532963996371363321113864768612440380340372808892707005449

Which gives ceiling (log2(n)/8) = 65.

Regards,
-Martin Lansler

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

小镇女孩 2024-12-07 18:09:39

根据python(我可能以某种方式误用),log2(n)/8是65.125,所以它的上限是66。n

是521位长(正如我假设的那样) - 我通过打印出十六进制表示进行检查,该表示以“1”开头,有 131 个十六进制数字)。 521 / 8 为 65.125。

according to python (which i may be misusing in some way), log2(n)/8 is 65.125 so the ceiling of that is 66.

and n is 521 bits long (as i assume would be expected - i checked by printing out the hex representation, which starts with "1" and has 131 hex digits). and 521 / 8 is 65.125.

与风相奔跑 2024-12-07 18:09:39

谢谢安德鲁...这确实是我们的 log2 函数(标准 Java 中缺少)未正确实现,我们使用 BigInteger 而不是 BigDecimal,这会导致除法过程中的损失或精度。

正确的 log2 代码如下所示(偏离主题,但其他 Java 开发人员可能会感兴趣):

private static final double LOG_2 = Math.log(2);
private static final BigDecimal BI_1024 = new BigDecimal("1024");

public static double log2(double num) {
    return (Math.log(num) / LOG_2);
}

private static double log2(BigDecimal value) {
    if (value.compareTo(BI_1024) < 0) {
        return log2(value.doubleValue());
    }
    return 10 + log2(value.divide(BI_1024));
}

Thanks Andrew... It was indeed our log2 function (missing in standard Java) which was incorrectly implemented, we were using BigInteger instead of BigDecimal which causes loss or precision during division.

The correct log2 code looks like (off-topic, but could be of interest for other Java developers):

private static final double LOG_2 = Math.log(2);
private static final BigDecimal BI_1024 = new BigDecimal("1024");

public static double log2(double num) {
    return (Math.log(num) / LOG_2);
}

private static double log2(BigDecimal value) {
    if (value.compareTo(BI_1024) < 0) {
        return log2(value.doubleValue());
    }
    return 10 + log2(value.divide(BI_1024));
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文