[opentitantool] SPHINCSPLUS refactoring #23730
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
TODO:
|
jadephilipoom
approved these changes
Jun 21, 2024
f960793 to
b2604bc
Compare
|
I've added domain handling to the I've also rewritten the headers on the existing PEM files to identify the keys as Passing CI is an effective test with the ROM. I've also tested with the HSM, although in order to do that, I need to change the version of the reference implementation we import to the ref-impl's |
915bad0 to
4b8343c
Compare
timothytrippel
approved these changes
Jun 27, 2024
jadephilipoom
approved these changes
Jun 27, 2024
0a03c48 to
e40555e
Compare
Signed-off-by: Chris Frantz <cfrantz@google.com>
Rework the sphincsplus build to permit linking in multiple algorithm variants without C symbol clashes. 1. Patch the sphincsplus C library to allow namespacing the relevant symbol names. Since C does not have namespaces, we use the C preprocessor to token-paste a prefix onto the symbols. 2. Supply the namespace prefix in the `cc_library` build rules. Signed-off-by: Chris Frantz <cfrantz@google.com>
1. Refactor the low-level interface into a macro that can access the low-level C functions for each algorithm variant we want to support. 2. Refactor key types to carry the algorithm variant along with the key material. 3. Save the algorithm name into the PEM files used for saving key material to disk. Prefix the name with `RAW:` to convey that the PEM files are just raw bags of bytes with no internal structure. Signed-off-by: Chris Frantz <cfrantz@google.com>
… crate Signed-off-by: Chris Frantz <cfrantz@google.com>
Rewrite the SPX PEM key labels to identify the Sphincs+ algorithm variant for the keys. Signed-off-by: Chris Frantz <cfrantz@google.com>
|
The CI test failure is not related to this change. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor the SPHINCSPLUS library to support multiple algorithm variants.
cc_libraryandrust_bindgenrules through thedefinesorclang_flagsattributes of those rules.2a. Create an enum whose discriminants are the sphincsplus algorithm names. Create a
macro_rules!macro that can expand an implementation for each discriminant that invokes the corresponding per-algorithm functions supplied by (1).2b. Create
Spx{Public,Secret}Keystructs to hold key material and their associated algorithm names. Create nice associated functions on these key types that provide nice interfaces to the lower-level functions supplied by (2a).2c. Add
{Encode,Decode}Keytraits that can serialize the key material to/from PEM files. Save the algorithm name into the PEM file so that when keys are loaded from files, they key material will get associated with the correct implementation functions.spxmodule in favor of using the newsphincspluscrate directly.