[prev in list] [next in list] [prev in thread] [next in thread]
List: bouncycastle-crypto-dev
Subject: Re: [dev-crypto] Interoperability of XMSS implementation BouncyCastle/Botan
From: David Hook <dgh () cryptoworkshop ! com>
Date: 2019-09-25 20:56:57
Message-ID: 54957dae-11c7-ba83-b9ea-7853e63b456f () cryptoworkshop ! com
[Download RAW message or body]
Hi Rene,
As there's quite a bit here this might be better taken off list until
it's sorted.
I'd suggest we start with syncing up properly on the public keys.
I note with some despair that the draft has now expired. I don't think
there isn't going to be any improvement in the level of experience
people have with these algorithms if there isn't a defined way of using
them. WOTS based algorithms are really the only algorithms ready now
which offer both well understood security and post-quantum hardness.
Assuming the worst case, which is someone hits the n-qbit (n being some
appropriate number) barrier by 2026, even a P-521 root certificate is
really not going to cut it for more than 5 to 6 years. After 2026 the
odds only seem to get worse. Anything which is likely to need to have a
still working root certificate in more 5 years should be probably be
looking at things like XMSS now.
I'd recommend checking the latest beta as well on
https://www.bouncycastle.org/betas as we've made a small addition to the
private key structure to allow for sharding. I think, with a little bit
of work we could come up with an ASN.1 encoding for the BDS data.
Ultimately that's really what's required.
Anyway, drop me a line. Lets see what we can do.
Thanks,
David
On 25/9/19 11:06 pm, Rene Korthaus wrote:
>
> Hi there,
>
>
> we are currently working on bringing XMSS signatures into our
> products. The software generating the signatures and certificates will
> be using BouncyCastle, whereas our clients that need to parse
> certificates and verify the signatures will be using Botan.
>
>
> During interoperability tests we found that BouncyCastle and Botan are
> incompatible in different places. One aspect is OIDs of course, both
> using their own PENs. RFC draft
> https://tools.ietf.org/html/draft-vangeest-x509-hash-sigs-03=A0defines
> OIDs for official use, but it is still in draft state. We=A0contacted
> the authors about it, unfortunately, it seems it will not be adapted
> soon. The IETF working group was concerned about the=A0lack of
> experience in securely maintaining state and that IETF standardization
> of these OIDs could lead implementors to believe these algorithms were
> safe to use in more cases than they should be. I have=A0already talked
> to Jack, the maintainer of Botan (I CC'd him on this thread), about
> it. Our proposal would be to follow the RFC draft as close as possible
> ib both libraries, with exception of the OIDs.=A0Botan could be extende=
d
> to support BouncyCastle's OID for parsing public keys and certificates
> instead.
>
>
> Apart from the OID mismatch, we=A0found the following situation with th=
e
> two implementations:
>
>
> * public key: Botan encodes algorithm type, root node, public seed,
> as required by RFC 8391.=A0BouncyCastle uses a custom
> format:=A0https://github.com/bcgit/bc-java/blob/738dfc0132323d66ad2=
7e7ec366666ed3e0638ab/core/src/main/java/org/bouncycastle/pqc/asn1/XMSSPu=
blicKey.java
> * signature: Both Botan and=A0BouncyCastle encode as required by RFC =
8391.
> * certificates: BouncyCastle encodes the PARAMS field, although
> mandated to be absent by the RFC draft, BouncyCastle does not
> encode the algorithm type in the public key (see public key
> above); Botan can not generate XMSS certificates ATM, but support
> could be added quity easily
> * private key: Botan uses a custom format, BouncyCastle does so,
> too:=A0https://github.com/bcgit/bc-java/blob/738dfc0132323d66ad27e7=
ec366666ed3e0638ab/core/src/main/java/org/bouncycastle/pqc/asn1/XMSSPriva=
teKey.java;
> neither RFCs define a private key encoding
>
>
> Regarding public key encoding, this was already partly addressed
> in=A0https://github.com/bcgit/bc-java/pull/513, but the
> SubjectPublicKeyInfo encoding was not updated with it and still
> encodes in the RFC 8391 draft format and not the final RFC 8391 format.=
>
> Certificates would=A0need the public key encoding fix and the PARAMS
> field to be absent. Both can probably be done together.
>
> Although we don't require the private key encoding to be compatible in
> our current plans on adopting XMSS, we still think it would be useful
> in general=A0if both major implementations would be interoperable here.=
> Our proposal would be to add support for deserializing Bouncy Castle's
> format to Botan and eventually, after some releases, switch over to
> BouncyCastle's format for serializing in Botan, too.
>
> Is this a way to go for you?
>
> Best regards,
> Ren=E9
>
>
> ---
> Ren=E9 Korthaus
> Team Coordinator Shared Components
> C++ Shared Components & DevOps
>
> Rohde & Schwarz Cybersecurity GmbH
> Lise-Meitner-Allee 4 | D-44801 Bochum
> Phone: + 49 89 4129 208163
> Email: rene.korthaus@rohde-schwarz.com
> www.rohde-schwarz.com/cybersecurity
> <http://www.rohde-schwarz.com/cybersecurity>
>
> Executive Board: Dr. Falk Herrmann (CEO)
> Company's Place of Business: Munich
> Commercial Register No.: HRB 160333, VAT Identification No.: DE 2950789=
69
> WEEE Register Nr.: DE 138 891 79
>
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Hi Rene,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">As there's quite a bit here this might
be better taken off list until it's sorted.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I'd suggest we start with syncing up
properly on the public keys. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I note with some despair that the draft
has now expired. I don't think there isn't going to be any
improvement in the level of experience people have with these
algorithms if there isn't a defined way of using them. WOTS based
algorithms are really the only algorithms ready now which offer
both well understood security and post-quantum hardness. Assuming
the worst case, which is someone hits the n-qbit (n being some
appropriate number) barrier by 2026, even a P-521 root certificate
is really not going to cut it for more than 5 to 6 years. After
2026 the odds only seem to get worse. Anything which is likely to
need to have a still working root certificate in more 5 years
should be probably be looking at things like XMSS now.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I'd recommend checking the latest beta
as well on <a class="moz-txt-link-freetext" \
href="https://www.bouncycastle.org/betas">https://www.bouncycastle.org/betas</a> as \
we've made a small addition to the private key structure to allow for sharding.
I think, with a little bit of work we could come up with an ASN.1
encoding for the BDS data. Ultimately that's really what's
required.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Anyway, drop me a line. Lets see what
we can do.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">David</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 25/9/19 11:06 pm, Rene Korthaus
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ed4e00bf440b44308e1ef921d0c29185@rohde-schwarz.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"><!-- P \
{margin-top:0;margin-bottom:0;} --></style> <div id="divtagdefaultwrapper"
style="font-size:10pt;color:#000000;font-family:Arial,Helvetica,sans-serif;"
dir="ltr">
<div id="divtagdefaultwrapper" dir="ltr" style="color: rgb(0, 0,
0); font-family: Arial, Helvetica, sans-serif, EmojiFont,
"Apple Color Emoji", "Segoe UI Emoji",
NotoColorEmoji, "Segoe UI Symbol", "Android
Emoji", EmojiSymbols;">
<p style="font-size: 10pt;">Hi there,</p>
<p style="font-size: 10pt;"><br>
</p>
<p style="font-size: 10pt;"><span style="font-family: Arial,
Helvetica, sans-serif, EmojiFont, "Apple Color
Emoji", "Segoe UI Emoji", NotoColorEmoji,
"Segoe UI Symbol", "Android Emoji",
EmojiSymbols; font-size: 13.3333px;">we are currently
working on bringing XMSS signatures into our products. The
software generating the signatures and certificates will
be using BouncyCastle, whereas our clients that need to
parse certificates and verify the signatures will be using
Botan.</span><br>
</p>
<p style="font-size: 10pt;"><span style="font-family: Arial,
Helvetica, sans-serif, EmojiFont, "Apple Color
Emoji", "Segoe UI Emoji", NotoColorEmoji,
"Segoe UI Symbol", "Android Emoji",
EmojiSymbols; font-size: 13.3333px;"><br>
</span></p>
<p style="font-size: 10pt;"><span style="font-family: Arial,
Helvetica, sans-serif, EmojiFont, "Apple Color
Emoji", "Segoe UI Emoji", NotoColorEmoji,
"Segoe UI Symbol", "Android Emoji",
EmojiSymbols; font-size: 13.3333px;"><span
style="font-family: Arial, Helvetica, sans-serif,
EmojiFont, "Apple Color Emoji", "Segoe UI
Emoji", NotoColorEmoji, "Segoe UI
Symbol", "Android Emoji", EmojiSymbols;
font-size: 13.3333px;">During interoperability tests we
found that BouncyCastle and Botan are incompatible in
different places. One aspect is OIDs of course, both
using their own PENs. RFC draft
<a
href="https://tools.ietf.org/html/draft-vangeest-x509-hash-sigs-03"
class="OWAAutoLink" id="LPlnk124312"
previewremoved="true" moz-do-not-send="true">
https://tools.ietf.org/html/draft-vangeest-x509-hash-sigs-03</a> defines
OIDs for official use, but it is still in draft state.
We contacted the authors about it, unfortunately, it
seems it will not be adapted soon. The IETF working
group was concerned about the lack of experience in
securely maintaining state and that IETF standardization
of these OIDs could lead implementors to believe these
algorithms were safe to use in more cases than they
should be. I have already talked to Jack, the maintainer
of Botan (I CC'd him on this thread), about it. Our
proposal would be to follow the RFC draft as close as
possible ib both libraries, with exception of the
OIDs. Botan could be extended to support BouncyCastle's
OID for parsing public keys and certificates \
instead.</span></span></p> <p style="font-size: 10pt;"><span style="font-family: \
Arial, Helvetica, sans-serif, EmojiFont, "Apple Color
Emoji", "Segoe UI Emoji", NotoColorEmoji,
"Segoe UI Symbol", "Android Emoji",
EmojiSymbols; font-size: 13.3333px;"><span
style="font-family: Arial, Helvetica, sans-serif,
EmojiFont, "Apple Color Emoji", "Segoe UI
Emoji", NotoColorEmoji, "Segoe UI
Symbol", "Android Emoji", EmojiSymbols;
font-size: 13.3333px;"><br>
</span></span></p>
<p style="font-size: 10pt;"><span style="font-family: Arial,
Helvetica, sans-serif, EmojiFont, "Apple Color
Emoji", "Segoe UI Emoji", NotoColorEmoji,
"Segoe UI Symbol", "Android Emoji",
EmojiSymbols; font-size: 13.3333px;"><span
style="font-family: Arial, Helvetica, sans-serif,
EmojiFont, "Apple Color Emoji", "Segoe UI
Emoji", NotoColorEmoji, "Segoe UI
Symbol", "Android Emoji", EmojiSymbols;
font-size: 13.3333px;">Apart from the OID mismatch,
we found the following situation with the two
implementations:</span><br>
</span></p>
<p style="font-size: 10pt;"><span style="font-family: Arial,
Helvetica, sans-serif, EmojiFont, "Apple Color
Emoji", "Segoe UI Emoji", NotoColorEmoji,
"Segoe UI Symbol", "Android Emoji",
EmojiSymbols; font-size: 13.3333px;"><span
style="font-family: Arial, Helvetica, sans-serif,
EmojiFont, "Apple Color Emoji", "Segoe UI
Emoji", NotoColorEmoji, "Segoe UI
Symbol", "Android Emoji", EmojiSymbols;
font-size: 13.3333px;"><br>
</span></span></p>
<p style="font-size: 10pt;"><span style="font-family: Arial,
Helvetica, sans-serif, EmojiFont, "Apple Color
Emoji", "Segoe UI Emoji", NotoColorEmoji,
"Segoe UI Symbol", "Android Emoji",
EmojiSymbols; font-size: 13.3333px;"><span
style="font-family: Arial, Helvetica, sans-serif,
EmojiFont, "Apple Color Emoji", "Segoe UI
Emoji", NotoColorEmoji, "Segoe UI
Symbol", "Android Emoji", EmojiSymbols;
font-size: 13.3333px;"></span></span></p>
<ul style="font-size: 13.3333px; font-family: Arial,
Helvetica, sans-serif, EmojiFont, "Apple Color
Emoji", "Segoe UI Emoji", NotoColorEmoji,
"Segoe UI Symbol", "Android Emoji",
EmojiSymbols; margin-bottom: 0px; margin-top: 0px;">
<li>public key: Botan encodes algorithm type, root node,
public seed, as required by RFC 8391. BouncyCastle uses a
custom format: <a
href="https://github.com/bcgit/bc-java/blob/738dfc0132323d66ad27e7ec366666ed3e0638ab/core/src/main/java/org/bouncycastle/pqc/asn1/XMSSPublicKey.java"
target="_blank" rel="noopener noreferrer"
class="x_OWAAutoLink" id="LPlnk64539"
previewremoved="true" \
moz-do-not-send="true">https://github.com/bcgit/bc-java/blob/738dfc0132323d66ad27e7ec3 \
66666ed3e0638ab/core/src/main/java/org/bouncycastle/pqc/asn1/XMSSPublicKey.java</a></li>
<li>signature: Both Botan and BouncyCastle encode as
required by RFC 8391.</li>
<li>certificates: BouncyCastle encodes the PARAMS field,
although mandated to be absent by the RFC draft,
BouncyCastle does not encode the algorithm type in the
public key (see public key above); Botan can not generate
XMSS certificates ATM, but support could be added quity
easily</li>
<li>private key: Botan uses a custom format, BouncyCastle
does so, too: <a
href="https://github.com/bcgit/bc-java/blob/738dfc0132323d66ad27e7ec366666ed3e0638ab/core/src/main/java/org/bouncycastle/pqc/asn1/XMSSPrivateKey.java"
target="_blank" rel="noopener noreferrer"
class="x_OWAAutoLink" id="LPlnk643232"
previewremoved="true" \
moz-do-not-send="true">https://github.com/bcgit/bc-java/blob/738dfc0132323d66ad27e7ec3 \
66666ed3e0638ab/core/src/main/java/org/bouncycastle/pqc/asn1/XMSSPrivateKey.java</a>; \
neither RFCs define a private key encoding</li> </ul>
<div style=""><span style="font-size: 13.3333px;"><br>
</span></div>
<div style=""><span style="font-size: 13.3333px;">Regarding
public key encoding, this was already partly addressed in <a
href="https://github.com/bcgit/bc-java/pull/513"
class="OWAAutoLink" id="LPlnk643428"
previewremoved="true" \
moz-do-not-send="true">https://github.com/bcgit/bc-java/pull/513</a>, but the \
SubjectPublicKeyInfo encoding was not updated with it and still encodes in the RFC \
8391 draft format and not the final RFC 8391 format.</span></div>
<div style=""><span style="font-size: 13.3333px;"><br>
</span></div>
<div style=""><span style="font-size: 13.3333px;">Certificates
would need the public key encoding fix and the PARAMS
field to be absent. Both can probably be done together.</span></div>
<div style=""><br>
</div>
Although we don't require the private key encoding to be
compatible in our current plans on adopting XMSS, we still
think it would be useful in general if both major
implementations would be interoperable here. Our proposal
would be to add support for deserializing Bouncy Castle's
format to Botan and eventually, after some releases, switch
over to BouncyCastle's format for serializing in Botan, too.</div>
<div id="divtagdefaultwrapper" dir="ltr" style="color: rgb(0, 0,
0); font-family: Arial, Helvetica, sans-serif, EmojiFont,
"Apple Color Emoji", "Segoe UI Emoji",
NotoColorEmoji, "Segoe UI Symbol", "Android
Emoji", EmojiSymbols;">
<br>
</div>
<div id="divtagdefaultwrapper" dir="ltr" style="color: rgb(0, 0,
0); font-family: Arial, Helvetica, sans-serif, EmojiFont,
"Apple Color Emoji", "Segoe UI Emoji",
NotoColorEmoji, "Segoe UI Symbol", "Android
Emoji", EmojiSymbols;">
Is this a way to go for you?</div>
<div id="divtagdefaultwrapper" dir="ltr" style="color: rgb(0, 0,
0); font-family: Arial, Helvetica, sans-serif, EmojiFont,
"Apple Color Emoji", "Segoe UI Emoji",
NotoColorEmoji, "Segoe UI Symbol", "Android
Emoji", EmojiSymbols;">
<br>
</div>
<div id="divtagdefaultwrapper" dir="ltr" style="color: rgb(0, 0,
0); font-family: Arial, Helvetica, sans-serif, EmojiFont,
"Apple Color Emoji", "Segoe UI Emoji",
NotoColorEmoji, "Segoe UI Symbol", "Android
Emoji", EmojiSymbols;">
Best regards,</div>
<div id="divtagdefaultwrapper" dir="ltr" style="color: rgb(0, 0,
0); font-family: Arial, Helvetica, sans-serif, EmojiFont,
"Apple Color Emoji", "Segoe UI Emoji",
NotoColorEmoji, "Segoe UI Symbol", "Android
Emoji", EmojiSymbols;">
René<br>
<p style="font-size: 10pt;"><br>
</p>
<div id="Signature" style="font-size: 10pt;">
<div id="divtagdefaultwrapper" dir="ltr" style="">
<p style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
</p>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
---<br>
René Korthaus</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
Team Coordinator Shared Components</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
C++ Shared Components & DevOps</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
<br>
</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
Rohde & Schwarz Cybersecurity GmbH</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
Lise-Meitner-Allee 4 | D-44801 Bochum</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
Phone: + 49 89 4129 208163</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
Email: <a class="moz-txt-link-abbreviated" \
href="mailto:rene.korthaus@rohde-schwarz.com">rene.korthaus@rohde-schwarz.com</a></div>
<div style=""><a
href="http://www.rohde-schwarz.com/cybersecurity"
target="_blank" rel="noopener noreferrer" id="LPNoLP"
style="text-indent:-24px" \
moz-do-not-send="true">www.rohde-schwarz.com/cybersecurity</a></div> <div \
style="color:rgb(0,0,0); font-family:Arial,Helvetica,sans-serif; font-size:10pt">
<br>
</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
<span style="color:rgb(33,33,33);
font-family:Arial,sans-serif,serif,EmojiFont;
font-size:13.3333px">Executive Board: Dr. Falk
Herrmann (CEO)</span></div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
<span style="color:rgb(33,33,33);
font-family:Arial,sans-serif,serif,EmojiFont;
font-size:13.3333px"></span>Company's Place of
Business: Munich</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
Commercial Register No.: HRB 160333, VAT Identification
No.: DE 295078969</div>
<div style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
WEEE Register Nr.: DE 138 891 79</div>
<p style="color:rgb(0,0,0);
font-family:Arial,Helvetica,sans-serif; font-size:10pt">
</p>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic