Add XMSS parameters #186
Open
Add XMSS parameters #186
Conversation
This file contains 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
The practical use case for WOTS+ is as a component of other protocols. These are typically implemented generically over WOTS+, and then instantiated with a joint set of parameters for WOTS+ and the parent scheme. This means that just instantiating WOTS+ with the approved parameter sets isn't suitable, since we want to define other protocols based on the generic specification. This commit adds an interface that defines the parameters (n, w, F, PRF) and the public API (genPK, sign, pkFromSig) for WOTS+. This way, we can define other protocols based on the interface and instantiate them with the approved WOTS parameter sets. I duplicated most of the docs.
- Defines a `Parameter` interface with the parameter definitions defined in the RFC, plus some additional types needed to compile things. - Defines a `Specification` that pulls together the parameters defined for WOTS+ and XMSS. - Instantiates one XMSS parameter set and the corresponding XMSS instantiation (e.g. in combination with the appropriate WOTS+ parameter set) to make sure everything builds.
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.
Addresses part of #175 but doesn't complete it. This ended up being a lot of infrastructure, so I'm going to break it into a separate PR.
This PR moves the WOTS+ scheme to its own directory (since it will be used in SPHINCS+ as well). The spec defines parameters for WOTS (
n,w, F, andPRF), which have various constraints and also some dependent WOTS-specific types (len`) that have their own constraints.My original plan was to have the XMSS spec take all the parameters for both XMSS and WOTS+, and then pass some of them through to instantiate WOTS+. However, I would've had to duplicate all of the WOTS-specific constraints in XMSS, which felt inelegant.
Then I was hoping to make an anonymous interface for the XMSS parameters (e.g. just a
parameterblock like most protocols have) and import the WOTS+ interface. This would match the spec, since SP 800-208 defines the WOTS+ parameter sets separately (Section 5.0) from the XMSS parameter sets (the rest of Section 5). The spec compiled with this but I couldn't figure out how to instantiate it -- cryptol#1581 suggests that this might not be possible.However, we can definitely import multiple interfaces to a single spec -- there's a section in the refman about it. So I moved the XMSS parameters to their own interface and imported it. It's pretty simple; it did require a few extra constraints that come out of the hash functions (and aren't really specified in the NIST spec, but some hash functions have message length upper bounds). Then I instantiated the XMSS parameter sets, and imported those parameters into the XMSS instantiation.
Open to feedback on a simpler way to do this, if there are any suggestions.
TODO