Re: [openpgp] Disadvantages of Salted Signatures

Stephan Verbücheln <verbuecheln@posteo.de> Mon, 11 December 2023 16:43 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 8E601C14F61E for <openpgp@ietfa.amsl.com>; Mon, 11 Dec 2023 08:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
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, 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_HELO_NONE=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: 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 7NEfEtvFJj2U for <openpgp@ietfa.amsl.com>; Mon, 11 Dec 2023 08:43:22 -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) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E7EC14F5FB for <openpgp@ietf.org>; Mon, 11 Dec 2023 08:43:14 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id B5B59240104 for <openpgp@ietf.org>; Mon, 11 Dec 2023 17:43:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1702312992; bh=rtPfGhrDWMcBJeLn7eIRF67RAzTwn64CplwqanDxxC8=; h=Message-ID:Subject:From:To:Date:MIME-Version:From; b=LgEzRBtaLws+1H3A021hA0p+GUFqcM3Soj7fMgH9bUv9Qk3sYHOWPBS966fXR1VjF wqikJ2Mk1wyCwXZVoFmWujp28DTZetnWE3vapK1DlH8HDJ/vugysJ9MRNBWv+yd0J4 1yOGKqngBnc1GBirdHLruTxKgpI8KkBHyMU/Wbd+QMK7Hm+ePsQqmRcbGZ0njrZWIq /6IuGHBzlABvcwfwqtiJTx4drgBrnPkQShSO20G319oW2kBluj1jkgKYUzTvnffJKC EY6+ZpkPIshqz+PG1svitHlhWlywATRXUdEFYZRhnxAilGu4CURUcMJh4YtD4Si1At LK/zPYxx/Sxhg==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SpncJ291Fz6tvZ for <openpgp@ietf.org>; Mon, 11 Dec 2023 17:43:12 +0100 (CET)
Message-ID: <87bd4895386b3a0cd0c62429b0b85df6f1860da2.camel@posteo.de>
From: Stephan Verbücheln <verbuecheln@posteo.de>
To: openpgp@ietf.org
Date: Mon, 11 Dec 2023 16:43:09 +0000
In-Reply-To: <87jzplrtfy.wl-neal@walfield.org>
References: <077dd27cef0c7d3968967fc4c3a880081b8bd9dd.camel@posteo.de> <87jzplrtfy.wl-neal@walfield.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-FZQlLQM3KuNQT825y6vb"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/w-Uu3FJY2sjykm6fPw90u1o0WWc>
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: Mon, 11 Dec 2023 16:43:26 -0000

Hi Neal

Thanks for the clarification. I now got some aspects that I did not get
from reading the RFC section.

Now I agree that this is a useful measure in scenarios where a victim
signs data for the attacker, such as the PGP “certify” operation. It
just does not prevent the signer himself from creating collisions. So
with that, my objections are reduced a lot.

I believe, the following two questions are still worth debating because
the mandatory salt does not come at zero cost.

Is it practically relevant?
Hash algorithms which are vulnerable to collisions should not be used
anyway. SHA-1 was deprecated in 2011, a long time before that attack
was demonstrated.

Does it make sense to have it mandatory or default?
In most cases, PGP users sign their own data (e-mails, software
tarballs etc.). It could nevertheless be default for “certify”
operations.

Regards
Stephan