Re: [openpgp] Disadvantages of Salted Signatures

Stephan Verbücheln <> Sat, 09 December 2023 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C520C14F681 for <>; Sat, 9 Dec 2023 07:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.404
X-Spam-Status: No, score=-4.404 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_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 QbndnzPwU5l4 for <>; Sat, 9 Dec 2023 07:31:04 -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 0549AC14F61A for <>; Sat, 9 Dec 2023 07:31:02 -0800 (PST)
Received: from submission ( []) by (Postfix) with ESMTPS id 63A2B240101 for <>; Sat, 9 Dec 2023 16:31:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=2017; t=1702135860; bh=205FA/DdWifHBt+CNETIjuQYH3wxkpjCE2VFYVrwb+U=; h=Message-ID:Subject:From:To:Date:MIME-Version:From; b=ZocOJLchGxJkFtI7Hi7pIMn1h+y1hv4eTJgC6d2DfHnFXvxAeqbE8uy4fnXaDMUVg WPDg1vwf3GiClSz7Sa/fzHRD9qnHrBhpiWBzl6fpT5s4Jm7JKrijLS7Yu/qIdaHJIO MXT5sRwpqObl4M0LJSAL/SZT48jh5CN6G9jfls0LXGpEF7rumoffvNvaKlvNApD4Id 0bsLeu2Z0AdvwBFEX5Bs9OrJZ9NEx/uaa8XVcXj0YxY17U4Inc/XbYt7wd/DOeBBZ5 sORbo3orkHuaGcAZPd2u2mhwwpHaIFRPfXUUHnPOzftcuLqNtsL2dNpQprKzzhxj6y 4jOOIECyTxWUQ==
Received: from customer (localhost []) by submission ( with ESMTPSA id 4SnX5v6kNZz6twG for <>; Sat, 9 Dec 2023 16:30:59 +0100 (CET)
Message-ID: <>
From: Stephan Verbücheln <>
Date: Sat, 09 Dec 2023 15:30:59 +0000
In-Reply-To: <>
References: <> <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-DSERFL2r/ucTw4ECvMdt"
MIME-Version: 1.0
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 15:31:08 -0000

Hello Neal

You are correct with your analysis for the scenario of researchers and
developers testing software and smartcards in the lab. However, there
is also the use case of real-life forensics on suspicious signatures in
the wild.

For example, imagine I have a file letter.txt and a corresponding

-rw-r--r-- 1 stephan stephan 1351 Dec  9 15:43 letter.txt
-rw-r--r-- 1 stephan stephan  119 Dec  9 15:44 letter.txt.sig

Now I am suspecting for some reason that something is wrong with this
signature. In order to investigate this, I want to create another
signature with a trusted PGP implementation.

So at first, I check the signature in order to get the timestamp.

$ gpg --verify letter.txt.sig 
gpg: assuming signed data in 'letter.txt'
gpg: Signature made Sat 09 Dec 2023 03:44:47 PM CET
gpg:                using EDDSA key 41D6...7C62
gpg: Good signature from "... <>" [ultimate]

Then I copy the file and create a new signature with a matching
timestamp, using the trusted PGP implementation.

$ cp letter.txt letter2.txt
$ faketime "3:44:47 PM" gpg -b letter2.txt

After that, I can test with SHA-2 checksums whether both signatures are

$ sha256sum *
a0bb...225f43ad9455710d  letter2.txt
4196...1d08cc0ee757c1c9  letter2.txt.sig
a0bb...225f43ad9455710d  letter.txt
4196...1d08cc0ee757c1c9  letter.txt.sig

I think this is a valuable use case to be considered.

I do not want to claim that I have thought this all through to the end.
It just seems counter-intuitive to me that cryptographers worked so
hard to make EdDSA deterministic and then engineers just throw it away
without a really convincing justification. So I am inviting everyone to
join this discussion to shed light on more use cases and scenarios
where salted signatures would be beneficial or dangerous.

I also want to say sorry that I am bringing this up so late in the
discussion. I was not aware about the new proposals until the LibrePGP
schism drew attention.

Best regards