Länge des privaten Diffie-Hellman-Schlüssels mit elliptischer Kurve

Question

Ich verwende die von FIPS 186-3 empfohlenen Kurven für elliptische Diffie-Hellman-Kurven. Ich versuche, die maximale Länge der privaten Schlüssel zu bestimmen, die laut RFC 5915 sein sollte:

Obergrenze (log2(n)/8), wobei n die Ordnung der Kurve ist

Für die P-256-Kurve erhalte ich die maximale Länge 32, was dem entspricht, was ich in meinem Code sehe (unter der Annahme einer Darstellung ohne Vorzeichen). Für die P-521-Kurve erhalte ich jedoch eine maximale Länge von 65. In meinem Code erhalte ich jedoch private Schlüssel der Länge 66. Hier ist ein Beispiel für einen 66 Bytes langen privaten Schlüssel aus der P-521-Kurve:

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

Der öffentliche Schlüssel dafür war (ohne das führende 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

Weiß jemand, warum es möglich ist, private Schlüssel mit einer Länge von 66 Byte zu erhalten? Laut dem FIPS 186-3 Dokument ist die Reihenfolge der P-521 Kurve:

n = 6864797660130609714981900799081393217269435300143305409394463459185543183397655394245057746333217197532963996371363321113864768612440380340372808892707005449

Das ergibt eine Obergrenze von (log2(n)/8) = 65.

Grüß Gott, -Martin Lansler

Answer 1

Laut Python (das ich vielleicht in irgendeiner Weise falsch verwende) ist log2(n)/8 65,125, so dass die Decke davon ist 66.

und n ist 521 Bits lang (wie ich annehme, dass man das erwarten würde - ich habe das überprüft, indem ich die Hex-Darstellung ausgedruckt habe, die mit "1" beginnt und 131 Hex-Ziffern hat). und 521 / 8 ist 65,125.

Answer 2

Danke Andrew... Es war in der Tat unsere log2-Funktion (die in Standard-Java fehlt), die falsch implementiert war. Wir haben BigInteger statt BigDecimal verwendet, was zu einem Verlust an Genauigkeit bei der Division führt.

Der korrekte log2-Code sieht wie folgt aus (Off-Topic, könnte aber für andere Java-Entwickler von Interesse sein):

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));
}