Closed johngray-dev closed 8 months ago
Hi @johngray-dev, @ounsworth , @opencrypto
I finished the review and have some minor comments. If you agree I can gladly change them myself:
line 126: shall we still mention {{I-D.ounsworth-pq-composite-keys}}? I think we can remove this section already since we define structures for public and private keys now...
line 166: I want to add a third point:
- Safeguard against faulty algorithm implementations and compromised keys: Even for long known algorithms there is a non-negligible risk of severe implementation faults. Latest examples are the ROCA attack and ECDSA psychic signatures. Using more than one algorithms will also mitigate these risks.
line 318: here we say generation must fail on recursive composites, but the pseudo code does not include a check step like in the verification. Shall I add one for sake of uniformity?
line 320: I think this sentence has duplicate sections, I commited a fixed version.
Here is the pull request with the updates for composite signatures:
Changes affecting interoperability:
Editorial changes:
Made this document standalone by folding in the minimum necessary content from composite-keys
Added a paragraph describing how to reconstitute component SPKIs.
Added a section showing the HEX encoding of the String Algorithm Names
Added a section on pre-hashing
Rename Dilithium to ML-DSA and Falcon to FN-DSA
Added an Implementation Consideration about FIPS validation where only one component algorithm is FIPS-approved.
TODO Refactored to use MartinThomson github template
TODO Worked on Use cases references
TODO Add Section on Signature APIs (Keygen, Sign, Verify) in introduction