Re: [openpgp] Disadvantages of Salted Signatures

Daniel Huigens <> Mon, 11 December 2023 11:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 502BAC14F5FD for <>; Mon, 11 Dec 2023 03:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.105 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3BmV8Sfou0Ia for <>; Mon, 11 Dec 2023 03:09:13 -0800 (PST)
Received: from ( []) (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 (Postfix) with ESMTPS id 40340C14F5E2 for <>; Mon, 11 Dec 2023 03:09:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=protonmail3; t=1702292950; x=1702552150; bh=QQpOQWCAB3LMs1cWWRuoeZWcZUn5gdVxl7YSbN9oHmQ=; 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=Oxfke/61icvUIlN5pDCvkwVWOa8rZ1ymYX7kVrKKB2+U5KIcJPhk97iKwRiyl8ynm QBoQPEBrg+elkDjJcT3gmmUqkmGK8FgJ+Je6b4GH27G+5di8IvO/6aizE2VMzulSAS YIBG7BNGlHTskc9mJGQVWTl/xis93Dhwq4RHdrk1ok3E3wx3XvoohXWQvoyZcyn96w jOQFuUT+yhUIWyKeji2Ltzb0AJNc4AQF16QasXG7zaJZKBq2QobhbqxsL6U9+jik5G q+OVPEJlj2ZN90aXq4Xh2howCOU0fWLP3TD63kj3SZpKC18lyWwwXKk5mAVDoi7QaL ZJBY0vdXLc1og==
Date: Mon, 11 Dec 2023 11:09:00 +0000
To: Stephan Verbücheln <>
From: Daniel Huigens <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
Feedback-ID: 2934448:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [openpgp] Disadvantages of Salted Signatures
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Dec 2023 11:09:17 -0000

Hi Stephan,

On Monday, December 11th, 2023 at 08:37, Stephan Verbücheln wrote:
> This change appears to be proposed by one party with one particular use
> case: Implementing PGP in JavaScript in the browser. This would explain
> the focus on fault attacks.

I'll assume you're referring to us, as we maintain OpenPGP.js?
However, as Neal mentioned, the addition of salting to signatures was
proposed by Sequoia, rather than by us, although we do support the
addition. Also, I believe fault attacks aren't specific to browser

> This is also apparent for other changes of the refresh such as GCM
> (because better supported by browsers)

The proximate cause for the addition of GCM was the fact that it's the
only AEAD mode standardized by NIST, and thus its inclusion is necessary
for those who care about FIPS compliance. The fact that it's implemented
in the Web Crypto API is a nice bonus, but not the primary reason for
its inclusion. Furthermore, this simply reflects the fact that GCM is
widely implemented and supported in general, and may thus be a
convenient option for other implementations as well.

> and Argon2 (because storing
> millions of keys in the cloud with weak login passwords rather than
> strong encryption passphrases or smartcards).

Argon2 (and the S2K mechanism in general) is not specific to cloud
storage; it can also be used if you want to store an encrypted copy of
your private key on an untrusted USB key, or something like that.
In fact, for such use cases, Argon2 is even more of an improvement,
because you can choose very strong parameters (e.g. taking a second or
more to derive the key), since this will be done very rarely. With the
previous S2K mechanisms, the maximum number of iterations was
relatively low (by modern computing performance standards), and so
achieving a second of hashing time was not possible. This is important
because shorter hash times obviously allow an attacker to try more
passwords in a given time frame. (And note that from the perspective
of the application, it doesn't know how strong the user's password or
passphrase is, so it's best to opt for a strong hashing function.)

> One could even argue that this cloud use case beats the point of PGP
> and end-to-end encryption, which is to work with your private
> information in a trusted environment. The JavaScript engine of a web
> browser is not exactly that, especially for long-term keys.

The Web Crypto API allows keys to be generated and stored in a way that
they are not accessible by JavaScript ("non-extractable"). OpenPGP.js
doesn't use this today, but it could do so in the future - but only for
algorithms that are supported by Web Crypto, of course. So if you care
about this, that's even more of a reason to use those (widely supported)
algorithms. As Andrew mentioned, web-based email isn't going away, for
better or worse.