ietf-openpgp
[Top] [All Lists]

Re: [openpgp] v5 Secret-Key Packet Formats

2018-01-18 05:38:58
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