Re: [Pqc] [Ext] [WG last call] IETF WG state changed for draft-ietf-pquip-pqt-hybrid-terminology

Wang Guilin <Wang.Guilin@huawei.com> Mon, 04 March 2024 11:18 UTC

Return-Path: <Wang.Guilin@huawei.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 33F42C151522 for <pqc@ietfa.amsl.com>; Mon, 4 Mar 2024 03:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 HSpoHdRJrz6z for <pqc@ietfa.amsl.com>; Mon, 4 Mar 2024 03:17:55 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0407FC151525 for <pqc@ietf.org>; Mon, 4 Mar 2024 03:17:55 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TpGKf0nZJz6K9J5 for <pqc@ietf.org>; Mon, 4 Mar 2024 19:13:58 +0800 (CST)
Received: from lhrpeml500002.china.huawei.com (unknown [7.191.160.78]) by mail.maildlp.com (Postfix) with ESMTPS id 0262F1416AD for <pqc@ietf.org>; Mon, 4 Mar 2024 19:17:52 +0800 (CST)
Received: from sinpeml500003.china.huawei.com (7.188.192.17) by lhrpeml500002.china.huawei.com (7.191.160.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 4 Mar 2024 11:17:51 +0000
Received: from sinpeml500005.china.huawei.com (7.188.193.102) by sinpeml500003.china.huawei.com (7.188.192.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 4 Mar 2024 19:17:49 +0800
Received: from sinpeml500005.china.huawei.com ([7.188.193.102]) by sinpeml500005.china.huawei.com ([7.188.193.102]) with mapi id 15.01.2507.035; Mon, 4 Mar 2024 19:17:49 +0800
From: Wang Guilin <Wang.Guilin@huawei.com>
To: Flo D <Flo.D=40ncsc.gov.uk@dmarc.ietf.org>, "pqc@ietf.org" <pqc@ietf.org>
CC: Wang Guilin <Wang.Guilin@huawei.com>
Thread-Topic: [Pqc] [Ext] [WG last call] IETF WG state changed for draft-ietf-pquip-pqt-hybrid-terminology
Thread-Index: AQHabAHx5sCbBZrqjEu2KgZ2iS78urEmxIwAgAChGeA=
Date: Mon, 04 Mar 2024 11:17:49 +0000
Message-ID: <600196f044fc4bc6acca1e033d6cc6ce@huawei.com>
References: <3407a98c-e683-44c3-aa66-9043bb186359@riseup.net> <5E709FEF-9AD3-4411-9470-984F44FF413E@icann.org> <LO0P123MB6702D75D28D3E59C9FADF6E2A8232@LO0P123MB6702.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <LO0P123MB6702D75D28D3E59C9FADF6E2A8232@LO0P123MB6702.GBRP123.PROD.OUTLOOK.COM>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.194.120.72]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pqc/Pf9ln0xZyWB0ROONcIceuUFhSbk>
Subject: Re: [Pqc] [Ext] [WG last call] IETF WG state changed for draft-ietf-pquip-pqt-hybrid-terminology
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: Mon, 04 Mar 2024 11:18:00 -0000

Dear Flo and all, 

I am happy to support adoption of draft-ietf-pquip-pqt-hybrid-terminology. 

I have read the draft several times and also given my feedback. So, from my viewpoint, the content seems quite good now. 

======================
About this version, my detailed comment is still on the definition of *Traditional Cryptographic Algorithm*. Namely, it seems still too narrow, not exactly the opposite of *Post-Quantum Algorithm*. 

Here is the current definition: 

"*Traditional Cryptographic Algorithm*:  An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems."

Happy to see this definition has been extended as asymmetric cryptographic algorithm based on factoring, DL or related mathematical problems, not just schemes based on factoring and DL problems, after communication with Flo. However, it seems still narrow. Namely, in logic, how can we show or conclude that Traditional Cryptographic Algorithms have only been built and also will be built only on factoring and DL related mathematical problems? A more natural definition may be something like the following (using similar expression for defining *Post-Quantum Algorithm* in [draft-ietf-pquip-pqt-hybrid-terminology]): 

*Traditional Cryptographic Algorithm*:  An asymmetric cryptographic algorithm that is designed to secure against attacks using classical computers, but not quantum computers. The representatives are  
cryptographic algorithms based on integer factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. For example, RSA, ECDSA, ECDH. 

In fact, this is similar for us not saying that Post-Quantum Algorithms just belong to five categories, as this is just what we have seen now. So, in future, some categories of Post-Quantum Algorithms may appear. Actually, this could happen to Traditional Cryptographic Algorithm as well. Namely, it is possible that someone may propose some totally new Traditional Cryptographic Algorithm based some new hard problem in the future. 

Another way to justify why the concept may need to be extended as the above is to show the existence of at least Traditional Cryptographic Algorithm, which is not based on factoring, DL or related mathematical problems. Especially, it will be even better if the algorithm is a standard or has been considered for standardization. 

For this purpose, I have checked this issue with a number of professors. Then, such an algorithm comes out: It is Algebraic Eraser (AE) Key Agreement Protocol (AEKAP). According to my quick check, I think AEKAP is a Traditional Cryptographic Algorithm, but not based on factoring, DL or related mathematical problems. 

Below is some related from WiKi and other sources for reference (I am not an expert on AEKAP and the related mathematical prolems): 
---------------------------------
1) Info from https://en.wikipedia.org/wiki/Algebraic_Eraser: 

"Algebraic Eraser (AE)[note 1] is an anonymous key agreement protocol that allows two parties, each having an AE public-private key pair, to establish a shared secret over an insecure channel.[1] This shared secret may be directly used as a key, or to derive another key that can then be used to encrypt subsequent communications using a symmetric key cipher. Algebraic Eraser was developed by Iris Anshel, Michael Anshel, Dorian Goldfeld and Stephane Lemieux. SecureRF owns patents covering the protocol[2] and unsuccessfully attempted (as of July 2019) to standardize the protocol as part of ISO/IEC 29167-20,[3] a standard for securing radio-frequency identification devices and wireless sensor networks.

The security of AE is based on the Generalized Simultaneous Conjugacy Search Problem (GSCSP)[4] within the braid group. This is a distinct and different hard problem than the Conjugacy Search Problem (CSP), which has been the central hard problem in what is called braid group cryptography.[5] Even if CSP is uniformly broken (which has not been done to date), it is not known how this would facilitate a break of GSCSP."

2. AEAKP once considered in IETF. 
Using Algebraic Eraser (AEDH) in OpenPGP
https://datatracker.ietf.org/doc/html/draft-atkins-openpgp-algebraic-eraser-05 

3. A paper on AEAKP
Algebraic EraserTM: A lightweight, efficient asymmetric key agreement protocol for use in no-power, low-power, and IoT devices. 
https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session8-atkins-paper.pdf 
---------------------------
======================

Guilin

-----Original Message-----
From: Pqc <pqc-bounces@ietf.org> On Behalf Of Flo D
Sent: Monday, 4 March 2024 4:53 pm
To: pqc@ietf.org
Subject: Re: [Pqc] [Ext] [WG last call] IETF WG state changed for draft-ietf-pquip-pqt-hybrid-terminology

Hi PQUIP,

Thanks Paul and Sofía for this last call.  I'd like to second Paul's call to the group to use this as an opportunity to review the draft.  Even if you don't think the draft still needs more time, I think it's vital that we "bank" some of the definitions sooner rather than later.  We need to do that so that the protocol drafts that refer to this draft, and that will start to get published once NIST have finalised their standards, can rely on the definitions that are included here.

Thanks in advance,
Flo

-----Original Message-----
From: Pqc <pqc-bounces@ietf.org> On Behalf Of Paul Hoffman
Sent: Friday, March 1, 2024 5:57 PM
To: pqc@ietf.org
Subject: Re: [Pqc] [Ext] [WG last call] IETF WG state changed for draft-ietf-pquip-pqt-hybrid-terminology

A strong nudge that this document is in WG Last Call and needs a bunch more reviews, even if they just say "that's all fine".


On Feb 21, 2024, at 07:31, Sofía Celi <cherenkov@riseup.net> wrote:

> Hi,
>
> This email starts the working group last call for "Terminology for Post-Quantum Traditional Hybrid Schemes" I-D, located here:
>
> https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/
>
> The WG Last Call will end 6th March 2024 @ 2359 UTC.
>
> Please review the I-D and submit any comments to the pqc@ietf.org mailing list.


--
Pqc mailing list
Pqc@ietf.org
https://www.ietf.org/mailman/listinfo/pqc

-- 
Pqc mailing list
Pqc@ietf.org
https://www.ietf.org/mailman/listinfo/pqc