TLS Session Key Calculator
Count the key material a TLS 1.3 handshake derives — traffic secrets, AEAD keys and IVs — including KeyUpdate rekeys.
About TLS Session Key Calculator
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.
Worked example
With the default values below, TLS Session Key Calculator returns Key Material per Connection of 360. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Cipher suiteone of TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256
- KeyUpdate rekeys per connectionaccepts 0–100 rekeys
- 2 rekeys
- New connections per secondminimum 1 conn/s
- 5,000 conn/s
Results
- 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
- Assessment
- 128-bit AEAD keys — fine classically, 64-bit under Grover
Step by step
- 1Values used
- 2TLS Session Key
- 3Per-record nonce construction
- 4Key Material per Connection= 360 bytes
- 5AEAD Key Length= 16 bytes
- 6AEAD IV Length= 12 bytes
- 7Traffic Secret Length= 32 bytes
- 8HKDF Invocations= 19
- 9Key Material Derived per Hour= 6,179.81 MiB
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.