Re: [openpgp] Signing of literal data packet [was: Re: Disadvantages of Salted Signatures]

Andrew Gallagher <andrewg@andrewg.com> Tue, 02 January 2024 00:55 UTC

Return-Path: <andrewg@andrewg.com>
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 3AE4CC14F5FD for <openpgp@ietfa.amsl.com>; Mon, 1 Jan 2024 16:55:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewg.com
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 nEA3LBolkAPS for <openpgp@ietfa.amsl.com>; Mon, 1 Jan 2024 16:55:02 -0800 (PST)
Received: from fum.andrewg.com (fum.andrewg.com [135.181.198.78]) (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 43C05C14F5FB for <openpgp@ietf.org>; Mon, 1 Jan 2024 16:55:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1704156898; bh=donEY8rfm7hzaF8DsrTEi8RV6oCzWA5yZViT2oruPo8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=J7BnbAI3l0xgbuvlK1a0kVKtxl5ClL80YOP0e3Dz0XiTI5VMeTdEKrlwJVYtm9Rnc ckcvn5xhimPqfa70kZLf9D5+xOTZ2zpmqzDNWmQxbp1qwUpc4fey+2Hrzid7GdNuss ibZMVrkGO+xDo370NO7lHnKWoPqTBQIYVv/JBGdVX2s7f1I+duJ51zxRdTaqE4fJIM 8jReVDh+xCMupDajyc3PIoJPoBlqjFd4wLSAfXU4LQ4+35QfzKhck5giyxZ7Mh0tPk xhgb12FHmFLBc00QZGFVP/sIZRP3C6oeWH9Sazsn8RWi+pnhJmofX5Ec5bqo9Xpyak em528Z+p26RLQ==
Received: from smtpclient.apple (serenity [IPv6:fc93:5820:7349:eda2:99a7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by fum.andrewg.com (Postfix) with ESMTPSA id 6CC0B5DC2A; Tue, 2 Jan 2024 00:54:58 +0000 (UTC)
From: Andrew Gallagher <andrewg@andrewg.com>
Message-Id: <FB0B9D50-06EF-407C-BF0E-A5BF3E7773DD@andrewg.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_B21410C8-CCB7-48A0-81F0-C7B779181942"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Tue, 02 Jan 2024 00:54:40 +0000
In-Reply-To: <74B3BAF7-5158-4054-93BA-2FEE9D0FBC82@andrewg.com>
Cc: Werner Koch <wk@gnupg.org>, Heiko Schäfer <heiko.schaefer@posteo.de>, Kai Engert <kaie@kuix.de>
To: "openpgp\\\\@ietf.org" <openpgp@ietf.org>
References: <871qb46hau.fsf@jacob.g10code.de> <74B3BAF7-5158-4054-93BA-2FEE9D0FBC82@andrewg.com>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/7rZHbvDGmBzbqBhxxntbu6fge_4>
Subject: Re: [openpgp] Signing of literal data packet [was: Re: 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: Tue, 02 Jan 2024 00:55:07 -0000

On 30 Dec 2023, at 11:00, Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org> wrote:
> 
> On 29 Dec 2023, at 17:37, Werner Koch <wk@gnupg.org> wrote:
>> 
>> Right, and this means that it does not fix the long standing bug that
>> the creation date, mode, and filename was not signed.  In LibrePGP
>> (i.e. rfc4880bis/crypto-refresh up to summer 2021) this was fixed.
> 
> In that case why not define the Literal Data Meta Hash subpacket for v6 sigs? Librepgp already defines it for v4 sigs.
> 
> In addition, if we allowed a nonzero (0x1?) value in the first byte of the subpacket to indicate that the rest of the packet contains a copy of the metadata verbatim (unhashed), we regain the ability to detach and reattach sigs, save ourselves a redundant extra hash calculation, and if the filename is short we even save a couple of bytes on the wire (compared to hashed metadata).

I have fleshed out the above idea and published it as a new Internet-Draft here:

https://datatracker.ietf.org/doc/draft-gallagher-openpgp-literal-metadata/

(@chairs: can you please add this to the list of WG documents?)

tl;dr: there is a leading zero byte in the Literal Data Meta Hash subpacket which is presumably there to allow for future versioning. So I have defined both an encoding/version 0 that is wire-identical to the subpacket defined in librepgp for enhanced v4 sigs, and an encoding/version 1 that contains the same data but unhashed. An unhashed encoding allows for lossless reattachment of detached signatures, and one fewer hash calculation.

This subpacket could then be used in both v4 and v6 sigs to add the missing functionality defined in librepgp v5 sigs. With no functionality differences remaining between v5 and v6 sigs, there is no justification to have them both, and with no difference in sig formats there is no reason to have two key versions either. This will allow us to reunify the public key and signature formats between crypto-refresh and librepgp.

It is open to further improvement: for example I would prefer not to define both hashed and unhashed encodings of the same subpacket - if we could agree to standardise on the unhashed encoding, we can leave encoding/version 0 reserved. But that’s not a blocker.

The differing AEAD packets are outside the scope of this proposal, but we can come back to them later.

A