linux-kernel - Re: [PATCH] crypto: crct10dif

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: <CAMj1kXHAvD9DRb_Qry===C4Hg-DeT6rN0HzWLcB3dCr+eNug+w@mail.gmail.com>
Date: Thu, 6 Feb 2025 19:04:38 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org, 
	dm-devel@...ts.linux.dev, Mikulas Patocka <mpatocka@...hat.com>
Subject: Re: [PATCH] crypto: crct10dif - remove from crypto API

On Thu, 6 Feb 2025 at 18:40, Eric Biggers <ebiggers@...nel.org> wrote:
>
> From: Eric Biggers <ebiggers@...gle.com>
>
> Remove the "crct10dif" shash algorithm from the crypto API.  It has no
> known user now that the lib is no longer built on top of it.  It has no
> remaining references in kernel code.  The only other potential users
> would be the usual components that allow specifying arbitrary hash
> algorithms by name, namely AF_ALG and dm-integrity.   However there are
> no indications that "crct10dif" is being used with these components.
> Debian Code Search and web searches don't find anything relevant, and
> explicitly grepping the source code of the usual suspects (cryptsetup,
> libell, iwd) finds no matches either.  "crc32" and "crc32c" are used in
> a few more places, but that doesn't seem to be the case for "crct10dif".
>
> crc_t10dif_update() is also tested by crc_kunit now, so the test
> coverage provided via the crypto self-tests is no longer needed.
>
> Also note that the "crct10dif" shash algorithm was inconsistent with the
> rest of the shash API in that it wrote the digest in CPU endianness,
> making the resulting byte array differ on little endian vs. big endian
> platforms.  This means it was effectively just built for use by the lib
> functions, and it was not actually correct to treat it as "just another
> hash function" that could be dropped in via the shash API.
>
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>
> ---
>
> I'm planning to take this via the crc tree.
>
>  arch/mips/configs/decstation_64_defconfig     |   1 -
>  arch/mips/configs/decstation_defconfig        |   1 -
>  arch/mips/configs/decstation_r4k_defconfig    |   1 -
>  crypto/Kconfig                                |   9 -
>  crypto/Makefile                               |   2 -
>  crypto/crct10dif_generic.c                    | 168 ----------
>  crypto/tcrypt.c                               |   8 -
>  crypto/testmgr.c                              |   7 -
>  crypto/testmgr.h                              | 288 ------------------
>  include/linux/crc-t10dif.h                    |   3 -
>  .../testing/selftests/arm64/fp/kernel-test.c  |   1 -
>  11 files changed, 489 deletions(-)
>  delete mode 100644 crypto/crct10dif_generic.c
>

Reviewed-by: Ard Biesheuvel <ardb@...nel.org>