-
Notifications
You must be signed in to change notification settings - Fork 34
/
ACVP Definition.txt
23 lines (21 loc) · 3.25 KB
/
ACVP Definition.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
This is the current definition for the ACVP-compatible method for deriving secrets.
The only question with ACVP (or any test vector) is how to make the crypto deterministic. Now, the RFC leaves a number of areas open; we need to fill in the gaps.
For any LMS tree, we have these potentially nondeterministic values:
- The I value
- The private values x[i] that are the start of each Winternitz chain; see Algorithm 0
- The randomizer value C that is in the header that is inserted in the initial message hash for each signature; see Algorithm 3
The RFC lists in Appendix A a method for generating the private values s[i] based on a SEED value (and the I value, the i value that indicates the WOTS digit the private value is for, and the j value that indicates the leaf in the LMS tree); we propose to extend that method:
- Every LMS tree will have a SEED and I value associated with it; this SEED will be m bits long (where m is the value specified by the LMS parameter set), and the I value will be 128 bits long.
- To generate the private x[i] values, we will use the algorithm in Appendix A
- To generate the randomized value C, we will adapt algorithm A, by using the SEED value of the LMS tree, the I value of the LMS tree, the q value to be the LMS index, and the i value to be 65533
- To generate the SEED value for a child LMS tree, we will adapt algorithm A by using the SEED value of the parent LMS tree, the I value of the parent LMS tree, the q value to be the LMS index of the child, and the i value to be 65534 (and the SEED being the SEED of the parent LMS tree).
- To generate the I value for a child LMS tree, we will adapt algorithm A by using the SEED value of the parent LMS tree, the I value of the parent LMS tree, the q value to be the LMS index of the child, and the i value to be 65535 (and the SEED being the SEED of the parent LMS tree); the I value will be the first 128 bits of the hash.
The ACVP server will specify the SEED and I for the root (top-most) LMS tree; the SEED and I values for all child LMS trees are derived as above.
Rules about handling varying length SEEDs (based on differing hash functions):
- A SEED for an LMS tree will always be m bits long; where m is specified by the LMS parameter set.
- The ACVP server MUST specify the correct length for the root SEED (and the client will error out if incorrect)
- If the SEED generated by a parent LMS tree isn’t the correct length for the child then:
o If it is too long, then it will be truncated to m bits
o If it is too short, then it will have 0 bits appended to make it m bits
(Hmmmm, would it more sense to just ignore the ‘all seeds must be precisely m bits long’ rule (as stated in Appendix A), and just allow variable length seeds??? The only issue I can think of is that the current code can’t handle a variable-length top-level seed (but that could be fixed). It might make sense to keep the ‘the ACVP seed must be m bits long’ rule (if someone was paranoid enough to use SHA-512, then they might not be happy with 256 bits root seeds), but be flexible elsewhere…
The ACVP server will specify a SEED and I which will be used to seed the entire process. Note that, if the SEED value isn’t the same length as the hash size indicated by the root LMS hash parameter set, the request will be rejected.