TLS Session Key Calculator
Count the key material a TLS 1.3 handshake derives — traffic secrets, AEAD keys and IVs — including KeyUpdate rekeys.
Inputs
Key Material per Connection
360bytes
AEAD Key Length
16bytes
AEAD IV Length
12bytes
Traffic Secret Length
32bytes
HKDF Invocations
19
Key Material Derived per Hour
6,179.81MiB
Assessment
128-bit AEAD keys — fine classically, 64-bit under Grover
Step by step
Values used
Cipher suite = TLS_AES_128_GCM_SHA256; KeyUpdate rekeys per connection = 2 rekeys; New connections per second = 5,000 conn/s
TLS Session Key
per direction TLS 1.3 derives one traffic secret (hash length) plus an AEAD key (16 or 32 B) and a 12-byte IV; each KeyUpdate re-derives all of them.
Per-record nonce construction
record nonce = 12-byte write IV XOR the 64-bit record sequence number.
Key Material per Connection
= 360 bytes
AEAD Key Length
= 16 bytes
AEAD IV Length
= 12 bytes
Traffic Secret Length
= 32 bytes
HKDF Invocations
= 19
Key Material Derived per Hour
= 6,179.81 MiB
How it works
TLS 1.3 runs a HKDF-based key schedule: Extract and Expand steps produce handshake and application traffic secrets for each direction, and each secret is expanded into a key and an IV. A KeyUpdate advances the traffic secret and regenerates both, which is how long-lived connections stay inside the AEAD usage limits. Every byte of derived material has to be zeroised and every HKDF call costs CPU, so at tens of thousands of connections per second the key schedule is a measurable part of the TLS budget and of your memory-hygiene obligations.
Formulas
TLS Session Key
per direction TLS 1.3 derives one traffic secret (hash length) plus an AEAD key (16 or 32 B) and a 12-byte IV; each KeyUpdate re-derives all of them.
- traffic secret
- 32 bytes with SHA-256, 48 with SHA-384
- AEAD key
- 16 bytes for AES-128, 32 for AES-256 and ChaCha20
- IV
- Always 12 bytes, XORed with the record sequence number
Per-record nonce construction
record nonce = 12-byte write IV XOR the 64-bit record sequence number.
Frequently Asked Questions
How is TLS Session Key calculated?
per direction TLS 1.3 derives one traffic secret (hash length) plus an AEAD key (16 or 32 B) and a 12-byte IV; each KeyUpdate re-derives all of them. TLS 1.3 runs a HKDF-based key schedule: Extract and Expand steps produce handshake and application traffic secrets for each direction, and each secret is expanded into a key and an IV. A KeyUpdate advances the traffic secret and regenerates both, which is how long-lived connections stay inside the AEAD usage limits.
Why does TLS Session Key matter?
Every byte of derived material has to be zeroised and every HKDF call costs CPU, so at tens of thousands of connections per second the key schedule is a measurable part of the TLS budget and of your memory-hygiene obligations.
What values do I need to enter?
This calculator takes 3 inputs: Cipher suite, KeyUpdate rekeys per connection, New connections per second. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why does the IV stay 12 bytes for AES-256?
The nonce length is a property of GCM, not the key length — SP 800-38D fixes the recommended nonce at 96 bits. TLS 1.3 derives a 12-byte static IV and XORs it with the record sequence number so nonces are unique and never random.