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
- [Pqc] Mapping the state of PQC and IETF Sofía Celi
- Re: [Pqc] [Ext] Mapping the state of PQC and IETF Paul Hoffman
- Re: [Pqc] [Ext] Mapping the state of PQC and IETF Alexandre Petrescu
- Re: [Pqc] [Ext] Mapping the state of PQC and IETF Behcet Sarikaya
- Re: [Pqc] Mapping the state of PQC and IETF Rebecca Guthrie
- Re: [Pqc] [Ext] Mapping the state of PQC and IETF Paul Hoffman
- Re: [Pqc] Mapping the state of PQC and IETF John Gray
- Re: [Pqc] [EXTERNAL] Mapping the state of PQC and… Mike Ounsworth
- Re: [Pqc] [EXTERNAL] Mapping the state of PQC and… Mike Ounsworth
- Re: [Pqc] [Ext] [EXTERNAL] Mapping the state of P… Paul Hoffman
- Re: [Pqc] [EXTERNAL] Mapping the state of PQC and… Hannes Tschofenig
- Re: [Pqc] Mapping the state of PQC and IETF Kampanakis, Panos
- Re: [Pqc] Mapping the state of PQC and IETF Hannes Tschofenig
- Re: [Pqc] [EXTERNAL] Mapping the state of PQC and… Alexandre Petrescu
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Kampanakis, Panos
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Bas Westerbaan
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Kampanakis, Panos
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Behcet Sarikaya
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Bas Westerbaan
- Re: [Pqc] Mapping the state of PQC and IETF Sofía Celi
- Re: [Pqc] [Ext] [EXTERNAL] Mapping the state of P… Sofía Celi
- Re: [Pqc] Mapping the state of PQC and IETF Sofía Celi
- Re: [Pqc] [Ext] [EXTERNAL] Mapping the state of P… Mike Ounsworth
- Re: [Pqc] Mapping the state of PQC and IETF - ssh D. J. Bernstein
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Eric Rescorla
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Alexandre Petrescu
- Re: [Pqc] Mapping the state of PQC and IETF - ssh D. J. Bernstein
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Alexandre Petrescu
- Re: [Pqc] Mapping the state of PQC and IETF - ssh D. J. Bernstein
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Blumenthal, Uri - 0553 - MITLL
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Alexandre Petrescu
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Thom Wiggers
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Alexandre Petrescu
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Thom Wiggers
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Behcet Sarikaya
- Re: [Pqc] Mapping the state of PQC and IETF - ssh Alexandre Petrescu