ietf-openpgp
[Top] [All Lists]

Re: [openpgp] v5 Secret-Key Packet Formats

2018-01-19 17:08:37
On Thu, Jan 18, 2018 at 10:41:47AM +0100, Werner Koch wrote:
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:

--8<---------------cut here---------------start------------->8---
-For each chunk, the AEAD construction is given the packet header,
-version number, cipher algorithm octet, AEAD algorithm octet, chunk size
-octet, and an eight-octet, big-endian chunk index as additional
-data.  The index of the first chunk is zero.
+For each chunk, the AEAD construction is given the Packet Tag, version
+number, cipher algorithm octet, AEAD algorithm octet, chunk size
+octet, and an eight-octet, big-endian chunk index as additional data.
+The index of the first chunk is zero.  Note that the Packet Tag has
+the value 0xd4 and that the length octets are not included because
+they may vary in case of a partial body length.
--8<---------------cut here---------------end--------------->8---

That should be fine.  We detect truncation elsewhere anyway.

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)

It's a good idea to use domain separation to ensure that packets can't
be copied and pasted between packet types.  It prevents cases where
someone accidentally creates a decryption oracle and reuses keys or
passphrases.  The packet tag should be enough for this, since the
authentication tag will flag the failure immediately if it changes.

I tried to model the AEAD authenticated data after TLS, since that has
generally been a successful model that's been resistant to attacks
involving the MAC.  The TLS model is "authenticate the entire packet".

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.

I would just say a hard error is the right thing to do.  Clearly if
there's disagreement, we can't be sure what the sender intended.  It
would be better to fail than produce a bunch of junk data.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

Attachment: signature.asc
Description: PGP signature

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