> suggest wrapping this context and the integrity algs in some kind of conditional I have a couple patches to send the context (which I haven't merged yet, because, similar to what you suggested, I wanted to make sure they were disabled by default). Tentative plan was to have them disabled by default, and sending the new context can be enabled for testing by a module parameter (e.g. "echo 1 > /sys/modules/cifs/parameters/enable_signing_context" or some similar config variable name) On Thu, Oct 15, 2020 at 1:15 PM Tom Talpey <tom@xxxxxxxxxx> wrote: > > On 10/12/2020 5:50 AM, Aurélien Aptel wrote: > > Patch LGTM > > > > Reviewed-by: Aurelien Aptel <aaptel@xxxxxxxx> > > > > Stefan Metzmacher via samba-technical <samba-technical@xxxxxxxxxxxxxxx> > >> This isn't in MS-SMB2 yet. > >> > >> Is this AES_128? > > > > This is returned in latest Windows Server Insider builds but it's not > > documented yet. > > > > https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver > > > > I've asked dochelp about it during the SDC plugfest and they gave me > > this: > > > > The new ContextType is: > > SMB2_SIGNING_CAPABILITIES 0x0008 > > The Data field contains a list of signing algorithms. > > • It adds a new negotiate context, which enables SMB to decouple signing algorithms from dialects. E.g. if both client and server supports it, a session may use HMAC-SHA256 with SMB 3.1.1. > > • It adds the AES-GMAC algorithm. > > > > SigningAlgorithmCount (2 bytes): Count of signing algorithms > > SigningAlgorithms (variable): An array of SigningAlgorithmCount 16-bit integer IDs specifying the supported signing algorithms. > > > > The following IDs are assigned: > > 0 = HMAC-SHA256 > > 1 = AES-CMAC > > 2 = AES-GMAC > > > > > > I've been CCed in a Microsoft email thread later on and it seems to be > > unclear why this was missed/wasn't documented. Maybe this is subject to > > change so take with a grain of salt. > > Just curious if you've heard back on this. Insider builds will sometimes > support things that don't make it to the release. Even Preview docs can > change. However, AES_GMAC has been on the radar since 2015 (*) so > perhaps the time has come! > > I'd suggest wrapping this context and the integrity algs in some kind of > conditional, in case this is delayed... > > Tom. > > (*) slide 29+ > https://www.snia.org/sites/default/files/SDC15_presentations/smb/GregKramer_%20SMB_3-1-1_rev.pdf -- Thanks, Steve