Re: Interoperability of XMSS implementation BouncyCastle/Botan
David Hook <dgh-rTAZ0PM/[email protected]> Thu, 26 Sep 2019 06:56:57 +1000
| Newsgroups | gmane.comp.encryption.bouncy-castle.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------94129C6959F73520F6DD0304 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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-Bf/A/FSCP0w3s4ca2cGeAgC/[email protected] > 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 > --------------94129C6959F73520F6DD0304 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit <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-Bf/A/FSCP0w3s4ca2cGeAgC/[email protected]"> <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/738dfc0132323d66ad27e7ec366666ed3e0638ab/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/738dfc0132323d66ad27e7ec366666ed3e0638ab/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-Bf/A/FSCP0w3s4ca2cGeAgC/[email protected]">rene.korthaus-Bf/A/FSCP0w3s4ca2cGeAgC/[email protected]</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> --------------94129C6959F73520F6DD0304--