Re: [openpgp] v5 Secret-Key Packet Formats

["brian m. carlson" <[e-mail]>]

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