[PATCH RFC net-next 1/5] tls: add HKDF-Expand-Label for the TLS 1.3 key schedule
Martin Belanger
martin.nvme.dev at gmail.com
Mon Oct 26 04:25:39 PDT 2026
On 10/26/26 03:27, Hannes Reinecke wrote:
> On 10/26/26 1:36 AM, Martin Belanger via B4 Relay wrote:
>> From: Martin Belanger <martin.belanger at dell.com>
>>
>> A TLS 1.3 KeyUpdate derives the next traffic secret, key and IV with
>> HKDF-Expand-Label (RFC 9846, section 7.2). Add the helper for the
>> kernel to do this itself.
>>
>> Only the part of the key schedule after the handshake is needed. The
>> input is a traffic secret, which is already a pseudorandom key, so
>> HKDF-Extract is not needed. Each output is at most Hash.length bytes,
>> so each derivation is a single HMAC with the library SHA-256 or SHA-384
>> functions.
>>
>> Assisted-by: LLM
>> Signed-off-by: Martin Belanger <martin.belanger at dell.com>
>> ---
>> net/tls/Kconfig | 2 ++
>> net/tls/Makefile | 2 +-
>> net/tls/tls.h | 2 ++
>> net/tls/tls_hkdf.c | 82
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 87 insertions(+), 1 deletion(-)
>>
> And another HKDF implementation. Maybe it's time to split if off (again).
> But anyway.
>
Yes. crypto/hkdf.c went away again in 6d888db2cfd9 ("crypto: remove
HKDF library"), when fscrypt and nvme-auth moved to the HMAC library.
tls_hkdf.c follows that pattern. It needs only HKDF-Expand-Label, which
is one HMAC here. If a shared helper is wanted again, I would do it in
a separate series.
Thanks for the review.
Martin
> Reviewed-by: Hannes Reinecke <hare at kernel.org>
>
> Cheers,
>
> Hannes
More information about the Linux-nvme
mailing list