Re: [openpgp] Disadvantages of Salted Signatures

Simon Josefsson <> Sat, 09 December 2023 12:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91745C024C37 for <>; Sat, 9 Dec 2023 04:31:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Status: No, score=-7.108 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_DNSWL_HI=-5, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b="cVv51buG"; dkim=pass (2736-bit key) header.b="byvThmnr"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AWnVE6RYSdoS for <>; Sat, 9 Dec 2023 04:31:47 -0800 (PST)
Received: from ( [IPv6:2001:9b1:8633::107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 38851C049742 for <>; Sat, 9 Dec 2023 04:31:45 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed;; s=ed2303; h=Content-Type:MIME-Version:Message-ID:In-Reply-To :Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description; bh=IAXnoa+qgyRFQzneri9LG+GjRU7bVqFw7pCl7403f6c=; t=1702125089; x=1703334689; b=cVv51buGtbDXNNrZocmsF7iCdTHZ8cF3EbBdFP2HPYfLTRpZkRmufzomYUwrTzB3lb7/DW5yiZz 08qOWNjuqBw==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=rsa2303; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=IAXnoa+qgyRFQzneri9LG+GjRU7bVqFw7pCl7403f6c=; t=1702125089; x=1703334689; b=byvThmnrGI2T9W9grPr8wb9aHZ44zkIRWzXiNu21tchjSYeibqQf+i2M5qQ1ttEW70RbkQuhA8r umV4SlWegkKP1yqN8lHP5rU6XoFrLsRQWalZiOP0D9DtAjLVW3u/n7tamfDY2RAAMUnh9fUyyPoyC 4SZE1c/7LSmjsDnxCpAJbrja9BqtBQyKSHMYwbQq3mWijyUUeHJVdGfFA9ktYQhkXEF5MDqDYfP61 uvwIv/cB008F0HAFGk/efkGsKMshTZpKdYExERYhkX5c8k1alZE7PE9mdtr0BFv13zOxBrM+NNnbl s6W5qzQHrIuIG8q+0XPwWYcXZMtaLYFwHhhG1LGtun6w48Bc7M0yhOxkononFFyyzJBtUBp1Z2ppV S4NuiUuBSCYfcTb1m08hB0pERhO5PSbXFiLCoVh+Y+bvMAOMyq3i3gQbuHcqYj4y/idbb0ZFS;
Received: from [2001:9b1:41ac:ff00:823f:5dff:fe09:16ac] (port=58468 helo=kaka) by with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <>) id 1rBwUO-007D63-TA; Sat, 09 Dec 2023 12:31:24 +0000
From: Simon Josefsson <>
To: "Neal H. Walfield" <>
Cc: Stephan Verbücheln <>,
References: <> <>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=
Date: Sat, 09 Dec 2023 13:31:44 +0100
In-Reply-To: <> (Neal H. Walfield's message of "Sat, 09 Dec 2023 12:37:04 +0100")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
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: Sat, 09 Dec 2023 12:31:52 -0000

"Neal H. Walfield" <> writes:

> That is, OpenPGP smartcards are handed the computed hash and asked to
> sign that; AIUI, the smartcard does not generate, nor can it influence
> the value of the salt that was generated in the previous step.  So,
> from the perspective of the card, I think the signing operation is
> deterministic.

That is true - but the signing operation should be evaluated from the
outside perspective, not one internal operation in one possible design.
When seen from the outside, what is described in crypto-refresh appears
to be a randomized digital signature operation, unless I'm missing how
the random salt value is generated.  There is no reason a more
OpenPGP-aware smartcard couldn't take all inputs and generate the random
salt on board.

Deterministic signatures is a property that EdDSA helped establish as a
desired feature.  I wouldn't regard randomized signatures as a desirable
design in general today, but I don't see any direct attack on
crypto-refresh similar to the randomized digital signature problems in
ECDSA.  In my mind, the advantages of randomized digital signatures
happen when you design it to become a VRF, like VXEdDSA [1], but I don't
see any discussion that this is a design goal in crypto-refresh.