-
Notifications
You must be signed in to change notification settings - Fork 570
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XMSS RFC 8391 Update #1858
XMSS RFC 8391 Update #1858
Conversation
XMSS_SHAKE256_W16_H16 = 0x0b00000b, | ||
XMSS_SHAKE256_W16_H20 = 0x0c00000c | ||
XMSS_SHA2_10_256 = 0x00000001, | ||
XMSS_SHA2_16_256 = 0x00000002, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the format changed between draft-06 and RFC? :/
Is there any reasonable way we can continue supporting older keys/sigs? It seems this change would invalidate all existing uses.
At the very least we'll also want to use a different OID for keys so it is not possible to mix them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, unfortunately the OID format did change. There exists another, new draft status document of interest regarding XMSS Algorithm Identifiers for HSS and XMSS for Use in the Internet X.509 Public Key Infrastructure. Also somewhere down the road XMSS will likely be assigned an "official" OID. So this may not be the last incompatible change to XMSS we see. There is also a disclaimer in RFC 8391:
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Research Task Force
(IRTF). The IRTF publishes the results of Internet-related research
and development activities. These results might not be suitable for
deployment. This RFC represents the consensus of the Crypto Forum
Research Group of the Internet Research Task Force (IRTF). Documents
approved for publication by the IRSG are not candidates for any level
of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8391.
A possibility to support older formats would be to integrate a key conversion utility into the botan cli.
I sent out a warning letting anyone who is actively using current draft-06 support to let us know https://lists.randombit.net/pipermail/botan-devel/2019-March/002278.html and added a warning to the 2.10 release notes. If we don't hear from anyone by say May 1st, I say go ahead and merge this. In the mean time we should still work to minimize disturbance:
|
Haven't heard from anyone about this so likely this is good to merge, but lets wait until end of the month just to be sure. |
@mgierlings Can you rebase to address the merge conflict? |
@randombit Will do. I also have another update to this PR in the pipeline, which I'll push soon. |
It looks like you merged master into your branch rather than rebasing, this makes history very hard to read. Please rebase instead. |
Changes XMSS and XMSS WOTS algorithm names and OIDs to correspond to RFC 8391.
- Replaces XMSS test vectors with new vectors that were generated using Bouncy Castle's XMSS implementation. - Adjusts the XMSS test bench to recognize the new XMSS algorithm naming scheme.
Internally XMSS uses a 64 Bit type for the leaf index. This patch removes the four leading zero bytes from the XMSS leaf index and serializes it as a four byte value as described in RFC 8391. Test cases are adjusted accordingly. The 64 Bit type is kept internally which potentially allows for code reuse when implementing XMSS^MT on top of the current XMSS code.
@randombit The broken commit should be fixed. I'm not sure though what causes the softhsm error in some of the Travis CI builds. |
@mgierlings Thanks. I think the problem is |
I don't think any change in performance was expected either way, but ftr I did check master vs this branch, they had only insignificant differences in sign and verify time. |
Codecov Report
@@ Coverage Diff @@
## master #1858 +/- ##
==========================================
- Coverage 91.38% 91.37% -0.01%
==========================================
Files 531 532 +1
Lines 56462 56556 +94
Branches 5877 5882 +5
==========================================
+ Hits 51596 51677 +81
- Misses 4866 4879 +13
Continue to review full report at Codecov.
|
@mgierlings I fixed the test issue in 10630cc. Is this PR ready to merge? |
@randombit Looks good to me! One remark though on the XMSS parameter name changes introduced with 10630cc: The RFC actually uses "-" between XMSS and the hash function name, see RFC 8391 Section 5.3 XMSS Parameters. By replacing the dash with an underscore we technically use non standard compliant algorithm names. |
@mgierlings BouncyCastle uses the same naming scheme, maybe this is a thing? Anyway, whatever we decide here, we should probably make it consistent in both libraries. |
@securitykernel Agreed, we should be consistent. If others start implementing XMSS, they will likely use names from the standard document. The cleanest solution would probably be to adhere to the RFC's naming scheme (in both BouncyCastle and Botan). If we come up with our own now we might need to revisit this and change naming again in the future. |
I renamed the params because that's what the patched handbook uses for the param names. I find combining hyphen and underscore really awkward. But if that is the standard naming scheme, probably best to follow it. |
@randombit The algorithm names in the handbook are supposed to correspond to the
or
|
I switched param names back. So I think this is now good to merge? It's been almost two months since the notification went out warning about the change and it looks like nobody sees an issue with it. |
@randombit Yes, I'd say we're good to merge. |
Updates XMSS (draft status) to conform to RFC 8391