Re: [openpgp] Curve448 in ECDH

"brian m. carlson" <> Sun, 28 February 2021 18:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0A4E3A1A91 for <>; Sun, 28 Feb 2021 10:44:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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: (amavisd-new); dkim=pass (3072-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ii1wUYhZMQfM for <>; Sun, 28 Feb 2021 10:44:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A54C3A1A90 for <>; Sun, 28 Feb 2021 10:44:39 -0800 (PST)
Received: from (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 (Postfix) with ESMTPSA id CA32760DF4 for <>; Sun, 28 Feb 2021 18:44:06 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1614537847; bh=DJeFktlfA4ywQFiqs3H3fikl2gspa+6yTkBD5txnBuM=; 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=ISWNy0WmVirQ/ZeGZRfx9PJrriNDa5BIDGtbEzESkRHGzf7YziZnc9CJ0bYLxx9ak VkYZOJq2Bj5o8gJq6fqH3BwG1Cypi2v465zvetWY8LQ4+pATkaL6Tc1QE49Cs6JR74 NCPsI1eBZzVnnHJqV904kaXcgrh//TRL0PJ6bEIVO/79jvZ3tdPY+yk1w6bh+uGUy/ glOv60LRRgy7Mx5VklAwjcNXpxTVceascoVYLQKuQ+xrJhi+fxzPsinjPoD6jvdZNY oUa4qFcXknhHPOtmuz1mwSqaUsZ968mB35drbjRWJr/wYk5xFd7L5zX/sWrEN4ZN7w VMfMJfQoV7DvLgJfOWJh5mKNp+KKbclLg3+GyBYR2kTikrGFHCYgBy0TU2vV1mksOA 0Fi6ePfgMEcJzb8DzJ2fwNzQRk9YH4DP/deLZJVg+LVBw82UnC92a4BJl1Y9tMh+et 3UVU0IGflooVvNdoH13mIhJkrXuoKCtE2K3CdjEFU7TzyuiLm4T
Date: Sun, 28 Feb 2021 18:44:01 +0000
From: "brian m. carlson" <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lv5qLzqgEmJUJW5g"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/2.0.5 (2021-01-21)
Archived-At: <>
Subject: Re: [openpgp] Curve448 in ECDH
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 28 Feb 2021 18:44:42 -0000

On 2021-02-28 at 18:19:35, Paul Wouters wrote:
> On Sun, 28 Feb 2021, brian m. carlson wrote:
> > > Is that a concern for openpgp ? openpgp is not an interactive protocol
> > > where there is a server-client with possible MITM observing time spent?
> > 
> > People definitely do use OpenPGP for interactive uses where constant
> > time operations are relevant.  For example, when you create a commit by
> > editing a file on GitHub, that commit will be signed by GitHub's private
> > key, which is an online use.  This is hardly the only case where people
> > sign online.
> While this is online, there is no negotiation to monitor where you can
> learn anything based on timing, as you don't get errors back to do
> timing on?

True, but you can create arbitrary content to sign, so you can influence
the data used in the signature.  If, for example, signing a message
where some hash bits have value A consistently takes more or less time
than a message where some bits have value B, then that could probably
be easily leveraged to learn something about the private key.

So I think this is a case where we'd see a timing oracle based on time
to complete versus a timing oracle based on success or failure.

> > I agree that these are not the typical uses of OpenPGP, but people
> > definitely do use it for online operations, and therefore, we need to
> > properly consider them when we secure the protocol.
> Sure, although if Curve448 has passed CFRG review, and other IETF
> protocols are using it as well, I would think the algorithm would
> be safe to use? And that constant time implementations will happen?
> Especially since those other protocols like TLS or IKE would be much
> more sensitive to this?

I believe Curve448 is presently considered secure and is expected to be
so for as long as quantum computers are not a threat, which is why CFRG
standardized it.  All implementations of Curve25519 and Curve448 that
I'm aware of are specifically designed to be constant time.

I agree that protocols which are always online like TLS are more likely
to be vulnerable to these attacks, but since most implementations of
OpenPGP are general purpose, it's hard to exclude them from online
brian m. carlson (he/him or they/them)
Houston, Texas, US