Re: [openpgp] v5 Secret-Key Packet Formats

Nickolay Olshevsky <> Thu, 18 January 2018 11:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E231E12D871 for <>; Thu, 18 Jan 2018 03:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 EfLj3UHIBZeh for <>; Thu, 18 Jan 2018 03:38:51 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA8A712D80F for <>; Thu, 18 Jan 2018 03:38:50 -0800 (PST)
Received: by with SMTP id f11so11711297wre.4 for <>; Thu, 18 Jan 2018 03:38:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:mime-version:subject:date:references:to:in-reply-to :message-id; bh=j48sBDWwBFW4I/C7veULWc9FXeW7rLL+sZunCiaFjD8=; b=KAr4oqOqs+Suqklarw7HOM0Lw14VrtpAxRwwvDXL+m7hRYBvwk+My3dFy4Xn2ByU0H QM6Gba828cqrPls2HMGNe0u6c9q6qWTJt+YYRzV8Berj1Lr02OEnqFRpCvNoaa5diaoo W4zMCEicrp65T56a8tWHruVstgV+ugDuzZ8CLJqxWthPsMwhIDHQfHhVm6VCfnRFlErI adkAE8pnlmQPLpI3gjjAW6mpn/5vgFuHYOsr5wADepl1GpgpgHcBcnMNfLxF2tw65DaR Tz3kAdsLYoeZW6pMYoT231g/dSCh+fylcmfiLVkMQl5L6LwuQXrutTNIh231PrdhUkU8 eVbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:mime-version:subject:date:references :to:in-reply-to:message-id; bh=j48sBDWwBFW4I/C7veULWc9FXeW7rLL+sZunCiaFjD8=; b=FQPIz5wWLX/J2cHIWl9eCAVZLvz5c8B7wpq6We1cPLMNyEWGbne9QKu7ng+SUrccQ6 RNf7Zbo3gAxxW3dC0RhWAlz41nLT0pXpe7Msr8rG2KOW7lodzQm77UCib7LABn6Zt/t1 CVZjxUdzuBAB3sSN4l9RBHI2fkXgGuJmRYXoNcgdyDqiS67UneuDH2ie845IUInb/JyJ ywA+uSDGp1qBE/D98C12kEGgPlYNZuFltgeoYDHLEK5KdQSho1TV7/KNrwiOejOD/myJ g/C2yTnSPhLUELOUhiCRlBZ6D1MBkslECOWdrv1lt5pHMqANzMwii6C5R7EvbFThSHK2 /kOw==
X-Gm-Message-State: AKwxytfGIY7rbaWUD4JLf9ywcOxfplqhjd46Fhy8elUrQN9H9LAvdMfv GGh4rOaPxsp424JbJ7TbLMKhPKih
X-Google-Smtp-Source: ACJfBovmHYSX8K5Ba/exSnVPf12oQl1fizbHjFvTmKg8a4Hb/GAnhEUXQaDjbLhwCz1vTUH6QICPfQ==
X-Received: by with SMTP id 47mr6172080wry.227.1516275528835; Thu, 18 Jan 2018 03:38:48 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id p32sm11068805wrc.9.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jan 2018 03:38:47 -0800 (PST)
Sender: Nickolay Olshevsky <>
From: Nickolay Olshevsky <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E6472E7F-9CFF-4BEB-9426-F03DE823820F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 18 Jan 2018 14:38:43 +0300
References: <> <> <> <> <>
To: IETF OpenPGP <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [openpgp] v5 Secret-Key Packet Formats
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jan 2018 11:38:53 -0000


> On Jan 18, 2018, at 12:41, Werner Koch <> wrote:
> I have not seen other comments but let me prepare a patch to use
> non-chunked AEAD for non-bulk data.
> What I noticed in the AEAD mode:
> 1. There is a problem including the entire packet header in the
>   additional data: When using partial length encoding we would need to
>   use the first partial length here.  gpg uses a a pipeline of
>   functions as data structure.  Thus the encryption layer does not know
>   how the next function down the line will block the data to emit the
>   partial length encoding.  Sure this can be hacked around but it would
>   be ugly.  Thus I propose this change:

Would like to add that I got the same problem that you described during implementation of the AEAD.
With partial packet lengths you’d need to cache first partial chunk on the encryption layer to set the additional data.
It can be worked around but removing packet’s length from ad will make things easier without loosing any security properties.
So agree with the proposed changes.

> 2. The above immediately raises the question why we need the Packet Tag
>   at all.  After all it will be a constant (the AEAD packet requires a
>   new style CTB and thus there is only one encoding).  I assume you did
>   this to prepare against a future rollback attack in case we ever
>   introduce a new style AEAD encryption.  But then, why do we have the
>   version number as first item in the AEAD packet?  It can serve the
>   same purpose.  Or is this to distinguish between AEAD used for bulk
>   encryption and secret key encryption?  What packet tag would we use
>   for the latter (with old-style CTB we can have several encodings)?
>   Shouldn't we either drop the packet header from the additional data
>   or can we define fixed values depending on the use like:
>     0xd4 := AEAD Encrypted Data Packet  (tag 20)
>     0xc3 := SKESK (Symmetric-Key Encrypted Session Key Packet, tag 3)
>     0xc5 := Secret-Key Packet (tag 5) and Secret-Subkey Packet (tag 7)

Also agree - this will make things more clear. And should not make an impact on the security as well.

> 3. The AEAD Encrypted Data Packet specifies the cipher algorithm to use.
>   The old encryption modes had no way to specify the algorithm.
>   Instead they take the algorithm either from the SKESK or the PKESK
>   (Public-Key Encryption Session Key Packet, tag 1).  For simple
>   encryption without even an SKESK it is implementation defined how to
>   get the algorithm.
>   I like that algorithm id in the AEAD packet.  But should we specify
>   what to do on a conflict and whether it is allowed that the SKESK
>   uses a different algorithm than that in the AEAD packet?  I currently
>   print a warning and continue but I am not sure whether this is really
>   needed.  The potential for a conflict has always been in OpenPGP: A
>   faulty implementation may encrypt to several keys giving different
>   algorithms in each PKESK and thus not all recipients would be able to
>   decrypt the message.  I am not ware of such bug, though.

Yep, some statement like ‘symmetric algorithm in previous v4 SKESK/v3 PKESK packets should be ignored for AEAD packet’ will make things more clear.
However, should it be allowed to use v4 SKESK with AEAD encrypted data packet?

Best regards,
	Nickolay Olshevsky