Re: [openpgp] AEAD Chunk Size

Vincent Breitmoser <look@my.amazin.horse> Wed, 27 February 2019 11:25 UTC

Return-Path: <look@my.amazin.horse>
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 0272D130EBB for <openpgp@ietfa.amsl.com>; Wed, 27 Feb 2019 03:25:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVIfGeT2BmVv for <openpgp@ietfa.amsl.com>; Wed, 27 Feb 2019 03:25:41 -0800 (PST)
Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAC5130EB4 for <openpgp@ietf.org>; Wed, 27 Feb 2019 03:25:41 -0800 (PST)
Received: from localhost (dhcp251-23.wlan.rz.tu-bs.de [134.169.251.23]) by mail.mugenguild.com (Postfix) with ESMTPSA id A47285FB11; Wed, 27 Feb 2019 12:25:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1551266738; bh=UeWWbzLG/Jiiv0yjSVHAWIX9OrDrIMqB5zdYYeEKmY4=; h=Date:From:To:Subject:Autocrypt:From; b=fWqJD28sZaO51lJYvHgQoxtSz3SEYFS6dPl7nbx/KOWRGklG4eugbceGhL3aq6UHW AQyV6O8fENCfH6tZg2MeZw4ybRoBfJwC4bON4+Trzaf1xG0gw9/5sqezQHRXdQjYSt 3bvoBfi4HOZArRefNF2zNRdjdpnU1bzkiVYn72Qw=
Message-Id: <F9VLV9HZWH.3RYL3UM3BN873@my.amazin.horse>
In-Reply-To: <87mumh33nc.wl-neal@walfield.org>
References: <87mumh33nc.wl-neal@walfield.org>
Date: Wed, 27 Feb 2019 12:25:38 +0100
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Vincent Breitmoser <look@my.amazin.horse>
To: "Neal H. Walfield" <neal@walfield.org>
Cc: openpgp@ietf.org
Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c=
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/cp36p7Urj5Qv8n4Nee4f1pLJ9Bk>
Subject: Re: [openpgp] AEAD Chunk Size
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 27 Feb 2019 11:25:44 -0000

Thanks for bringing this up, Neal. I do support this motion.

For the record, related merge request is here:
https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/16

 - V


"Neal H. Walfield" <neal@walfield.org> wrote:
> The current version of 4880bis has a chunk size parameter for AEAD:
> 
>   ## AEAD Encrypted Data Packet (Tag 20)
> 
>   ...
> 
>   The body of this packet consists of:
> 
>   ...
> 
>     * A one-octet chunk size.
> 
>   ...
> 
>   The chunk size octet specifies the size of chunks using the
>   following formula (in C), where c is the chunk size octet:
> 
>        chunk_size = ((uint64_t)1 << (c + 6))
> 
>   An implementation MUST support chunk size octets with values from 0
>   to 56.  Chunk size octets with other values are reserved for future
>   extensions.  Implementations SHOULD NOT create data with a chunk
>   size octet value larger than 21 (128 MiB chunks) to facilitate
>   buffering of not yet authenticated plaintext.
> 
>   https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-05#section-5.16
> 
> In other words, chunks can be up to 1 << (56 + 6) = 2^62 bytes large
> (4 exbibytes).
> 
> According to RFC 5116, an AEAD algorithm must not output partially
> decrypted data:
> 
>    If a
>    particular implementation of an AEAD algorithm is requested to
>    process an input that is outside the range of admissible lengths, or
>    an input that is outside the range of lengths supported by that
>    implementation, it MUST return an error code and it MUST NOT output
>    any other information.  In particular, partially encrypted or
>    partially decrypted data MUST NOT be returned.
> 
>    https://tools.ietf.org/html/rfc5116#section-2.1
> 
> Because it is hard to know the context (i.e., the available resources)
> in which a message will be decrypted, it is difficult for an
> implementation to make a reasonable choice when doing the encryption.
> Actually, I'm not aware of any advantages for chunk sizes that are
> larger than a few kilobytes.
> 
> Consequently, I propose not only imposing a reasonable ceiling on the
> chunk size that even small embedded devices with a cortex M0 could
> handle, but to simply fix the parameter to 16 KiB.  It's not clear to
> me that a variable size offers any advantages.  But, there is a clear
> disadvantage: it's unjustified complexity, which is a breeding ground
> for bugs.  Unless someone can justify this added complexity, I see no
> reason to parameterize this.
> 
> (If it is needed, the size could be a function of the actually AEAD
> algorithm, e.g., EAX, OCB, etc.)
> 
> I've attached a patch that makes the proposed change.
> 
> I've spoken with several people including Vincent Breitmoser (Open
> Keychain), Justus Winter & Kai Michaelis (also Sequoia), Phil
> Zimmermann, and Hanno Böck and they all support this proposal.
> 
> Thanks,
> 
> :) Neal
> 
> 
> 
> From efd12443c2da194fdb40eb6f606c9d9bb9c46ddc Mon Sep 17 00:00:00 2001
> From: "Neal H. Walfield" <neal@gnu.org>
> Date: Wed, 27 Feb 2019 11:32:11 +0100
> Subject: [PATCH] Fix the AEAD chunk size to 16 kiByte.
> 
> ---
>  middle.mkd | 21 +++++----------------
>  1 file changed, 5 insertions(+), 16 deletions(-)
> 
> diff --git a/middle.mkd b/middle.mkd
> index 44d1246..4437df7 100644
> --- a/middle.mkd
> +++ b/middle.mkd
> @@ -2694,8 +2694,6 @@ The body of this packet consists of:
>  
>    * A one-octet AEAD algorithm.
>  
> -  * A one-octet chunk size.
> -
>    * A starting initialization vector of size specified by the AEAD
>      algorithm.
>  
> @@ -2716,11 +2714,11 @@ a full authentication tag.
>  
>  For each chunk, the AEAD construction is given the Packet Tag in new
>  format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag),
> -version number, cipher algorithm octet, AEAD algorithm octet, chunk
> -size octet, and an eight-octet, big-endian chunk index as additional
> +version number, cipher algorithm octet, AEAD algorithm octet,
> +and an eight-octet, big-endian chunk index as additional
>  data.  The index of the first chunk is zero.  For example, the
> -additional data of the first chunk using EAX and AES-128 with a chunk
> -size of 64 kiByte consists of the octets 0xD4, 0x01, 0x07, 0x01, 0x10,
> +additional data of the first chunk using EAX and AES-128
> +consists of the octets 0xD4, 0x01, 0x07, 0x01,
>  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, and 0x00.
>  
>  After the final chunk, the AEAD algorithm is used to produce a final
> @@ -2729,16 +2727,7 @@ given the additional data specified above, plus an eight-octet,
>  big-endian value specifying the total number of plaintext octets
>  encrypted.  This allows detection of a truncated ciphertext.
>  
> -The chunk size octet specifies the size of chunks using the following
> -formula (in C), where c is the chunk size octet:
> -
> -        chunk_size = ((uint64_t)1 << (c + 6))
> -
> -An implementation MUST support chunk size octets with values from 0 to
> -56.  Chunk size octets with other values are reserved for future
> -extensions.  Implementations SHOULD NOT create data with a chunk size
> -octet value larger than 21 (128 MiB chunks) to facilitate buffering of
> -not yet authenticated plaintext.
> +The chunk size is 16 kiByte.
>  
>  A new random initialization vector MUST be used for each message.
>  Failure to do so for each message will lead to a catastrophic failure