linux-kernel - Re: [RFC] ksmbd: Deprecate MD5 support and enhance AES-GCM for SMB 3.1.1 compliance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKYAXd_ZG-ngCCtnG_Uxm=CHkWS6x+=JzM9TXpxGUiH-A7j1TQ@mail.gmail.com>
Date: Tue, 16 Sep 2025 18:47:52 +0900
From: Namjae Jeon <linkinjeon@...nel.org>
To: Yunseong Kim <ysk@...lloc.com>
Cc: Steve French <smfrench@...il.com>, linux-cifs@...r.kernel.org, 
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] ksmbd: Deprecate MD5 support and enhance AES-GCM for SMB
 3.1.1 compliance

On Tue, Sep 16, 2025 at 8:07 AM Yunseong Kim <ysk@...lloc.com> wrote:
>
> Hi all,
Hi Yunseong,
>
> I'm looking into contributing to the ksmbd crypto module, specifically
> around crypto handling in crypto_ctx.c. I wanted to send this RFC to gauge
> interest and get feedback before preparing patches.
>
> First, regarding MD5 support: The current code includes HMAC-MD5
> (via crypto_alloc_shash("hmac(md5)")) which appears to be for legacy SMB1
> compatibility. SMB1 is widely deprecated due to security issues, and MD5
> itself is vulnerable to collision attacks, making it unsuitable for modern
> use. I propose deprecating or removing this support entirely, perhaps with
> a config option (e.g., CONFIG_KSMBD_LEGACY_SMB1) for those who absolutely
> need it, but defaulting to off. This would align ksmbd with security best
> practices, similar to how Windows has disabled SMB1 by default.
Steve answered it.
>
> Second, for SMB 3.1.1 compliance: The code already supports AES-GCM via
> crypto_alloc_aead("gcm(aes)"), but to fully adhere to the spec (MS-SMB2),
> we should explicitly handle AES-128-GCM as the default cipher, with
> AES-256-GCM as an optional stronger variant. AES-256-GCM isn't mandatory
> but is recommended for higher security (e.g., in Windows Server 2022+).
This cipher array in SMB2_ENCRYPTION_CAPABILITIES is ordered by
the client's preference, with the most preferred cipher at the beginning and
the least preferred at the end. This allows the client to signal its
ideal choice
to the server.
The server chooses the first cipher in the client's array that it also supports.
Are you saying that the ksmbd server does have to choose AES-256-GCM
if it is not the first cipher in the client's array ?
>
> This would involve:
>  - Adding key length checks and setkey logic in the caller side
>    (e.g., negotiate or session setup).
>  - Updating the negotiate context to include cipher selection
>    (0x0001 for AES-128-GCM, 0x0002 for AES-256-GCM).
I'm not sure what you're trying to change. Are you trying to change a macro
defined in smb2pdu.h?

>  - Potentially separating signing (AES-CMAC) from encryption ciphers for
>    clarity.
>
> Is this direction worth pursuing? I'd like to prepare patches for review
> if there's consensus. Any thoughts on priorities, potential pitfalls, or
> related work in progress?
Could you elaborate more about the 3 items you suggested ?
>
> Thanks for your time.
Thanks!
>
> Yunseong