Re: [TLS] PQC key exchange sizes
Dear, all, I wrote some of the open challenges of putting post-quantum cryptography into protocols over here: https://sofiaceli.com/thoughts/Taxonomy.pdf The document is very open ended atm but the idea is to develop into a list of concrete problems. As I mentioned on our talk at the TLS WG meeting, I am planning a next instation of this workshop for around November to precesily talk about these challenges (the website is not yet updated as some people have asked ;)): https://sofiaceli.com/PQNet-Workshop/ I'll send a reminder to this list once there is more information about it. Thank you, On 27/07/2022 21:54, Rob Sayre wrote: Hi, There's also data from the old Chrome/Cloudflare experiment, in the discussion section: https://blog.cloudflare.com/the-tls-post-quantum-experiment/ <https://blog.cloudflare.com/the-tls-post-quantum-experiment/> I /think/ the discussion says that sending handshake messages somewhat above the MTU didn't matter much, except on the slowest connections. They do hesitate to settle on a reason for that. As for compatibility in general, it seems premature to worry about. If an implementation adds PQC support, and finds it doesn't work for underlying fragmentation reasons, they'll surely have to fix that too. thanks, Rob On Wed, Jul 27, 2022 at 12:06 PM Bas Westerbaan <mailto:40cloudflare@dmarc.ietf.org>> wrote: On the QUIC side, there is the "*Q*uantum Ready" interop test: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370 <https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370> On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos mailto:40amazon@dmarc.ietf.org>> wrote: Gotcha. This is a reasonable explanation for a potential problem, but I would also like to see experimental proof that DTLS implementation X, Y, Z have the problem. TLS implementations don't deal with big ClientHellos today so we could assume they would have a problem, but when tested they do OK for the most part. -Original Message- From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Ilari Liusvaara Sent: Wednesday, July 27, 2022 10:42 AM To: mailto:tls@ietf.org>> mailto:tls@ietf.org>> Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote: > Hi Ilari, > > > - DTLS-level fragmentation. There are buggy implementations that > > break if one tries this. > > DTLS servers have been fragmenting and sending cert chains that don’t > fit in the MTU for a long time. Is this buggy on the TLS client side? These problems are specific to fragmenting Client Hello. Handling fragmented DTLS Client Hello is different from handling fragmented DTLS Certificate (and even more so in DTLS 1.3). I think DTLS specification just pretends both cases are the same. They are not. QUIC implementations could have similar issues with multiple initial packets, but operating QUIC with fast failure-independent fallback would make failures soft. There is the general principle that if some protocol feature is not used in the wild, it tends to break, even if required part of the protocol. Either by implementation being poorly tested and buggy, assuming the feature does not exist, or being missing entierely. Combine this with interop failures having outsize impact and old versions sticking around far longer than desriable. And I do not think fragmented Client Hellos in DTLS or multiple initials in QUIC are seen much. One trick with DTLS would be sending client hello with no key shares. Causes extra round-trip, but any server that selects PQC causing fragmentation would presumably be capable of handling that. -Ilari ___ TLS mailing list TLS@ietf.org <mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls> ___ TLS mailing list TLS@ietf.org <mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls> ___ TLS mailing list TLS@ietf.org <mail
Re: [TLS] PQC key exchange sizes
Hi, There's also data from the old Chrome/Cloudflare experiment, in the discussion section: https://blog.cloudflare.com/the-tls-post-quantum-experiment/ I /think/ the discussion says that sending handshake messages somewhat above the MTU didn't matter much, except on the slowest connections. They do hesitate to settle on a reason for that. As for compatibility in general, it seems premature to worry about. If an implementation adds PQC support, and finds it doesn't work for underlying fragmentation reasons, they'll surely have to fix that too. thanks, Rob On Wed, Jul 27, 2022 at 12:06 PM Bas Westerbaan wrote: > On the QUIC side, there is the "*Q*uantum Ready" interop test: > > > https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370 > > > > On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos 40amazon@dmarc.ietf.org> wrote: > >> Gotcha. This is a reasonable explanation for a potential problem, but I >> would also like to see experimental proof that DTLS implementation X, Y, Z >> have the problem. TLS implementations don't deal with big ClientHellos >> today so we could assume they would have a problem, but when tested they do >> OK for the most part. >> >> >> -Original Message- >> From: TLS On Behalf Of Ilari Liusvaara >> Sent: Wednesday, July 27, 2022 10:42 AM >> To: >> Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content is safe. >> >> >> >> On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote: >> > Hi Ilari, >> > >> > > - DTLS-level fragmentation. There are buggy implementations that >> > > break if one tries this. >> > >> > DTLS servers have been fragmenting and sending cert chains that don’t >> > fit in the MTU for a long time. Is this buggy on the TLS client side? >> >> These problems are specific to fragmenting Client Hello. Handling >> fragmented DTLS Client Hello is different from handling fragmented DTLS >> Certificate (and even more so in DTLS 1.3). I think DTLS specification just >> pretends both cases are the same. They are not. >> >> >> QUIC implementations could have similar issues with multiple initial >> packets, but operating QUIC with fast failure-independent fallback would >> make failures soft. >> >> >> There is the general principle that if some protocol feature is not used >> in the wild, it tends to break, even if required part of the protocol. >> Either by implementation being poorly tested and buggy, assuming the >> feature does not exist, or being missing entierely. >> Combine this with interop failures having outsize impact and old versions >> sticking around far longer than desriable. And I do not think fragmented >> Client Hellos in DTLS or multiple initials in QUIC are seen much. >> >> >> One trick with DTLS would be sending client hello with no key shares. >> Causes extra round-trip, but any server that selects PQC causing >> fragmentation would presumably be capable of handling that. >> >> >> >> -Ilari >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
On the QUIC side, there is the "*Q*uantum Ready" interop test: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=438405370 On Wed, Jul 27, 2022 at 8:57 PM Kampanakis, Panos wrote: > Gotcha. This is a reasonable explanation for a potential problem, but I > would also like to see experimental proof that DTLS implementation X, Y, Z > have the problem. TLS implementations don't deal with big ClientHellos > today so we could assume they would have a problem, but when tested they do > OK for the most part. > > > -Original Message- > From: TLS On Behalf Of Ilari Liusvaara > Sent: Wednesday, July 27, 2022 10:42 AM > To: > Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote: > > Hi Ilari, > > > > > - DTLS-level fragmentation. There are buggy implementations that > > > break if one tries this. > > > > DTLS servers have been fragmenting and sending cert chains that don’t > > fit in the MTU for a long time. Is this buggy on the TLS client side? > > These problems are specific to fragmenting Client Hello. Handling > fragmented DTLS Client Hello is different from handling fragmented DTLS > Certificate (and even more so in DTLS 1.3). I think DTLS specification just > pretends both cases are the same. They are not. > > > QUIC implementations could have similar issues with multiple initial > packets, but operating QUIC with fast failure-independent fallback would > make failures soft. > > > There is the general principle that if some protocol feature is not used > in the wild, it tends to break, even if required part of the protocol. > Either by implementation being poorly tested and buggy, assuming the > feature does not exist, or being missing entierely. > Combine this with interop failures having outsize impact and old versions > sticking around far longer than desriable. And I do not think fragmented > Client Hellos in DTLS or multiple initials in QUIC are seen much. > > > One trick with DTLS would be sending client hello with no key shares. > Causes extra round-trip, but any server that selects PQC causing > fragmentation would presumably be capable of handling that. > > > > -Ilari > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
Gotcha. This is a reasonable explanation for a potential problem, but I would also like to see experimental proof that DTLS implementation X, Y, Z have the problem. TLS implementations don't deal with big ClientHellos today so we could assume they would have a problem, but when tested they do OK for the most part. -Original Message- From: TLS On Behalf Of Ilari Liusvaara Sent: Wednesday, July 27, 2022 10:42 AM To: Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote: > Hi Ilari, > > > - DTLS-level fragmentation. There are buggy implementations that > > break if one tries this. > > DTLS servers have been fragmenting and sending cert chains that don’t > fit in the MTU for a long time. Is this buggy on the TLS client side? These problems are specific to fragmenting Client Hello. Handling fragmented DTLS Client Hello is different from handling fragmented DTLS Certificate (and even more so in DTLS 1.3). I think DTLS specification just pretends both cases are the same. They are not. QUIC implementations could have similar issues with multiple initial packets, but operating QUIC with fast failure-independent fallback would make failures soft. There is the general principle that if some protocol feature is not used in the wild, it tends to break, even if required part of the protocol. Either by implementation being poorly tested and buggy, assuming the feature does not exist, or being missing entierely. Combine this with interop failures having outsize impact and old versions sticking around far longer than desriable. And I do not think fragmented Client Hellos in DTLS or multiple initials in QUIC are seen much. One trick with DTLS would be sending client hello with no key shares. Causes extra round-trip, but any server that selects PQC causing fragmentation would presumably be capable of handling that. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote: > Hi Ilari, > > > - DTLS-level fragmentation. There are buggy implementations that > > break if one tries this. > > DTLS servers have been fragmenting and sending cert chains that don’t > fit in the MTU for a long time. Is this buggy on the TLS client side? These problems are specific to fragmenting Client Hello. Handling fragmented DTLS Client Hello is different from handling fragmented DTLS Certificate (and even more so in DTLS 1.3). I think DTLS specification just pretends both cases are the same. They are not. QUIC implementations could have similar issues with multiple initial packets, but operating QUIC with fast failure-independent fallback would make failures soft. There is the general principle that if some protocol feature is not used in the wild, it tends to break, even if required part of the protocol. Either by implementation being poorly tested and buggy, assuming the feature does not exist, or being missing entierely. Combine this with interop failures having outsize impact and old versions sticking around far longer than desriable. And I do not think fragmented Client Hellos in DTLS or multiple initials in QUIC are seen much. One trick with DTLS would be sending client hello with no key shares. Causes extra round-trip, but any server that selects PQC causing fragmentation would presumably be capable of handling that. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
On Tue, Jul 26, 2022, at 22:21, Kampanakis, Panos wrote: > Why are 2-3 packet CHs unworkable? Loss probability is a contributing factor for sure, but the thing that really hurts is the extra round trip that many servers will induce when they cannot process the TLS ClientHello in one go. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
Hi Ilari, > - DTLS-level fragmentation. There are buggy implementations that break if one > tries this. DTLS servers have been fragmenting and sending cert chains that don’t fit in the MTU for a long time. Is this buggy on the TLS client side? Any public info you can share about these buggy implementations for my education? -Original Message- From: TLS On Behalf Of Ilari Liusvaara Sent: Tuesday, July 26, 2022 10:59 AM To: Subject: RE: [EXTERNAL][TLS] PQC key exchange sizes CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Tue, Jul 26, 2022 at 02:15:34PM +0200, Thom Wiggers wrote: > > In yesterday’s working group meeting we had a bit of a discussion of > the impact of the sizes of post-quantum key exchange on TLS and > related protocols like QUIC. As we neglected to put Kyber’s key sizes > in our slide deck (unlike the signature schemes), I thought it would > be a good idea to get the actual numbers of Kyber onto the mailing list. > > Note that in the context of TLS’s key exchange, the public key would > be what goes into the ClientHello key_shares extension, and the > ciphertext would go into the Server’s ServerHello key_shares extension. > > Kyber512: NIST level I, "strength ~AES128" > public key: 800 bytes > ciphertext: 768 bytes > secret key: 1632 bytes > Kyber768: NIST level III, "~AES192" > public key: 1184 > ciphertext: 1088 > secret key: 2400 bytes > Kyber1024: NIST level V, "~AES256" > public key: 1568 > ciphertext: 1568 > secret key: 3168 > > So for the key exchange at least, it seems to me Kyber512 should work > for TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if > you want to stay in QUIC’s default 1300 byte initial packet? Also, I > don't really know how the D of DTLS might change the story. The initial packet size is 1200, so Kyber768 public key does not fit into a packet. However, the initial packets can be split, so even Kyber1024 key does fit into two initial packets (this also doubles the server initial window from 3600 to 7200 due to the way amplification limit works) DTLS is a bit more problematic. There are two ways to deal with the key being too big to fit in a single IP packet. - IP-level fragmentation. REALLY SHOULD NOT be used. - DTLS-level fragmentation. There are buggy implementations that break if one tries this. And in both case, the failure modes are not easy to recover from. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
On Tue, Jul 26, 2022, at 11:42, Blumenthal, Uri - 0553 - MITLL wrote: > What are the implications for environments that require NIST Sec Level 3 or 5? Poor performance. By which I mean increased exposure to packet loss and additional round trips. For instance, in QUIC servers might be forced to use Retry, which adds a round trip. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
What are the implications for environments that require NIST Sec Level 3 or 5? Regards, Uri > On Jul 26, 2022, at 11:33, Martin Thomson wrote: > > On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote: >> Be interested in how that'd change the CH if ECH is used too. >> I guess the answer mightn't make us happy;-) > > PQ HPKE would not fit, but the Kyber-512 numbers mean that we should be OK > for ECH if we stuck with classical security. For obvious reasons, that might > not be OK though. > > If we wanted a PQ HPKE (or a Hybrid KEM) then ECH would blow out the size so > that we would end up with multiple packets for the CH. That would be > basically unworkable from a performance perspective. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote: > Be interested in how that'd change the CH if ECH is used too. > I guess the answer mightn't make us happy;-) PQ HPKE would not fit, but the Kyber-512 numbers mean that we should be OK for ECH if we stuck with classical security. For obvious reasons, that might not be OK though. If we wanted a PQ HPKE (or a Hybrid KEM) then ECH would blow out the size so that we would end up with multiple packets for the CH. That would be basically unworkable from a performance perspective. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
On 26/07/2022 13:15, Thom Wiggers wrote: Hi all, In yesterday’s working group meeting we had a bit of a discussion of the impact of the sizes of post-quantum key exchange on TLS and related protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide deck (unlike the signature schemes), I thought it would be a good idea to get the actual numbers of Kyber onto the mailing list. Note that in the context of TLS’s key exchange, the public key would be what goes into the ClientHello key_shares extension, and the ciphertext would go into the Server’s ServerHello key_shares extension. Kyber512: NIST level I, "strength ~AES128" public key: 800 bytes ciphertext: 768 bytes secret key: 1632 bytes Be interested in how that'd change the CH if ECH is used too. I guess the answer mightn't make us happy;-) S. Kyber768: NIST level III, "~AES192" public key: 1184 ciphertext: 1088 secret key: 2400 bytes Kyber1024: NIST level V, "~AES256" public key: 1568 ciphertext: 1568 secret key: 3168 So for the key exchange at least, it seems to me Kyber512 should work for TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to stay in QUIC’s default 1300 byte initial packet? Also, I don't really know how the D of DTLS might change the story. All the numbers we reported are as of the latest version of the individual submissions (except as discussed below). The standards that NIST eventually names FIPS-xyz might have (mildly) different sizes. NIST has said that they’re always happy to receive feedback and information about use cases and constraints. Lastly, Bas Westerbaan has talked about a Kyber draft in yesterday’s CFRG meeting. I believe a stated goal is to use that for coordinating any experiments before the NIST standard is out. So keep an eye out if that interests you. Cheers, Thom PS: Let me also correct the mistake I had introduced in the SPHINCS+ numbers in the TLS talk: SPHINCS+ has indeed gotten slightly smaller than the numbers I reported. The smallest SPHINCS+ variant (sphincs+-128s) has a signature size of 7,856 bytes. There’s a nice table with the different parameter sets of SPHINCS+ on their Github repository https://github.com/sphincs/sphincsplus#parameters. I’m glad that people were paying attention, apparently more than I was :-) I will also clarify that when we mentioned that Falcon needs very careful attention when implementing, this concerns Falcon's signing routines. These require constant-time double-width floating point maths; on many CPUs this will need to be emulated in software. Verification, on the other hand, is a lot less sensitive. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PQC key exchange sizes
On Tue, Jul 26, 2022 at 02:15:34PM +0200, Thom Wiggers wrote: > > In yesterday’s working group meeting we had a bit of a discussion of the > impact of the sizes of post-quantum key exchange on TLS and related > protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide > deck (unlike the signature schemes), I thought it would be a good idea to > get the actual numbers of Kyber onto the mailing list. > > Note that in the context of TLS’s key exchange, the public key would be > what goes into the ClientHello key_shares extension, and the ciphertext > would go into the Server’s ServerHello key_shares extension. > > Kyber512: NIST level I, "strength ~AES128" > public key: 800 bytes > ciphertext: 768 bytes > secret key: 1632 bytes > Kyber768: NIST level III, "~AES192" > public key: 1184 > ciphertext: 1088 > secret key: 2400 bytes > Kyber1024: NIST level V, "~AES256" > public key: 1568 > ciphertext: 1568 > secret key: 3168 > > So for the key exchange at least, it seems to me Kyber512 should work for > TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to > stay in QUIC’s default 1300 byte initial packet? Also, I don't really know > how the D of DTLS might change the story. The initial packet size is 1200, so Kyber768 public key does not fit into a packet. However, the initial packets can be split, so even Kyber1024 key does fit into two initial packets (this also doubles the server initial window from 3600 to 7200 due to the way amplification limit works) DTLS is a bit more problematic. There are two ways to deal with the key being too big to fit in a single IP packet. - IP-level fragmentation. REALLY SHOULD NOT be used. - DTLS-level fragmentation. There are buggy implementations that break if one tries this. And in both case, the failure modes are not easy to recover from. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] PQC key exchange sizes
Hi all, In yesterday’s working group meeting we had a bit of a discussion of the impact of the sizes of post-quantum key exchange on TLS and related protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide deck (unlike the signature schemes), I thought it would be a good idea to get the actual numbers of Kyber onto the mailing list. Note that in the context of TLS’s key exchange, the public key would be what goes into the ClientHello key_shares extension, and the ciphertext would go into the Server’s ServerHello key_shares extension. Kyber512: NIST level I, "strength ~AES128" public key: 800 bytes ciphertext: 768 bytes secret key: 1632 bytes Kyber768: NIST level III, "~AES192" public key: 1184 ciphertext: 1088 secret key: 2400 bytes Kyber1024: NIST level V, "~AES256" public key: 1568 ciphertext: 1568 secret key: 3168 So for the key exchange at least, it seems to me Kyber512 should work for TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to stay in QUIC’s default 1300 byte initial packet? Also, I don't really know how the D of DTLS might change the story. All the numbers we reported are as of the latest version of the individual submissions (except as discussed below). The standards that NIST eventually names FIPS-xyz might have (mildly) different sizes. NIST has said that they’re always happy to receive feedback and information about use cases and constraints. Lastly, Bas Westerbaan has talked about a Kyber draft in yesterday’s CFRG meeting. I believe a stated goal is to use that for coordinating any experiments before the NIST standard is out. So keep an eye out if that interests you. Cheers, Thom PS: Let me also correct the mistake I had introduced in the SPHINCS+ numbers in the TLS talk: SPHINCS+ has indeed gotten slightly smaller than the numbers I reported. The smallest SPHINCS+ variant (sphincs+-128s) has a signature size of 7,856 bytes. There’s a nice table with the different parameter sets of SPHINCS+ on their Github repository https://github.com/sphincs/sphincsplus#parameters. I’m glad that people were paying attention, apparently more than I was :-) I will also clarify that when we mentioned that Falcon needs very careful attention when implementing, this concerns Falcon's signing routines. These require constant-time double-width floating point maths; on many CPUs this will need to be emulated in software. Verification, on the other hand, is a lot less sensitive. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
