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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 03 March 2023 13:30 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: pqc@ietfa.amsl.com
Delivered-To: pqc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4366C151538 for <pqc@ietfa.amsl.com>; Fri, 3 Mar 2023 05:30:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.629
X-Spam-Level:
X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9nv3bFCpgUC for <pqc@ietfa.amsl.com>; Fri, 3 Mar 2023 05:29:58 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F681C14EAA3 for <pqc@ietf.org>; Fri, 3 Mar 2023 05:29:58 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 323DTts1029016 for <pqc@ietf.org>; Fri, 3 Mar 2023 14:29:55 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B3C7A202034 for <pqc@ietf.org>; Fri, 3 Mar 2023 14:29:55 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A8501208339 for <pqc@ietf.org>; Fri, 3 Mar 2023 14:29:55 +0100 (CET)
Received: from [10.8.32.70] (is156570.intra.cea.fr [10.8.32.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 323DTtAY010369 for <pqc@ietf.org>; Fri, 3 Mar 2023 14:29:55 +0100
Message-ID: <b8defb79-eb40-06b8-f327-4c3c45850df6@gmail.com>
Date: Fri, 03 Mar 2023 14:29:55 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
Content-Language: fr
To: pqc@ietf.org
References: <20230303112532.1126239.qmail@cr.yp.to>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <20230303112532.1126239.qmail@cr.yp.to>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pqc/YhfjZHI_WTLVtN4IeuSgANKNxyM>
Subject: Re: [Pqc] Mapping the state of PQC and IETF - ssh
X-BeenThere: pqc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Post Quantum Cryptography discussion list <pqc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pqc>, <mailto:pqc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pqc/>
List-Post: <mailto:pqc@ietf.org>
List-Help: <mailto:pqc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pqc>, <mailto:pqc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2023 13:30:02 -0000


Le 03/03/2023 à 12:25, D. J. Bernstein a écrit :
> Alexandre Petrescu writes:
>> Is this crypto subject to export controls and does it concern me in
>> my country or not?
> 
> For countries following the Wassenaar Arrangement, there are export 
> controls on cryptography, but with a critical exception for 
> open-source software. For example, if you look at page 3 of
> 
> https://www.wassenaar.org/app/uploads/2022/12/List-of-Dual-Use-Goods-and-Technologies-Munitions-List-Dec-2022.pdf
>
>
>
>
>
> 
then you find a blanket exception for software "in the public
> domain", where page 225 defines this as software "which has been made
> available without restrictions upon its further dissemination".
> 
> (There's also a note saying that "copyright restrictions do not 
> remove 'technology' or 'software' from being 'in the public domain'".
> This is generally understood to mean that CC0, MIT, GPL, etc. are all
> okay; just don't try to hide the source code or to charge per copy.)
> 
> Beyond the open-source exception, post-quantum cryptography was an 
> accidental exception to the Wassenaar Arrangement until 2018, because
> of the following series of events:
> 
> * Last century, there wasn't the open-source exception in the U.S. 
> The people in charge at NSA were using other exceptions to promote 
> weak cryptography, with considerable success.
> 
> * For example, they set up fast procedures (see page 12 of 
> https://web.archive.org/web/19970528120806/http://www.pmdtc.org/dtn/DTN1092.PDF)
>
>
>
>
>
> 
to approve deployments of 40-bit RC4. RC4 is weak even with larger
> keys; we didn't manage to stamp it out until decades later.
> 
> * After some policy evolution, the Wassenaar Arrangement ended up 
> controlling cryptography "in excess of 56 bits of symmetric key 
> length, or equivalent" (see, e.g., page 93 of the 2017 version: 
> https://www.wassenaar.org/app/uploads/2019/consolidated/2017-List-of-DU-Goods-and-Technologies-and-Munitions-List.pdf).
>
>
>
>
>
> 
* The procedures surrounding the Wassenaar Arrangement require that
> listed items be clearly defined, so someone went through giving a 
> concrete definition of "in excess of 56 bits of symmetric key length,
> or equivalent".
> 
> * Specifically, the definition says that "in excess of 56 bits of 
> symmetric key length, or equivalent" means a "symmetric algorithm" 
> with >56 key bits ("not including parity bits"), or an "asymmetric 
> algorithm" based on "any of the following: 1. Factorisation of 
> integers in excess of 512 bits (e.g., RSA); 2. Computation of 
> discrete logarithms in a multiplicative group of a finite field of 
> size greater than 512 bits (e.g., Diffie-Hellman over Z/pZ); or 3. 
> Discrete logarithms in a group other than mentioned in paragraph b.2.
> in excess of 112 bits (e.g., Diffie-Hellman over an elliptic 
> curve)."
> 
> Eventually (to my disappointment) someone on that side noticed that 
> this didn't cover post-quantum systems. In 2018, the Wassenaar 
> Arrangement added "asymmetric algorithms" where "the security of the
>  algorithm is based on any of the following: 1. Shortest vector or 
> closest vector problems associated with lattices (e.g., NewHope, 
> Frodo, NTRUEncrypt, Kyber, Titanium); 2. Finding isogenies between 
> Supersingular elliptic curves (e.g., Supersingular Isogeny Key 
> Encapsulation); or 3. Decoding random codes (e.g., McEliece, 
> Niederreiter)".
> 
> Today, as in the 1990s, the export laws create incentives to deploy 
> weak cryptography (e.g., RSA-512) and avoid strong cryptography, 
> including post-quantum cryptography. However, given
> 
> * the evidence of large-scale attackers already recording user data 
> for subsequent decryption,
> 
> * the risk that the attackers will have big quantum computers when 
> some of that data should still be confidential (think about, e.g., 
> whistleblowers talking to journalists), and
> 
> * the blanket exception in the Wassenaar Arrangement for open-source 
> software,
> 
> my recommendation is to proceed with immediate post-quantum 
> deployment, obviously using open-source software!
> 
> There's continual anti-cryptography lobbying from various agencies. 
> It's conceivable that at some point they'll have the political power
>  to remove the open-source exception in the Wassenaar Arrangement, to
>  undo the constitutional constraints on cryptography censorship in
> the U.S., etc. These risks aren't a reason to avoid taking action
> now; tomorrow's changes in the law can't retroactively punish today's
>  lawful actions.
> 
> There are also various efforts by NSA et al. to _slow down_ 
> deployment of post-quantum cryptography. I don't believe that going 
> along with these efforts is consistent with 
> https://www.rfc-editor.org/rfc/rfc7258 ("Pervasive Monitoring Is an 
> Attack"), specifically Section 2 ("The IETF Will Work to Mitigate 
> Pervasive Monitoring").
> 
> For your specific situation, you have to check on the details of the
>  law in your own country. For example, in the U.S., there's a 
> regulation demanding that you send email to enc@nsa.gov and 
> crypt@bis.doc.gov at the time of publication, but I'm skeptical that
>  this will survive court scrutiny.

Thanks for the description and suggestion.

For my specific situation, I kind of raised a questionary comment about
quantum resistance algos and export control during a TTC export controls
discussion (TTC stands for technology and trade council or commission or
similar, between EU and US, covering many trade and technology aspects,
so I asked whether the technology quantum encryption too might become
part of export controls and how; for some reason the question is under
consideration for some time now; the TTC is free access to TTC-inclined
people, meets regularly, has WG on 'standards').

I kind of suppose that if the algos are purely US inventions then they
might become (or not?) export controlled to some countries; but to be
understood under the explanation you gave above, in the better, about
the Wassenaar concept.

> At the opposite extreme, my understanding is that Russia demands back
> doors in cryptography whether or not it's exported.

Hm, good to know, I dont know.  I have not seen a change in stance from
Russia with respect to crypto export controls recently, but I dont know
their initial stance on crypto tech export controls either; it might be
as you say - backdoors imposed, I dont know.

I did see many changes in stance from Russia recently, but it is in what
concerns other Internet aspects (not crypto) - things like blocking
some western websites, independent pursuit of 5G trials, potentially
separation of 5G Internet standardisation (balance to Asia), separate
Internet from lower orbit space like Marathon (but it was so before too,
with old Molniya), and similar.  These 'pivots' so to say are in a
direction of more security, it is obvious, but they dont say 'quantum'
anywhere, so it's not immediately obvious to see how Russia considers
quantum resistance.

I this field, I suppose that Russia might want in the near future to
develop its own concept of quantum resistance, however hard that might
seem, i.e. regardless of cost.

Alex

> 
> ---D. J. Bernstein
>