[v1,0/3] SMB3.11 preauth integrity

Hi,

This patchset implements pre-authentification signing in which is
mandatory in SMB3.11 (packet signing never worked for 3.11 in cifs.ko
before this).

The main difference is that the signing key is derived from hashing
previous requests and responses. This was partially implemented by
Steve some time ago (the preauth hash buffers were already in the
server and session structures).

The mechanism is well described in the SMB3.11 presentation given at
SDC 2015 (slides are availaible here [1]).

Since this requires a new hashing alg (SHA512) I've tried to clean up
some of the crypto code by refactoring shash & sdesc memory management
in separate functions. Much more readable now :)

1: https://www.snia.org/sites/default/files/SDC15_presentations/smb/GregKramer_%20SMB_3-1-1_rev.pdf

Aurelien Aptel (3):
  CIFS: refactor crypto shash/sdesc allocation&free
  CIFS: add sha512 secmech
  CIFS: implement v3.11 preauth integrity

 fs/cifs/Kconfig         |  1 +
 fs/cifs/cifsencrypt.c   | 85 +++++++------------------------------------
 fs/cifs/cifsfs.c        |  1 +
 fs/cifs/cifsglob.h      |  7 +++-
 fs/cifs/cifsproto.h     |  5 +++
 fs/cifs/link.c          | 27 +++-----------
 fs/cifs/misc.c          | 54 +++++++++++++++++++++++++++
 fs/cifs/smb2misc.c      | 64 ++++++++++++++++++++++++++++++++
 fs/cifs/smb2pdu.c       | 25 +++++++++++++
 fs/cifs/smb2pdu.h       |  1 +
 fs/cifs/smb2proto.h     |  5 +++
 fs/cifs/smb2transport.c | 97 +++++++++++++++++++++----------------------------
 fs/cifs/smbencrypt.c    | 27 +++-----------
 fs/cifs/transport.c     | 17 +++++++++
 14 files changed, 245 insertions(+), 171 deletions(-)

Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
for the series.

Sadly this collides with my compounding series   so I will have to rebase :-(



On Sat, Feb 17, 2018 at 4:19 AM, Aurelien Aptel <aaptel@suse.com> wrote:
> Hi,
>
> This patchset implements pre-authentification signing in which is
> mandatory in SMB3.11 (packet signing never worked for 3.11 in cifs.ko
> before this).
>
> The main difference is that the signing key is derived from hashing
> previous requests and responses. This was partially implemented by
> Steve some time ago (the preauth hash buffers were already in the
> server and session structures).
>
> The mechanism is well described in the SMB3.11 presentation given at
> SDC 2015 (slides are availaible here [1]).
>
> Since this requires a new hashing alg (SHA512) I've tried to clean up
> some of the crypto code by refactoring shash & sdesc memory management
> in separate functions. Much more readable now :)
>
> 1: https://www.snia.org/sites/default/files/SDC15_presentations/smb/GregKramer_%20SMB_3-1-1_rev.pdf
>
> Aurelien Aptel (3):
>   CIFS: refactor crypto shash/sdesc allocation&free
>   CIFS: add sha512 secmech
>   CIFS: implement v3.11 preauth integrity
>
>  fs/cifs/Kconfig         |  1 +
>  fs/cifs/cifsencrypt.c   | 85 +++++++------------------------------------
>  fs/cifs/cifsfs.c        |  1 +
>  fs/cifs/cifsglob.h      |  7 +++-
>  fs/cifs/cifsproto.h     |  5 +++
>  fs/cifs/link.c          | 27 +++-----------
>  fs/cifs/misc.c          | 54 +++++++++++++++++++++++++++
>  fs/cifs/smb2misc.c      | 64 ++++++++++++++++++++++++++++++++
>  fs/cifs/smb2pdu.c       | 25 +++++++++++++
>  fs/cifs/smb2pdu.h       |  1 +
>  fs/cifs/smb2proto.h     |  5 +++
>  fs/cifs/smb2transport.c | 97 +++++++++++++++++++++----------------------------
>  fs/cifs/smbencrypt.c    | 27 +++-----------
>  fs/cifs/transport.c     | 17 +++++++++
>  14 files changed, 245 insertions(+), 171 deletions(-)
>
> --
> 2.12.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ronnie sahlberg <ronniesahlberg@gmail.com> writes:
> Sadly this collides with my compounding series   so I will have to rebase :-(

Yes I suspected that, sorry :/

Hopefully it shouldn't be too hard to rebase:

* The new function to update the hash called before and after
  sending/receiving a packet expects no rfc length.

* And it's only called for requests&responses happening before Tree
  Connects so I think we can also assume no compounded packets.

Hope that helps
Cheers,