Re: [lamps] [EXT] Re: New Composite Algs list

[Tim Hollebeek <[e-mail]>]

It’s not true that all of the relevant decisions have been made … whether and which ones of these IETF will standardize is a very important decision that has not (entirely) been made yet, so I welcome this kind of discussion and analysis.  I’m actually very interested in it myself, as I don’t think we’ve yet figured out the best technology or technologies to implement the transition.  I think the sort of detailed security analysis that’s going on in this thread is very important.

There have been a lot of things figured out during the last 5 years of discussion on this topic, but there’s still more work to do, and I would like to thank all the people who have been involved and sticking with these very important discussions.

-Tim

From: Spasm <[e-mail]> On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Thursday, May 11, 2023 11:58 AM
To: Mike Ounsworth <Mike.Ounsworth=[e-mail]>
Cc: LAMPS <[e-mail]>
Subject: Re: [lamps] [EXT] Re: New Composite Algs list

I will not try myself to make an argument for hybrids, but instead point to published works:

BSI
“potential vulnerabilities that only arise from the concrete implementation of a new algorithm are not yet as well studied as is the case with algorithms that have been in use for some time. Therefore, quantum computer-resistant methods should not be used alone - at least in a transitional period – but only in hybrid mode, i.e. in combination with a classical method.”
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.pdf?__blob=publicationFile&v=4

Among the cited publications, this is the only one that bases its opinion on security-related reasons. And their reasoning is questionable. For example, LWE has been studied since at least 1995 longer than ECC was before it’s been accepted as a standard. There was no overwhelming need to move to ECC from RSA (or DH), but nobody suggested then that “ECC should … be used … only … in combination with a classical method <that being RSA at that time>”. Likewise, when DES was being retired, nobody suggested that AES-protected information should be super-encrypted with DES, because “potential vulnerabilities … are not yet as well studied”.

German InfoSec Agency (BSI) thinks hybrid is the only way to proceed, and will require it. American InfoSec Agency (NSA) thinks hybrid is unnecessary, and will not require it. Which one of them is right?

Note that if CRQC does come to existence, then hybrids assuredly won’t help, including protection of today’s sensitive data than need to remain confidential.
Only if all of the following statements remain true, hybrid would make sense:

  1.  There is no CRQC throughout the time the data maintains its value (otherwise, adding Classic is useless);
  2.  There is an attack against PQ part of the hybrid;
  3.  There are no attacks against Classic part of the hybrid.

If you truly believe in (1), why bother with PQ stuff at all? Re. (2) and (3) – how likely would that be?


ETSI
“If backwards compatibility is required during a phased migration, then the application will have to support both classical and Quantum Safe algorithms.

This makes no sense to me – if your data would still require protection when CRQC is built, you have to PQ-protect it now, to deal with “record now, break later” attacks. In that case, your applications would have to start supporting PQ now as well. Then, if you have to roll out the PQ support anyway, what’s the point of supporting also Classical? And if your applications don’t deal with data of that degree of sensitivity – why migrate now at all?

Note that there are two separate goals that can be achieved by PQ / T hybrid cryptography:

1)      increased security against a break of one of the component algorithms, and

CRQC pretty much guarantees a break in the Classic (Traditional) component, no matter what. The only arguments are about when (5 years? 10? 20? 50?), or even if.


2)      Easing migration and backwards compatibility.

How having to maintain two sets of algorithms instead of one would ease migration?

Backwards compatibility would only matter if you’re communicating with or using data protected by Classic-only. If that’s the case – intercept of your encrypted data today is a guaranteed compromise if CRQC is ever built (within the lifetime of that data); while failure of CRQC to materialize would mean the whole effort was a waste of time and money.

Perhaps I’m fighting with windmills, as all of the relevant decisions seem to have already been made… Still, pointing out the apparent, er, lack of wisdom in those gives a feeling of relief. ;-)




From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Tomas Gustavsson
Sent: Thursday, May 11, 2023 1:00 AM
To: Watson Ladd <[e-mail]<mailto:[e-mail]>>; Mike Ounsworth <Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]>>
Cc: LAMPS <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [lamps] New Composite Algs list

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
X.509 calls it alternative signatures.
https://www.itu.int/rec/T-REC-X.509-201910-I<https://urldefense.com/v3/__https:/www.itu.int/rec/T-REC-X.509-201910-I__;!!FJ-Y8qCqXTj2!ayrq1aEMkWQljW-8Lh3dmdfDOi8QJn-lEVFYFJsZmSvkrVKWOfuyJ6nx11d80_s1Vus-XM2ZpjOiKrMZ8Fstvie_-znL_UOEhLn-lJ8t$>

Cheers,
Tomas

________________________________
From: Spasm <[e-mail]<mailto:[e-mail]>> on behalf of Watson Ladd <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, May 11, 2023 2:24 AM
To: Mike Ounsworth <Mike.Ounsworth=[e-mail]<mailto:Mike.Ounsworth=[e-mail]>>
Cc: LAMPS <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lamps] New Composite Algs list

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [e-mail]<mailto:[e-mail]> with any questions.


What's the rationale for hybrid signatures?



--
Astra mortemque praestare gradatim

_______________________________________________
Spasm mailing list
[e-mail]<mailto:[e-mail]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Ctomas.gustavsson%40keyfactor.com%7Cc59ae65205db4e0eef0908db51b6192e%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638193614842431678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aRdnug9rugBXYJOOxC4l831nc48nHH5%2FrPeZX1M%2BdeQ%3D&reserved=0<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ayrq1aEMkWQljW-8Lh3dmdfDOi8QJn-lEVFYFJsZmSvkrVKWOfuyJ6nx11d80_s1Vus-XM2ZpjOiKrMZ8Fstvie_-znL_UOEhJmOprFP$>
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.