Hello!
On Jan 18, 2018, at 12:41, Werner Koch <wk(_at_)gnupg(_dot_)org> 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
o(_dot_)nickolay(_at_)gmail(_dot_)com
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp