Re: [openpgp] PQC encryption algorithm selection

Bart Butler <bart+ietf@pm.me> Wed, 07 February 2024 14:36 UTC

Return-Path: <bart+ietf@pm.me>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD0FC14F5FA for <openpgp@ietfa.amsl.com>; Wed, 7 Feb 2024 06:36:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pm.me
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 RdP0M4We4ZNy for <openpgp@ietfa.amsl.com>; Wed, 7 Feb 2024 06:36:11 -0800 (PST)
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7FBC14F71F for <openpgp@ietf.org>; Wed, 7 Feb 2024 06:36:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1707316568; x=1707575768; bh=pYpfBiLwTjVMQaw+5uz9JY9F8j30h2ck5yUfGsxqbnA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=TC+I5Jzb5JMa93NPSeOYtDD+SdDGsWTlnzTk3jO5Qx9umC1P4H7uRKLatIOVYJCqe BScnFcKdzc6orCR/HxqEOf7X79UT0pSZrjgmNAhq8hDNdFBcXhKX9XAicxBBPC4paQ I4R0HI5RrqaaxmtBU5c8neJT0jcycEsi13ddBJK2Je8pqRfwhGufADqpNzbtScFh5T 5tRDfslsalZjJzNnJ6zBTHLutULVUE9tB6JNi5kgXrMUGUmOOdJrn5czSRfr4CLJyx iiFGYUXFjeo9bQEtB9DlfdbmjgPi3G/Z0s0+ccQam/M+9GW5X1H7AVVCQ9tqoKLuXH 4pc7bbfXXDu8g==
Date: Wed, 07 Feb 2024 14:36:02 +0000
To: Simo Sorce <simo@redhat.com>
From: Bart Butler <bart+ietf@pm.me>
Cc: Aron Wussler <aron@wussler.it>, "openpgp@ietf.org" <openpgp@ietf.org>
Message-ID: <nIbLLK7cbTi8PL3_Tq4ppnh8hKDo9l7-xcpng3e4qr2xchofzqiJNlJ5N5YMkVonNpQ6p9Kyob0L3zY3w4VYdya_cBb2aZ6v7u9wKfeLLtw=@pm.me>
In-Reply-To: <1bbfbdbb7c927a0d5a3fc408ef2f1a02d3447a65.camel@redhat.com>
References: <WlmG-t8W8gPB6BePADYNwa365fmk6DGf3GF8Q4XZ3Ho1X3h0W9wykE364A6KDLQvU2p-lUKsftm0rQEe8V5p2jTuQgUEOQWOnlnhQJzdsgs=@wussler.it> <1bbfbdbb7c927a0d5a3fc408ef2f1a02d3447a65.camel@redhat.com>
Feedback-ID: 5683226:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="------6a9a1861c43451d56d92da9e1ef3b34c5feb1fc1204000d30cba48ed57f5a560"; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/_hHdjmB7qCQ_hvWHomYeGocEt4c>
Subject: Re: [openpgp] PQC encryption algorithm selection
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Feb 2024 14:36:15 -0000

I think everyone would love to just do 25519 and 448. The others (MAY) are there for compliance (NIST/BSI) if I'm not mistaken.

On Wednesday, February 7th, 2024 at 3:03 PM, Simo Sorce <simo@redhat.com> wrote:

> 

> 

> Hi Aron,
> Why so much redundancy in EC curves?
> 

> This is basically the same thing 3 times over, wouldn't it be more
> appropriate to just allow a singe EC curve family so there is no risk
> of interoperability issues between implementations ?
> 

> Simo.
> 

> On Wed, 2024-02-07 at 11:39 +0000, Aron Wussler wrote:
> 

> > Hi everyone,
> > 

> > In the next weeks, before IETF 119, we'd like to collect feedback about the algorithm selection implemented in the draft [1]. We're interested in presenting some vectors for the next meeting. It would be great if you could provide feedback by March 1st.
> > 

> > To keep the discussion focused we're going to start from the encryption algorithm selection, KEM combiners will follow (since it may also depend on the algorithm selection). Digital signatures will also follow in another thread.
> > 

> > Right now, we have the following list of algorithms (in table 1)
> > +====+===============================+=============+=============+
> > | ID | Algorithm | Requirement | Definition |
> > +====+===============================+=============+=============+
> > | 29 | ML-KEM-768 + X25519 | MUST | Section 5.2 |
> > +----+-------------------------------+-------------+-------------+
> > | 30 | ML-KEM-1024 + X448 | SHOULD | Section 5.2 |
> > +----+-------------------------------+-------------+-------------+
> > | 31 | ML-KEM-768 + ECDH-NIST-P-256 | MAY | Section 5.2 |
> > +----+-------------------------------+-------------+-------------+
> > | 32 | ML-KEM-1024 + ECDH-NIST-P-384 | MAY | Section 5.2 |
> > +----+-------------------------------+-------------+-------------+
> > | 33 | ML-KEM-768 + ECDH- | MAY | Section 5.2 |
> > | | brainpoolP256r1 | | |
> > +----+-------------------------------+-------------+-------------+
> > | 34 | ML-KEM-1024 + ECDH- | MAY | Section 5.2 |
> > | | brainpoolP384r1 | | |
> > +----+-------------------------------+-------------+-------------+
> > 

> > Please provide feedback on the algorithms, and if you think they should be "MUST", "SHOULD", or "MAY". The proposed list is derived from the results of the NIST standardization process, hybrid with the curves already supported from OpenPGP for compliance purposes.
> > 

> > Finally, please note that this is not the sole opportunity to standardize PQC algorithms: as of the crypto-refresh, new algorithms will need a specification and designated expert review, and not an RFC.
> > 

> > Cheers and thanks,
> > Aron
> > 

> > [1] https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-00.html#name-algorithm-specifications
> > 

> > --
> > Aron Wussler
> > Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930
> > _______________________________________________
> > openpgp mailing list
> > openpgp@ietf.org
> > https://www.ietf.org/mailman/listinfo/openpgp
> 

> 

> --
> Simo Sorce
> Distinguished Engineer
> RHEL Crypto Team
> Red Hat, Inc
> 

> 

> 

> 

> 

> 

> 

> 

> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp