[openpgp] SEIPDv1 algorithm obfuscation when using persistent symmetric keys

Daniel Huigens <d.huigens@protonmail.com> Mon, 26 January 2026 17:42 UTC

Return-Path: <d.huigens@protonmail.com>
X-Original-To: openpgp@mail2.ietf.org
Delivered-To: openpgp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id AAAD7AD4380F for <openpgp@mail2.ietf.org>; Mon, 26 Jan 2026 09:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxmT4cZH7spa for <openpgp@mail2.ietf.org>; Mon, 26 Jan 2026 09:42:55 -0800 (PST)
Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch [79.135.106.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 22655AD4380A for <openpgp@ietf.org>; Mon, 26 Jan 2026 09:42:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1769449368; x=1769708568; bh=7XSaoKccLc39jIujaU5BVMpbhS6iMix5rKfKnXdG8QY=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=Jv7gICDE1vJXQml6yg5pgx1PaJPysCXFJExYewAOvUwZDlc9r1fdjzN0b4f3IvF0W fHo5t0Zx3lc1IB8fU+c96CPj9wjkRLG8hkFSnkPQkdzuAprxSQsjhnQPicpddnk76r G3//Q2QaPEP8jA5SefqV9It13CdJo9dEkSV8H2nRJf145AWvVrBd0Q/y2j+y0LNhsP ODSe/hWpDmCFOws9r165+4/AT9i3Dm1q0ODcwDNZlJirOPVgsWx+hdbu14xk8IWdGx /SON3JPrWPB5VkD2N99o7OYz4LwRsBr/Af8sjNwCQXFLpLuZACKfNUDM6fHJA3hxcX 56AFTZzh4v7OA==
Date: Mon, 26 Jan 2026 17:42:44 +0000
To: IETF OpenPGP WG <openpgp@ietf.org>
From: Daniel Huigens <d.huigens@protonmail.com>
Message-ID: <bjPZ8UJ_FSaCQGBoQyNY9UKBPeAGYvjKXNgnAAS3o2tH3EDfJ72huCjlRApuD2DYG3C3HC_dunAAIQupQ6tYYPKlvwyKY8rzD2MlK2D3ZNM=@protonmail.com>
Feedback-ID: 2934448:user:proton
X-Pm-Message-ID: ad7916befc2bce4d7e9dfaaa99de256930773f3d
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: MAH6LRBHCOUVDKORD6ED7UKTXQKP3L4P
X-Message-ID-Hash: MAH6LRBHCOUVDKORD6ED7UKTXQKP3L4P
X-MailFrom: d.huigens@protonmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [openpgp] SEIPDv1 algorithm obfuscation when using persistent symmetric keys
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/iG4cNcM9Usbs8Oc-29QHIkYVadk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

Hi all,

In the meeting today I said that for v3 PKESKs using a persistent
symmetric key, we should add a cleartext symmetric algorithm ID
indicating the algorithm used by the following SEIPDv1 packet,
like we did in X25519 and X448.

In those algorithms, we also mandated for this algorithm to be AES,
to prevent algorithm confusion attacks. However, in the case of
persistent symmetric keys, there is actually a use case for allowing
other algorithms, namely if you're re-encrypting session keys of old
messages that use a different algorithm. So, we should make sure that
the algorithm ID is covered by the integrity tag, either by adding it
to the HKDF info or additional data, or by just encrypting it together
with the session key, as we do in ECDH and RSA.

The latter may be preferable in this case, because we may not want to
reveal if a message is encrypted using IDEA or TripleDES or so, in case
one of those algorithms is ever broken. There's also no significant
downside to doing so as AEAD algorithms accept any plaintext length,
unlike AES-KW.

In addition to that, ECDH allows you to hide the session key length
using padding, to prevent distinguishing between AES-128 and AES-256,
for example. Is that something we should care about here? If so,
we could allow padding the session key with zeros, or so.

(I don't personally think that that's super important, but I'd hate for
someone to claim that symmetrically re-encrypting a session key is ever
a downgrade, for example.)

Best,
Daniel