ietf-openpgp
[Top] [All Lists]

Re: [openpgp] AEAD Chunk Size

2019-02-27 15:34:40
Hi all,

We (Sunny Rajan and I) definitely agree with reducing the range of allowed 
sizes, because both 4 exabyte chunks and large messages composed of 64-byte 
chunks are clearly not optimal.

In our AEAD implementation for OpenPGP.js we settled on a default `c` of 12 
rather than 8 after some performance benchmarking showed that 256 kiB chunks 
were more performant for the most common message sizes. Our result was specific 
to the web crypto API, and therefore specific to OpenPGP.js, but in general 
libraries may want to use different default sizes depending on implementation 
details like this.

So ideally we’d prefer to keep the size byte, but to shrink its range in both 
directions. For example, the RFC could state that the chunk SHOULD be 16 kiB 
(or 256 kiB, hint hint), but decryption MUST be available for `c` values 
between 8-12 inclusive. This would also allow us to be backwards-compatible 
with messages that have already been created following the current version of 
the draft, which do exist given the benefit that AEAD provides and that 
OpenPGP.js has supported the current draft in experimental mode for most of the 
last year. 


Regards,

Bart and Sunny


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, February 27, 2019 3:25 AM, Vincent Breitmoser 
<look@my.amazin.horse> wrote:





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(_at_)walfield(_dot_)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(_at_)gnu(_dot_)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


openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
<Prev in Thread] Current Thread [Next in Thread>