lucky13-type of attack for SHA384 and SHA256
I received a paper which among others describes a lucky13-style attack for HMAC-SHA384 and HMAC-SHA256. This requires access to CPU cache (e.g., via a VM or container), and the attacker to select plaintext (chosen-plaintext attack) in addition to the "standard" lucky13 requirements. It uncovers multiple issues:
- In SHA384 we seem we have used the wrong constants for the counter-measures #455 (closed) (assigned CVE-2018-10845).
- We cap the number of additional blocks processed to 1, enabling exploitation for SHA256 and SHA384 (CVE-2018-10844)
- When hashing additional blocks we don't access the plaintext data at the end of the message, and that can be measured when access to cpu cache is available (CVE-2018-10844)
Note that this attack affects GnuTLS clients and servers which communicate with a peer who does not support the encrypt-then-mac extension. We should consider dropping HMAC-SHA256 and HMAC-SHA384 (already removed in master for different reason) from the default set of ciphersuites in 3.6.x, as they are only used for compatibility with older servers and clients (new should use AEAD or EtM), and provide no significant advantage over HMAC-SHA1 in these cases. We should also consider dropping them all, or part of them (e.g., SHA384) completely from the supported set of ciphersuites.
Should be addressed in:
- 3.6.x
- 3.5.x
- 3.3.x