Conversation
TJ-91
force-pushed
the
xmssmt-dev
branch
11 times, most recently
from
46d0701 to
4cbc0b8
Compare
TJ-91
force-pushed
the
xmssmt-dev
branch
2 times, most recently
from
8769160 to
f2bba6c
Compare
|
@randombit @reneme I removed the draft status and welcome any feedback |
No I think this should be a specific length, probably |
|
Sorry about all the merge conflicts btw, this recent work was unplanned, the issue of errors on concurrent usage was only recently brought to my attention and that's what is driving the XMSS patches. |
|
|
||
| // The public part of the input key bits was already parsed, so we can | ||
| // decide depending on the buffer length whether this must be BER decoded. | ||
| if(key_bits.size() == xmssmt_params.raw_private_key_size()) { |
There was a problem hiding this comment.
The fallback decoding is not needed, since there are no previous XMSS^MT private keys.
There was a problem hiding this comment.
true, it's the same for the public keys but I will then need to encode the test vectors accordingly.
| } | ||
|
|
||
| // fall back to raw decoding | ||
| // TODO: in contrast to XMSS there are no old versions to support, however, the test vectors are decoded as raw keys (no octet string) |
There was a problem hiding this comment.
Yes, there should be no fallback decoding for XMSS^MT in my view.
|
|
||
| #include <botan/internal/xmss_core.h> | ||
| #include <botan/internal/xmss_tools.h> | ||
| #include <array> |
There was a problem hiding this comment.
Not needed acc. to clang-tidy.
There was a problem hiding this comment.
Does this refer to #include <array>? I think without it some Windows CI fails
XMSS^MT: implement pubkey and verify XMSS^MT: implement keygen and sign XMSS^MT: refactor common XMSS and XMSS^MT code adjust for leaf idx >32 bit in the index registry add test vector files to git clang tidy XMSS^MT: add some tests and documentation various small fixes Remove XMSS^MT private key shared mutable state (see randombit#5366), disabled for now (see randombit#5369)
4 participants
This implements XMSS^MT as a separate module which re-uses internal XMSS functionality.
I refactored and extended XMSS as far as is needed to not re-implement any XMSS functionality. I moved some core XMSS algorithms like tree_hash to
xmss_core.cppand made it independent of XMSS keys and instead pass the required data.Some noteworthy changes:
uint64_tas leaf index since XMSS^MT has larger trees (up to a total height of 60). XMSS^MT simply uses the same registry and that should be no problem: The seed and the prf are equally used in XMSS^MT and the keys can be uniquely identified by it.test_pubkey.cppI changedFurther notes:
test_xmssmt.cppto slow tests (ci) and generally left out the parameter sets that have large XMSS subtrees (height 20).size_tis used for the leaf index which can be more than 16 bits. Is there any particular reason why one wouldn't simply useuint32_tor similar?Todo:
closes #5256