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

"D. J. Bernstein" <djb@cr.yp.to> Fri, 03 March 2023 11:26 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
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 0C29AC1526FF for <pqc@ietfa.amsl.com>; Fri, 3 Mar 2023 03:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 zGnDptPYqdlg for <pqc@ietfa.amsl.com>; Fri, 3 Mar 2023 03:25:59 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 47E12C1522DB for <pqc@ietf.org>; Fri, 3 Mar 2023 03:25:57 -0800 (PST)
Received: (qmail 31802 invoked by uid 1010); 3 Mar 2023 11:25:56 -0000
Received: from unknown (unknown) by unknown with QMTP; 3 Mar 2023 11:25:56 -0000
Received: (qmail 1126241 invoked by uid 1000); 3 Mar 2023 11:25:32 -0000
Date: Fri, 03 Mar 2023 11:25:32 -0000
Message-ID: <20230303112532.1126239.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: pqc@ietf.org
Mail-Followup-To: pqc@ietf.org
In-Reply-To: <092a4783-e9e9-f9f2-93d8-41e33800d14b@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pqc/FLdc1rGhCp5ER0ZjR_u8BnqKsjY>
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 11:26:04 -0000

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. At the opposite extreme, my understanding is that Russia
demands back doors in cryptography whether or not it's exported.

---D. J. Bernstein