Here is my proposal to include AES-256 as a mandatory-to-implement algorithm and to promote its use as discussed in #74.
I tried to consider all cases and find the best balance between forcing (and migrating to) AES-256 and interoperability with the older specs (RFC4880, Crypto Refresh).
Cases to consider are:
Encrypting to a v4 certificate with a PQ/T encryption subkey
Encrypting to a v4 certificate with only traditional keys
Encrypting to a v6 certificate with any PQ(/T) key.
Encrypting to a v6 certificate without any PQ(/T) key.
Encrypting to certificates that explicitly indicate AES-128 or AES-256 support
Encrypting to certificates that do not indicate AES-128 or AES-256 support
Encrypting to any combination of the cases above
Another important aspect: If all involved parties use PQ(/T) keys, then AES-256 will be supported (and hopefully favored) by every party. To further push AES-256, I have added the following sentence to the security considerations:
An implementation SHOULD use AES-256 in the case of a v1 SEIPD packet, or AES-256 and OCB in the case of a v2 SEIPD packet, if all recipients indicate support for it (explicitly or implicitly).
The reason is that when carelessly implementing the specification, an implementation might otherwise choose to take the simple way of always encrypting via AES-128, even if every recipient uses the "Level 5" PQ algorithms.
Please also comment on:
The place where the text is added and the names of the sections
Is there a better place to state Implementations MUST implement AES-256?
If we want to ask for opinions on the mailing list, the argument is: AES-256 is the obvious choice and this will result in everyone using PQ(/T) + AES-256 in the long run. We are committed to AES-256 anyway by the KEM construction.
Here is my proposal to include
AES-256
as a mandatory-to-implement algorithm and to promote its use as discussed in #74. I tried to consider all cases and find the best balance between forcing (and migrating to) AES-256 and interoperability with the older specs (RFC4880, Crypto Refresh).Cases to consider are:
Another important aspect: If all involved parties use PQ(/T) keys, then AES-256 will be supported (and hopefully favored) by every party. To further push AES-256, I have added the following sentence to the security considerations:
The reason is that when carelessly implementing the specification, an implementation might otherwise choose to take the simple way of always encrypting via AES-128, even if every recipient uses the "Level 5" PQ algorithms.
Please also comment on:
Implementations MUST implement AES-256
?If we want to ask for opinions on the mailing list, the argument is:
AES-256
is the obvious choice and this will result in everyone using PQ(/T) +AES-256
in the long run. We are committed toAES-256
anyway by the KEM construction.