Re: [Pqc] Mapping the state of PQC and IETF - ssh

[Alexandre Petrescu <[e-mail]>]

Thank you authors of this topic, and the subject line update.

If I may further bring a typical question about this, that of export
controls:

Le 02/03/2023 à 09:32, D. J. Bernstein a écrit :
> Kampanakis, Panos writes:

[...]
> The available evidence (see 
> https://nist.pqcrypto.org/foia/index.html) suggests that NIST 
> actually selected Kyber in 2021.12, but then delayed the
> announcement for several months trying to deal with patents.

Obviously an ssh end user would not like to be charged lots of money for
just being secure.  In the automotive industry the stance is that there
are some fundamental safety features necessarily present in even the
cheapest automobiles - not only for the obvious ethical reason but also
to avoid further safety risks to those with more expensive automobiles
too - security is a whole and expensive cars must exist.

That said, the IPR discussion might be valid at NIST but it is also at IETF.

> I'm saying "trying" here because the patent situation is still a 
> mess:
> 
> * NIST's patent buyouts don't activate until after NIST issues its 
> Kyber standard (currently predicted to be 2024---probably there will 
> be a draft standard early summer 2023);
> 
> * NIST's buyouts are only for _exactly the version of Kyber in that 
> standard_ (patching security problems would require new buyouts); 
> and
> 
> * NIST doesn't appear to have analyzed whether Kyber is safe from the
> other five patent families that were already identified on GAM/LPR
> systems. (See https://ntruprime.cr.yp.to/faq.html.)
> 
> NIST's 2022.07 report said that NIST could still select NTRU as the 
> patent-free option if something went wrong with patents. NIST 
> retracted this after the buyout agreements were signed. (This could 
> be undertsood as saying the other patent families aren't an issue, 
> but by default I'd chalk this up to NIST not realizing how courts 
> stretch patents.)
> 
> NIST could instead have issued a 2021 announcement encouraging 
> immediate deployment of NTRU. NIST's report said that "the overall 
> performance of any of these KEMs would be acceptable for general-use 
> applications" and that NIST finds Kyber's security "marginally" more 
> convincing than NTRU's security. "Marginally" is an awfully thin 
> rationale for diving into a patent minefield and delaying 
> post-quantum deployment until 2024.
> 
> It's important to remember that attackers systematically collect user
> data and keep it in the hopes of decrypting it later:
> 
> https://www.forbes.com/sites/andygreenberg/2013/06/20/leaked-nsa-doc-says-it-can-collect-and-keep-your-encrypted-data-as-long-as-it-takes-to-crack-it/
>
>
> 
Delaying post-quantum deployment means security damage.
> 
>> There was nothing wrong with it, it just didn't move forward, so 
>> there will be no final spec for it.
> 
> NTRU Prime already has a complete specification and a Sage reference
>  implementation (see https://ntruprime.cr.yp.to) along with the 
> deployed software. Every detail of the internal PKE stabilized five 
> years ago, and every remaining KEM detail stabilized four years ago.
> 
> Obviously _NIST_ isn't about to issue an NTRU Prime specification, 
> but IETF and IRTF aren't bound by what NIST does. When NIST's 
> standards aren't in line with IETF priorities, IETF sets its own 
> standards, as illustrated by the usage of Curve25519 in IETF 
> standards for several years (starting with an IRTF informational 
> spec, preceded by a detailed CFRG investigation of options) before 
> NIST finally managed to issue a Curve25519 standard in 2023.
> 
> For post-quantum cryptography, there's a security problem _right 
> now_, and IETF should endorse taking action _right now_ in response. 
> Given the patent situation, this isn't compatible with following 
> NIST.
> 
>> Also, OpenSSH currently does not support ECDH+PQ for "quantum-safe
>>  FIPS" compliance.
> 
> I'm not sure exactly which distinction you're drawing here, but I'd 
> suggest that the top priority should be protecting users, even if 
> this is negatively correlated with FIPS compliance.
> 
>> Although it is a great that OpenSSH was an early adopter, in the 
>> long run it makes sense to standardize on a consensus-based, 
>> peer-reviewed spec
> 
> The Kyber and NTRU Prime specs have both undergone peer review. This 
> is more meaningful for NTRU Prime than for Kyber, for two basic 
> reasons: (1) Kyber has a larger attack surface; (2) the Kyber design 
> is a moving target, for example with discoveries of flaws in the 
> security analysis leading to cryptosystem modifications 4 years ago 
> and 2.5 years ago.
> 
> As for "consensus-based", the process of reaching consensus in IETF 
> starts with IETF investigation of the merits of the options at hand.
>  Seeing deployment of various options can provide indirect 
> information but shouldn't substitute for an IETF investigation.

In that consensus search, and in the end user protection direction, one
would also consider the export controls.  This is new and stronger crypto.

Is this crypto subject to export controls and does it concern me in my
country or not?

Or is it also in a birth phase, a fluid law setting, where it is not
known precisely, and hence the usage can be dubious at the time.

This is also make or break in the usage, with potential effects on
standards.

The export control concept applies to ssh but also to other protocols
protected by this stronger and newer crypto.

Alex

> 
>> instead of complying with the choices one widely-used 
>> implementation made.
> 
> OpenSSH's deployment of post-quantum cryptography began with TinySSH
>  from Jan Mojzis. Two implementations of a protocol are sufficient 
> for IETF standardization.
> 
> There's security value in focusing cryptographic review on a limited
>  number of options, but, given the GAM/LPR patent minefield, IETF and
>  IRTF shouldn't restrict attention purely to GAM/LPR cryptosystems 
> such as Kyber.
> 
>> Currently SSH is an orphan protocol; there is no IETF WG to work
>> on it and PQUIP will not do any standardizations.
> 
> I would like to see the X25519+PQ hybrids specified centrally so that
> they don't require protocol-specific work.
> 
> ---D. J. Bernstein
>