In TLS1.3 all allowed algorithms included in cipher suites are AEAD, which means they don't just encrypt but they authenticate too (thus if I don't misunderstand, they give not only confidentiality but also integrity/authentication. So, then...why it's necessary to include a Hash algorithm in the cipher suite? I mean...why isn't ChaCha20 (or AES-GCM, etc) enough so Poly1305 (or SHA256, etc) should be necessary?
-
2$\begingroup$ Mostly the same as for AEAD in TLS1.2, which was answered years ago, although 1.3 uses standard HKDF instead of 'custom' PRF: crypto.stackexchange.com/questions/17691/… crypto.stackexchange.com/questions/26410/… security.stackexchange.com/questions/39590/… security.stackexchange.com/questions/115605/… $\endgroup$– dave_thompson_085Commented Nov 24, 2019 at 0:55
-
1$\begingroup$ Basically, the mode of operation is used for the encryption of data. But you need a hash-based functionality for everything that isn't covered by the transmission of data, e.g. in the key agreement. $\endgroup$– tyloCommented Nov 24, 2019 at 19:26
-
$\begingroup$ Thanks to all!!! $\endgroup$– OsquiCommented Nov 24, 2019 at 19:30
2 Answers
From RFC 8446, the hash is used for:
- The transcript hash, covering every message in the handshake to authenticate it during key agreement and certificate verification (§4.4.1).
- Deriving various session keys from raw key agreement material and transcript hash with HKDF (§7.1).
- Deriving key material for protocols based on the key negotiated in a TLS session (RFC 5705).
There are other tools in TLS 1.3 that you didn't list. From section E.1.1. in RFC8446
E.1.1. Key Derivation and HKDF Key derivation in TLS 1.3 uses HKDF as defined in [RFC5869] and its two components, HKDF-Extract and HKDF-Expand.
HKDF is HMAC-based Extract-and-Expand Key Derivation Function and defined in rfc5869
The HMAC requires the Cryptographic Hash algorithm specified in the cipher suite, these are SHA256 or SHA384.