Hi!
The protection of secret keys usning AEAD has this requirement:
If the string-to-key usage octet is 253, the encrypted MPI values are
encrypted as one combined plaintext exactly as an AEAD Encrypted Data
packet with a chunk size octet of 10 would be. This implicit chunk
^^^^^^^^^^^^^^^^^^^^^^
size octet is included in the normal calculations of additional data.
Given chunk_size = ((uint64_t)1 << (c + 6)) this works only for keys
requiring less than 64 KiByte for the secret parameters. This may not
be enough in the future and thus I suggest to increase the default chunk
size. A value of 20 would allow for 64 MiByte which should be enough,
but 25, resulting in 2^31 would be more logical.
However, there is a practical problem using chunks for secret key (and
also with Symmetric-Key Encrypted Session Key Packets): we need to run
two AEAD encryptions for those commonly short key packets because our
description of the AEAD says:
After the final chunk, the AEAD algorithm is used to produce a final
authentication tag encrypting the empty string. This AEAD instance
is 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.
This is overhead in the implementation and the specification (question
of the default chunk size). I would prefer that we remove the use of
the chunked AEAD encryption from Secret-Key and Symmetric-Key Encrypted
Session Key Packets. Thus instead of
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.
we make use of the parameters already in the Secret-Key Packet:
* [Optional] If string-to-key usage octet was 255, 254, or 253, a one-
octet symmetric encryption algorithm.
* [Optional] If string-to-key usage octet was 253, a one-octet AEAD
algorithm.
[...]
* [Optional] If secret data is encrypted (string-to-key usage
octet not zero), an Initial Vector (IV) of the same length as
the cipher's block size.
The IV already matches our requirement for EAX and for OCB we would set
its LSByte to zero. The description of the AEAD mode needs to be
changed to explain the chunked and the non-chunked mode.
What do you think?
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpkGie7VZuWd.pgp
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp