Re: [openpgp] Disadvantages of Salted Signatures

Stephan Verbücheln <verbuecheln@posteo.de> Sat, 09 December 2023 15:42 UTC

Return-Path: <verbuecheln@posteo.de>
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 D8102C14F61E for <openpgp@ietfa.amsl.com>; Sat, 9 Dec 2023 07:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=posteo.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDBxOy9JS1AQ for <openpgp@ietfa.amsl.com>; Sat, 9 Dec 2023 07:42:48 -0800 (PST)
Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D37C14F5F7 for <openpgp@ietf.org>; Sat, 9 Dec 2023 07:42:48 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 202A8240101 for <openpgp@ietf.org>; Sat, 9 Dec 2023 16:42:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1702136566; bh=zpte54zUQRAIykCG299Bn6GlYaDGUOI95Ygfl70FRmE=; h=Message-ID:Subject:From:To:Date:MIME-Version:From; b=P6XD2mpTFFYqEAxu13U15Y1aMiRyRiUVPHYpOFGn8fbyNanJWPxAeHnLJrOgN+h5k PZDswv9Zle4uK+dPGQhLZAl3WjlVIZ8/4OoAMiikBNQcme/SdyvZNB6gSaCWBM/FuH ebnMmYxoiPzSoVw4hfgQ5HomByxkGncIdC8+/kSqGKQpLkS4msgshDmo+sz/EvV8os V2zOS7CoeP2SDS32UntLS9GVg9Diy3MItnXH1zO6vDwyO064WhRpNQ0c9hEjdEgYZ5 vjR1rI7fYNiCxNm3fdG2uo9BQeaumoplNYZRz+JRZj37oypgeR3UQpcjrvCSwv6r2X 3WDSg4T7Vy1Ow==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SnXMT5jYpz9rxM for <openpgp@ietf.org>; Sat, 9 Dec 2023 16:42:45 +0100 (CET)
Message-ID: <f83dd301dc3dce17ab6e4c6eda550f01fdc57849.camel@posteo.de>
From: Stephan Verbücheln <verbuecheln@posteo.de>
To: openpgp@ietf.org
Date: Sat, 09 Dec 2023 15:42:45 +0000
In-Reply-To: <4231197A-9FB7-4B5F-984B-648BB2794C61@andrewg.com>
References: <077dd27cef0c7d3968967fc4c3a880081b8bd9dd.camel@posteo.de> <4231197A-9FB7-4B5F-984B-648BB2794C61@andrewg.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-ofWgUVEw7GZZEFgfggKv"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/zpig1JQc-ojNMGvkN9YqfVn-7cw>
Subject: Re: [openpgp] Disadvantages of Salted Signatures
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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, 09 Dec 2023 15:42:52 -0000

Hi Andrew

On Sat, 2023-12-09 at 10:47 +0000, Andrew Gallagher wrote:
> Strictly speaking, an action being pointless does not mean that it
> will not happen. One could imagine an automated system, say a notary
> service, being coerced into making a large number of identical
> signatures, even down to the timestamp.

You are right, there are some exotic scenarios where this could happen.
However, such a notary should not be running in an environment where
the CPU and memory are shared with untrusted processes or systems. Also
there is nothing preventing the notary from putting their own salt into
the data if they think it is useful to them.

The question is: Does it make sense as a default for the majority of
users in typical use cases such as signing of e-mails, release tarballs
or Git commits?
In that case, it is best practice anyway to require a manual PIN entry
for each signature, which makes it even more unlikely that two
identical messages are signed with the same timestamp.

Regards
Stephan