Unterschiede zur Python/Bitbucket-Implementierung

[Chratho]

Hi,

da die Readme auf Deutsch ist halte ich es hier auch mal auf Deutsch.

Mir sind gegenüber [1] einige Unterschiede in der Implementierung aufgefallen und ich würde diese gern auf kurzem Wege kommunizieren:

1. Offenbar werden in der CBOR-Serialisierung indefinite length maps verwendet [2] - statt finite maps wie in [1]. Ist dies eine bewusste Entscheidung gewesen, d.h. die Verwendung ist hier offen und im Parsing müssen client- und server-seitig einfach beide Formate unterstützt werden?
2. Der Wert von Kyber768_PK in M1 hat hier eine Länge von 1208 bytes gegenüber 1184 bytes in [1]. Das ist denke ich eine klare Inkompatibilität. Gemäß [3] sollten 1184 bytes richtig sein. Möglicherweise resultieren die zusätzlichen 24 bytes aus irgendeinem ASN1-Overhead.

Weiter konnte ich bislang nicht analysieren. Was die Kyber-Implementierung angeht habe ich den Code nur mal überflogen, hierzu eine Frage

3. Ist Kyber hier wirklich wie unter [1] gemäß der Round 3 Submission umgesetzt? Da das reines BC ist und ich keinen weiteren refinement-Code entdecken konnte befürchte ich fast NIST FIPS 203, was wieder inkompatibel mit [1] wäre.

Liebe Grüße

[1] https://bitbucket.org/andreas_hallof/vau-protokoll/src/master/minimal/
[2] https://datatracker.ietf.org/doc/html/rfc8949#section-3.2.2
[3] https://pq-crystals.org/kyber/

[Arkinator]

Vielen dank für die Anmerkung. Ein paar (nicht normative :) ) Anmerkungen:

1: Das ist uns intern auch schon aufgefallen. Da es in der Spezifikation keine festlegung hinsichtlich einer Variante gibt sollten sowohl Server als auch Client mit beiden Varianten umgehen können. Die, bei Ihnen wahrscheinlich auch, aufgefallenen Unterschiede in den Nachrichten sind zwar vorhanden blockieren aber die Funktion nicht. Daher: passt so.
2: Ebenfalls auch in internen Reviews aufgetaucht. Der Fix ist im internen Repo schon eingebaut aber noch nicht ausgerollt. Die Vermutung mit dem ASN.1 Overhead kommt genau hin. Danke für den Hinweis.
3: Hier sehen wir leider ein Delta. Ich bin noch nicht tief in der Materie eingearbeitet, werde das aber nachholen und einen Fix bereit stellen. Ebenfalls vielen Dank für den Hinweis.

[fnoGematik]

Hallo @Chratho,

du hast den Unterschied zwischen der aktuellen BC Implementierung (wie wir sie momentan verwenden) und der letzten veröffentlichten Version von Kyber (3.0.2) schon angemerkt.

bcgit/bc-java#1578 (comment)

Im letzten Kommentar hast Du geschrieben, dass Du eine erfolgreiche Anpassung geschafft hast.
Wäre es möglich, dass Du diese Anpassung mit uns teilen könntest? Dann können wir diese auch ggf. übernehmen bzw. gegenprüfen.

[Chratho]

Hi,

ja, gern. Aus meiner Sicht:

1. Berechnung des Shared Secrets mit BC (wie geschehen).
2. Auf Kyber768_ct wird ein SHA3-256-Digest berechnet.
3. Verknüpfung der Bytearrays aus 1. und 2.
4. Für das Bytearray aus 3. wird nun mittels SHAKE-256 ein neuer 32 byte langer Hash berechnet.

Das Ergebnis aus 4. sollte dann mit dem Round 3 Ergebnis ident sein. Im zitierten Thread findet sich auch ein Unit-Test mit dem man das Ergebnis validieren kann.

lg, Christian

[fnoGematik]

Hallo @Chratho,

wir haben gerade eine neue Version der lib-vau released. Damit sollte der Unterschied zwischen Python & Java in den Punkten 2. & 3. aus der ursprünglichen Frage behoben sein.

Siehe Release Notes

[Chratho]

Hi,

vielen Dank für die schnellen Änderungen!

Ich habe meine Analyse jetzt fortgesetzt und bin nun noch auf einen letzten Punkt gestoßen:

In A_24608 heißt es bzgl. des Ergebnisses der HKDF: Die ersten 32 Byte (=256 Bit) heißen K1_c2s und die letzten 32 Byte heißen K1_s2c. Bei der Erzeugung von KdfKey1 scheint diese Reihenfolge aber vertauscht.

Liebe Grüße

[Arkinator]

Auch das kann ich bestätigen. Den Bug scheint es auch schon in der Python-Implementierung zu geben, nächstes Release kommt bald. Danke für den Hinweis.

[fnoGematik]

Vielen Dank für das weitere Finding @Chratho!!!
Wir haben gerade ein neues Release 1.0.9 mit dem Fix bereit gestellt.

Btw.: Beim nächsten Finding gern ein neues Issue aufmachen. Dann bekomme ich das eher mit 👍 .

[Chratho]

Hi,

das sollte es hoffentlich schon gewesen sein!

Fraglich bleibt für mich nur mehr der Punkt bzgl. der CBOR-Serialisierung von Maps. Ich denke zumindest hinsichtlich der Server-Responses wäre es möglicherweise vorteilhaft eine Darstellungsform vorzugeben - einfach weil ich nun doch schon manche CBOR-Library gesehen habe die nur eine Darstellung unterstützt, was potentiell dazu führen kann dass Interoperabilitätsprobleme am Client erst sehr spät entdeckt würden. Aber das muss anderweitig diskutiert werden.

Danke und liebe Grüße