[openpgp] Curve448 in ECDH

"brian m. carlson" <sandals@crustytoothpaste.net> Sat, 27 February 2021 23:38 UTC

Return-Path: <sandals@crustytoothpaste.net>
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 D503E3A161D for <openpgp@ietfa.amsl.com>; Sat, 27 Feb 2021 15:38:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gE6O9ih4qOC for <openpgp@ietfa.amsl.com>; Sat, 27 Feb 2021 15:38:46 -0800 (PST)
Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DA43A161C for <openpgp@ietf.org>; Sat, 27 Feb 2021 15:38:45 -0800 (PST)
Received: from camp.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7d4e:cde:7c41:71c2]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 2BD2960DF4 for <openpgp@ietf.org>; Sat, 27 Feb 2021 23:38:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1614469093; bh=tlu6xIQHRx0j6Qq6fPGEcWOcRb0+pyCg85Q/rQDIQv4=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=a/Ron1wa4F3a383nwHzwGOlsbHnQe20ts/ze0WhWe8bMcE8ptoVJqWxKUtGV44PlG jMgULAgjcx2C210Hj7gSp8FcjYgEtldNsjbonGK+1pkzTWosc3jNH8GkCiiaUHy8Xt tyEWE8GcDePI9KqofskMXjZrZ+GLhwRcUrxBYcGXBmhnirBrhCx937s+yEAHEodTFF TAWjqMNOSYKhYV0Tma0TRp7/GIYgo5q9IttpY3I7144BGX6+xa8M3wDpmmU7m0j1Io 44/S0xYjhLeBiTp87X79oiT4DZP1JFKRNaGLJ/cObYvsDWWbsN+XCXkZu7N2JCXYeg h8JBUrE8Kpda3r3zrHJlValQ2sswA1H3MFSb6paW8QVGTgRCYeDDfYZC/upiS/uKXL q8rFjEyEZ1YrWUllhZIYzmu4K3ytMRCtZ9gzu+IsnaEeqfncKakyMmV8m8UiHn4jvL YiO/FtESfVaPfqMNIs1BoPU2FlQcgdANdLqZw2XqOmmiVC8RcvV
Date: Sat, 27 Feb 2021 23:38:08 +0000
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: openpgp@ietf.org
Message-ID: <YDrX4NICW6a6TX32@camp.crustytoothpaste.net>
References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+WdxAB6L+rfxqE7p"
Content-Disposition: inline
In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca>
User-Agent: Mutt/2.0.5 (2021-01-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/d5RzfD8ZyqtjcUoJ1IQiZSzv-XE>
Subject: [openpgp] Curve448 in ECDH
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 27 Feb 2021 23:38:48 -0000

On 2021-02-23 at 02:19:03, Paul Wouters wrote:
> 
> - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves)
> - Incorporate Curve25519 for ECDH

Most of what's there looks fine (excepting the v5 fingerprint thing I
mentioned elsewhere).

I'm wondering, however, if there's consensus for adding Curve448 as well
for ECDH.  (I would be in favor of it.)  I don't have an OID for it, but
I believe RFC 8410 defines one, although that RFC defines a different
OID for Curve25519 than I see here in the spec.

The reason I ask is that in many implementations, of the NIST curves,
only P-256 is implemented in a constant-time manner, whereas Curve25519
and Curve448 are almost always implemented in a constant-time manner.
For example, Go has this problem.  That's in addition to the pervasive
questions about the selection of the parameters, which I want to
acknowledge as a concern many people have but don't want to debate
extensively.

It therefore makes sense to provide a curve that doesn't have those
limitations for those cases where users or specifications require a
security level of 192 bits or greater.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US