On Sat, Sep 06, 2025 at 02:35:11PM -0700, Eric Biggers wrote:
> This series is targeting libcrypto-next. It can also be retrieved from:
>
> git fetch
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
> curve25519-v2
>
> This series removes the unus
On Mon, Sep 08, 2025 at 06:35:04PM +0200, Jason A. Donenfeld wrote:
> Hi Eric,
>
> Just a small nit -- would you commit this with the subject line all
> lower case, like the other wireguard commits?
Done.
> By the way, I have been reading every single one of your patches. It
> didn't seem like i
On Sat, Sep 06, 2025 at 02:35:18PM -0700, Eric Biggers wrote:
> +static struct kunit_case curve25519_test_cases[] = {
> + KUNIT_CASE(test_curve25519),
> + KUNIT_CASE(test_curve25519_basepoint),
> + {},
> +};
> +
> +static struct kunit_suite curve25519_test_su
KMSAN dependencies internally.
- Add a selection of CRYPTO_LIB_UTILS, since WireGuard directly calls
crypto_memneq(). This gets selected indirectly by
CRYPTO_LIB_CURVE25519 and CRYPTO_LIB_CHACHA20POLY1305 anyway, but it's
best to make this dependency explicit.
Signed-off-by: Er
rom messages in test_curve25519()
- Use NSEC_PER_SEC instead of literal 10
- Added an Acked-by
Eric Biggers (12):
crypto: hisilicon/hpre - Remove unused curve25519 kpp support
crypto: arm/curve25519 - Remove unused kpp support
crypto: powerpc/curve25519 - Remove unused kpp support
crypto: x86/curv
Curve25519 is used only via the library API, not the crypto_kpp API. In
preparation for removing the unused crypto_kpp API for Curve25519,
remove the unused "hpre-curve25519" kpp algorithm.
Cc: Longfang Liu
Cc: Zhiqi Song
Signed-off-by: Eric Biggers
---
drivers/crypto/hisilic
Add a benchmark to curve25519_kunit. This brings it in line with the
other crypto KUnit tests and provides an easy way to measure
performance.
Signed-off-by: Eric Biggers
---
lib/crypto/tests/curve25519_kunit.c | 31 +
1 file changed, 31 insertions(+)
diff --git a
le via the library API.
It's also worth noting that even if the kpp support for Curve25519 comes
back later, there is no need for arch-specific kpp glue code like this,
as a single kpp algorithm that wraps the library API is sufficient.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Kconfig
generic Curve25519 code. And
the Curve25519 functions are very long anyway, so inlining doesn't
matter as much for Curve25519 as it does for some other algorithms.)
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Kconfig | 12 -
arch/arm/crypto/Mak
.
Signed-off-by: Eric Biggers
---
lib/crypto/tests/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/crypto/tests/Kconfig b/lib/crypto/tests/Kconfig
index eaca60d3e0a36..578af717e13a7 100644
--- a/lib/crypto/tests/Kconfig
+++ b/lib/crypto/tests/Kconfig
@@ -11,11
s the same list of test vectors. So they didn't really provide
any additional value.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c |6 -
crypto/testmgr.h | 1225 --
2 files changed, 1231 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/
Move curve25519() and curve25519_generate_public() from curve25519.h to
curve25519.c. There's no good reason for them to be inline.
Signed-off-by: Eric Biggers
---
include/crypto/curve25519.h | 28 +++-
lib/crypto/curve25519.c
le via the library API.
It's also worth noting that even if the kpp support for Curve25519 comes
back later, there is no need for arch-specific kpp glue code like this,
as a single kpp algorithm that wraps the library API is sufficient.
Signed-off-by: Eric Biggers
---
arch/x86/crypto/Kconfig
y
API (), which is a simpler and easier-to-use API
and is the API that is actually being used.
Acked-by: Geert Uytterhoeven # m68k
Signed-off-by: Eric Biggers
---
arch/m68k/configs/amiga_defconfig| 1 -
arch/m68k/configs/apollo_defconfig | 1 -
arch/m68k/configs/atari_defconfig|
ependency, since the Curve25519 code is still entangled with CRYPTO. A
later commit will fix that.
Signed-off-by: Eric Biggers
---
include/crypto/curve25519.h | 2 -
lib/crypto/Makefile | 1 -
lib/crypto/curve25519.c | 3 -
lib/
ssible via the library API.
It's also worth noting that even if the kpp support for Curve25519 comes
back later, there is no need for arch-specific kpp glue code like this,
as a single kpp algorithm that wraps the library API is sufficient.
Signed-off-by: Eric Biggers
---
arch/powerpc
Move curve25519() and curve25519_generate_public() from curve25519.h to
curve25519.c. There's no good reason for them to be inline.
Signed-off-by: Eric Biggers
---
include/crypto/curve25519.h | 28 +++-
lib/crypto/curve25519.c
e25519 remains fully supported
for in-kernel users via the library API (crypto/curve25519.h).
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Kconfig |1 -
arch/arm/crypto/curve25519-glue.c | 77 +-
arch/m68k/configs/amiga_defconfig |1
ependency, since the Curve25519 code is still entangled with CRYPTO. A
later commit will fix that.
Signed-off-by: Eric Biggers
---
include/crypto/curve25519.h | 2 -
lib/crypto/Makefile | 1 -
lib/crypto/curve25519.c | 3 -
lib/
reorganizes the
generic and arch-optimized Curve25519 code to all be located in
lib/crypto/ and built into a single libcurve25519 module.
Eric Biggers (6):
crypto: curve25519 - Remove kpp support
lib/crypto: tests: Migrate Curve25519 self-test to KUnit
lib/crypto: tests: Add Curve25519 benchmark
KMSAN dependencies internally.
- Add a selection of CRYPTO_LIB_UTILS, since WireGuard directly calls
crypto_memneq(). This gets selected indirectly by
CRYPTO_LIB_CURVE25519 and CRYPTO_LIB_CHACHA20POLY1305 anyway, but it's
best to make this dependency explicit.
Signed-off-by: Er
On Mon, Sep 01, 2025 at 01:18:14PM -0700, Eric Biggers wrote:
> diff --git a/lib/crypto/tests/Kconfig b/lib/crypto/tests/Kconfig
> index 7e4e66f30a7a6..c0f3b64489dd6 100644
> --- a/lib/crypto/tests/Kconfig
> +++ b/lib/crypto/tests/Kconfig
> @@ -11,13 +11,14 @@ config CRYPTO_LIB_BLA
generic Curve25519 code. And
the Curve25519 functions are very long anyway, so inlining doesn't
matter as much for Curve25519 as it does for some other algorithms.)
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Kconfig | 12 -
arch/arm/crypto/Mak
Add a benchmark to curve25519_kunit. This brings it in line with the
other crypto KUnit tests and provides an easy way to measure
performance.
Signed-off-by: Eric Biggers
---
lib/crypto/tests/curve25519_kunit.c | 31 +
1 file changed, 31 insertions(+)
diff --git a
On Tue, Aug 05, 2025 at 03:28:48PM -0700, Eric Biggers wrote:
> This series is targeting libcrypto-next and can also be retrieved from:
>
> git fetch
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git md5-lib-v2
>
> This series introduces a library API fo
On Tue, Aug 05, 2025 at 03:28:54PM -0700, Eric Biggers wrote:
> Reimplement crypto/md5.c on top of the new MD5 library functions. Also
> add support for HMAC-MD5, again just wrapping the library functions.
>
> This closely mirrors crypto/sha1.c.
>
> Signed-off-by: Eric Bigger
Reimplement crypto/md5.c on top of the new MD5 library functions. Also
add support for HMAC-MD5, again just wrapping the library functions.
This closely mirrors crypto/sha1.c.
Signed-off-by: Eric Biggers
---
crypto/Kconfig| 2 +-
crypto/md5.c | 359
x27;t have to be run at build time.
Signed-off-by: Eric Biggers
---
lib/crypto/tests/Kconfig| 10 ++
lib/crypto/tests/Makefile | 1 +
lib/crypto/tests/md5-testvecs.h | 186
lib/crypto/tests/md5_kunit.c| 39 +++
4 files changed, 236 inser
code was disabled by default. MD5 still remains
available through crypto_shash, but individual architectures no longer
need to handle it.
Note: to see the diff from arch/sparc/crypto/md5_glue.c to
lib/crypto/sparc/md5.h, view this commit with 'git show -M10'.
Signed-off-by: Eric Biggers
MD5 code was disabled by default. MD5 still remains
available through crypto_shash, but individual architectures no longer
need to handle it.
Signed-off-by: Eric Biggers
---
arch/powerpc/configs/powernv_defconfig| 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
arch/powerpc
was disabled by default. MD5 still remains
available through crypto_shash, but individual architectures no longer
need to handle it.
Note: to see the diff from arch/mips/cavium-octeon/crypto/octeon-md5.c
to lib/crypto/mips/md5.h, view this commit with 'git show -M10'.
Signed-off-by: Er
Since octeon-crypto.c is the only remaining source file in
arch/mips/cavium-octeon/crypto/, move it into its parent directory
arch/mips/cavium-octeon/. Then remove the directory
arch/mips/cavium-octeon/crypto/, including its Makefile.
Signed-off-by: Eric Biggers
---
arch/mips/cavium-octeon
"md5" and "hmac(md5)" crypto_shash algorithms will also be
reimplemented on top of these library functions. For "hmac(md5)" this
will provide a faster, more streamlined implementation.
Signed-off-by: Eric Biggers
---
include/crypto/md5.h | 181 +
ecture-optimized MD5 code, since unfortunately there
were objections to removing it.
Eric Biggers (7):
lib/crypto: md5: Add MD5 and HMAC-MD5 library functions
lib/crypto: mips/md5: Migrate optimized code into library
mips: cavium-octeon: Move octeon-crypto.c into parent dir
lib/crypto:
On Tue, Aug 05, 2025 at 04:17:49PM +0900, Simon Richter wrote:
> Hi,
>
> On 8/5/25 13:58, Eric Biggers wrote:
>
> > What does this have to do with this thread, which is about the PowerPC
> > optimized MD5 code?
>
> Hence the new subject. It is still related to rem
On Tue, Aug 05, 2025 at 08:27:14AM +0200, Christophe Leroy wrote:
> > What? That's crazy. Userspace MD5 code would be faster and more
> > reliable. No need to make syscalls, transfer data to and from the
> > kernel, have an external dependency, etc. Is this the coreutils md5sum?
> > We need to
On Tue, Aug 05, 2025 at 01:49:31PM +0900, Simon Richter wrote:
> Hi,
>
> On 8/5/25 07:59, Eric Biggers wrote:
>
> > > md5sum uses the kernel's MD5 code:
>
> > What? That's crazy. Userspace MD5 code would be faster and more
> > reliable. No need t
On Mon, Aug 04, 2025 at 10:59:01PM +, Eric Biggers wrote:
> On Mon, Aug 04, 2025 at 09:02:27PM +0200, Christophe Leroy wrote:
> >
> >
> > Le 04/08/2025 à 20:09, Eric Biggers a écrit :
> > > On Mon, Aug 04, 2025 at 07:42:15PM +0200, Christophe Leroy wrote:
>
On Mon, Aug 04, 2025 at 09:02:27PM +0200, Christophe Leroy wrote:
>
>
> Le 04/08/2025 à 20:09, Eric Biggers a écrit :
> > On Mon, Aug 04, 2025 at 07:42:15PM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 03/08/2025 à 22:44, Eric Biggers a écr
On Mon, Aug 04, 2025 at 07:42:15PM +0200, Christophe Leroy wrote:
>
>
> Le 03/08/2025 à 22:44, Eric Biggers a écrit :
> > MD5 is insecure, is no longer commonly used, and has never been
> > optimized for the most common architectures in the kernel. Only mips,
> &
On Mon, Aug 04, 2025 at 01:44:21PM +0900, Simon Richter wrote:
> Hi,
>
> On 8/4/25 05:44, Eric Biggers wrote:
>
> > Taken together, it's clear that it's time to retire these additional MD5
> > implementations, and focus maintenance on the MD5 generic C code.
On Sun, Aug 03, 2025 at 05:27:01PM -0500, Segher Boessenkool wrote:
> You are replacing a known-working target implementation by a lower
> performance generic implementation.
That's probably correct, though FWIW there have been quite a few cases
where optimized assembly code in the kernel actually
On Sun, Aug 03, 2025 at 05:07:10PM -0500, Segher Boessenkool wrote:
> On Sun, Aug 03, 2025 at 01:44:29PM -0700, Eric Biggers wrote:
> > MD5 is insecure,
>
> Really? Have you found an attack? Can you explain it to the rest of
> the world?
>
> MD5 is not recommended
Reimplement crypto/md5.c on top of the new MD5 library functions. Also
add support for HMAC-MD5, again just wrapping the library functions.
This closely mirrors crypto/sha1.c.
Signed-off-by: Eric Biggers
---
crypto/Kconfig| 2 +-
crypto/md5.c | 359
x27;t have to be run at build time.
Signed-off-by: Eric Biggers
---
lib/crypto/tests/Kconfig| 10 ++
lib/crypto/tests/Makefile | 1 +
lib/crypto/tests/md5-testvecs.h | 186
lib/crypto/tests/md5_kunit.c| 39 +++
4 files changed, 236 inser
s the flexibility to upgrade to a more modern
algorithm, which I'll be proposing instead.)
As usual, the "md5" and "hmac(md5)" crypto_shash algorithms will also be
reimplemented on top of these library functions. For "hmac(md5)" this
will provide a faster, more streamli
SoCs.
Taken together, it's clear that it's time to retire these additional MD5
implementations, and focus maintenance on the MD5 generic C code.
This commit removes the PowerPC optimized MD5 code.
Signed-off-by: Eric Biggers
---
arch/powerpc/configs/powernv_defconfig | 1 -
ar
SoCs.
Taken together, it's clear that it's time to retire these additional MD5
implementations, and focus maintenance on the MD5 generic C code.
This commit removes the SPARC64 optimized MD5 code.
Signed-off-by: Eric Biggers
---
arch/sparc/crypto/Kconfig| 10 --
arch/sparc/crypt
SoCs.
Taken together, it's clear that it's time to retire these additional MD5
implementations, and focus maintenance on the MD5 generic C code.
This commit removes the Cavium Octeon optimized MD5 code.
Signed-off-by: Eric Biggers
---
arch/mips/cavium-octeon/crypto/Makefile |
Since octeon-crypto.c is the only remaining source file in
arch/mips/cavium-octeon/crypto/, move it into its parent directory
arch/mips/cavium-octeon/. Then remove the directory
arch/mips/cavium-octeon/crypto/, including its Makefile.
Signed-off-by: Eric Biggers
---
arch/mips/cavium-octeon
to implement legacy protocols.
This should again look quite boring and familiar, as it mirrors the
SHA-1 and SHA-2 changes closely. The MD5 changes are quite a bit
simpler, though, since we'll only be supporting the generic C MD5 code.
Of course there's also only one variant of MD5, unlik
On Sat, Jul 12, 2025 at 04:22:51PM -0700, Eric Biggers wrote:
> For 6.17, I'd like to take patches 1-15 at the most. Patches 16-26
> would be for later, and I'll probably resend them individually later for
> subsystem maintainers to take.
FYI, patches 1-15 have been in linux-
On Sun, Jul 13, 2025 at 03:05:16PM +, Elliott, Robert (Servers) wrote:
> > -Original Message-
> > From: Eric Biggers
> > Sent: Saturday, July 12, 2025 6:23 PM
> > Subject: [PATCH 03/26] lib/crypto: sha1: Add SHA-1 library functions
> ...
>
Use the SHA-1 library functions instead of crypto_shash. This is
simpler and faster.
Signed-off-by: Eric Biggers
---
security/keys/trusted-keys/Kconfig| 4 +-
security/keys/trusted-keys/trusted_tpm1.c | 221 --
2 files changed, 35 insertions(+), 190 deletions
level functions sha1_init()
and sha1_update() to get the same result, provided that the resulting
state is used directly, skipping sha1_final().
So, let's do that instead. This will allow removing the low-level API.
Signed-off-by: Eric Biggers
---
net/ipv6/addrconf.c | 23 +++
Signed-off-by: Eric Biggers
---
include/crypto/sha1.h | 10 ---
lib/crypto/sha1.c | 63 ---
2 files changed, 17 insertions(+), 56 deletions(-)
diff --git a/include/crypto/sha1.h b/include/crypto/sha1.h
index 162a529ec8413..34658f4d76e3b 100644
--- a
Use the SHA-1 library instead of crypto_shash. This is simpler and
faster.
Signed-off-by: Eric Biggers
---
drivers/net/ppp/Kconfig| 3 +-
drivers/net/ppp/ppp_mppe.c | 109 +++--
2 files changed, 20 insertions(+), 92 deletions(-)
diff --git a/drivers/net
Use the SHA-1 library functions instead of crypto_shash. This is
simpler and faster.
Signed-off-by: Eric Biggers
---
lib/Kconfig | 3 +--
lib/digsig.c | 46 ++
2 files changed, 7 insertions(+), 42 deletions(-)
diff --git a/lib/Kconfig b/lib
Use the SHA-1 library instead of crypto_shash. This is simpler and
faster.
Signed-off-by: Eric Biggers
---
drivers/gpu/drm/bridge/Kconfig | 3 +--
drivers/gpu/drm/bridge/ite-it6505.c | 33 ++---
2 files changed, 3 insertions(+), 33 deletions(-)
diff --git a
Use the SHA-1 library functions instead of crypto_shash. This is
simpler and faster.
Signed-off-by: Eric Biggers
---
drivers/tee/Kconfig| 3 +--
drivers/tee/tee_core.c | 55 +++---
2 files changed, 10 insertions(+), 48 deletions(-)
diff --git a/drivers
For SCTP authenticated chunks, use the HMAC-SHA1 and HMAC-SHA256 library
functions instead of crypto_shash. This is simpler and faster.
Signed-off-by: Eric Biggers
---
include/net/sctp/auth.h | 12 +--
include/net/sctp/constants.h | 2 -
include/net/sctp/structs.h | 5 --
net/sctp
Use the HMAC-SHA1 and HMAC-SHA256 library functions instead of
crypto_shash. This is simpler and faster.
Signed-off-by: Eric Biggers
---
include/net/seg6_hmac.h | 12 ---
net/ipv6/Kconfig| 6 +-
net/ipv6/seg6.c | 7 --
net/ipv6/seg6_hmac.c| 199
Use the SHA-1 library instead of crypto_shash. This is simpler and
faster.
Signed-off-by: Eric Biggers
---
drivers/nfc/s3fwrn5/Kconfig| 3 +--
drivers/nfc/s3fwrn5/firmware.c | 17 +
2 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/nfc/s3fwrn5/Kconfig
was disabled by default. SHA-1 still
remains available through crypto_shash, but individual architectures no
longer need to handle it.
Signed-off-by: Eric Biggers
---
arch/x86/crypto/Kconfig | 14 -
arch/x86/crypto/Makefile | 3 -
arch/x86/crypto
won't have to be run at build time.
Signed-off-by: Eric Biggers
---
lib/crypto/tests/Kconfig | 10 ++
lib/crypto/tests/Makefile| 1 +
lib/crypto/tests/sha1-testvecs.h | 212 +++
lib/crypto/tests/sha1_kunit.c| 39 ++
4 files changed
sha1_base.h is no longer used, so remove it.
Signed-off-by: Eric Biggers
---
include/crypto/sha1_base.h | 82 --
1 file changed, 82 deletions(-)
delete mode 100644 include/crypto/sha1_base.h
diff --git a/include/crypto/sha1_base.h b/include/crypto
Now that there's a proper SHA-1 library API, just use that instead of
the low-level SHA-1 compression function. This eliminates the need for
bpf_prog_calc_tag() to implement the SHA-1 padding itself. No
functional change.
Signed-off-by: Eric Biggers
---
include/linux/filter.h
SHA-1 code was disabled by default. SHA-1 still
remains available through crypto_shash, but individual architectures no
longer need to handle it.
Note: to see the diff from arch/sparc/crypto/sha1_glue.c to
lib/crypto/sparc/sha1.h, view this commit with 'git show -M10'.
Signed-off-by: Er
ned-off-by: Eric Biggers
---
arch/powerpc/configs/44x/akebono_defconfig| 1 -
arch/powerpc/configs/powernv_defconfig| 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
arch/powerpc/crypto/Kconfig | 16 ---
arch/powerpc/crypto/Makefile
code was disabled by default. SHA-1 still
remains available through crypto_shash, but individual architectures no
longer need to handle it.
Note: to see the diff from arch/mips/cavium-octeon/crypto/octeon-sha1.c
to lib/crypto/mips/sha1.h, view this commit with 'git show -M10'.
Signed-of
. (Support for that has been omitted for now, for
simplicity and because usually it isn't performance-critical.)
To match sha1_blocks(), change the type of the nblocks parameter and the
return value of __sha1_ce_transform() from int to size_t. Update the
assembly code accordingly.
Signed-off-by:
code was disabled by default. SHA-1 still
remains available through crypto_shash, but individual architectures no
longer need to handle it.
Signed-off-by: Eric Biggers
---
arch/s390/configs/debug_defconfig | 1 -
arch/s390/configs/defconfig | 1 -
arch/s390/crypto/Kconfig
as size_t.
Signed-off-by: Eric Biggers
---
arch/arm/configs/exynos_defconfig | 1 -
arch/arm/configs/milbeaut_m10v_defconfig | 2 -
arch/arm/configs/multi_v7_defconfig | 2 -
arch/arm/configs/omap2plus_defconfig | 1 -
arch/arm/configs/pxa_defconfig
ted_tpm1.c. Those are currently using
crypto_shash, but using the library functions would be much simpler.
Signed-off-by: Eric Biggers
---
include/crypto/sha1.h | 118 ++
lib/crypto/sha1.c | 106 -
2 files ch
rypto/sha1_generic.c to crypto/sha1.c, view
this commit with 'git show -M10'.
Signed-off-by: Eric Biggers
---
crypto/Makefile | 2 +-
crypto/sha1.c | 135 ++
crypto/sha1_generic.c | 87
crypto/testmg
Same as sha256 and sha512: Use the state format that the generic partial
block handling code produces, as requested by Herbert, even though this
is applicable only to legacy drivers.
Signed-off-by: Eric Biggers
---
crypto/sha1.c | 66 +++
1 file
Add a library interface for SHA-1, following the SHA-2 one. As was the
case with SHA-2, this will be useful for various in-kernel users. The
crypto_shash interface will be reimplemented on top of it as well.
Signed-off-by: Eric Biggers
---
include/crypto/sha1.h | 60
r the initial introduction of the library.
Signed-off-by: Eric Biggers
---
arch/x86/crypto/sha1_ssse3_glue.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/sha1_ssse3_glue.c
b/arch/x86/crypto/sha1_ssse3_glue.c
index 0a912bfc86c51..826579a7473c4 100644
Rename the existing sha1_init() to sha1_init_raw(), since it conflicts
with the upcoming library function. This will later be removed, but
this keeps the kernel building for the introduction of the library.
Signed-off-by: Eric Biggers
---
include/crypto/sha1.h | 2 +-
kernel/bpf/core.c | 2
th SHA-1 and SHA-2, in the case of some
users that use both algorithms). The diffstat for that part is:
27 files changed, 169 insertions(+), 903 deletions(-)
For 6.17, I'd like to take patches 1-15 at the most. Patches 16-26
would be for later, and I'll probably resend them indi
On Mon, Jun 30, 2025 at 09:06:31AM -0700, Eric Biggers wrote:
> This series is also available at:
>
> git fetch
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
> sha256-lib-cleanup-v2
>
> This series improves the SHA-224 and SHA-256 library code to
Make the export and import functions for the sha224, sha256,
hmac(sha224), and hmac(sha256) shash algorithms use the same format as
the padlock-sha and nx-sha256 drivers, as required by Herbert.
Signed-off-by: Eric Biggers
---
crypto/sha256.c | 95
Add kerneldoc comments, consistent with the kerneldoc comments of the
SHA-384 and SHA-512 API.
Signed-off-by: Eric Biggers
---
include/crypto/sha2.h | 76 +++
1 file changed, 76 insertions(+)
diff --git a/include/crypto/sha2.h b/include/crypto/sha2.h
Remove sha256_is_arch_optimized(), since it is no longer used.
Signed-off-by: Eric Biggers
---
arch/mips/cavium-octeon/crypto/octeon-sha256.c | 6 --
include/crypto/internal/sha2.h | 8
lib/crypto/arm/sha256.c| 7 ---
lib/crypto/arm64
The previous commit made the SHA-256 compression function state be
strongly typed, but it wasn't propagated all the way down to the
implementations of it. Do that now.
Signed-off-by: Eric Biggers
---
.../mips/cavium-octeon/crypto/octeon-sha256.c | 2 +-
include/crypto/internal/s
t more
readable.
Signed-off-by: Eric Biggers
---
lib/crypto/sha256.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/lib/crypto/sha256.c b/lib/crypto/sha256.c
index 68936d5cd7745..808438d4f4278 100644
--- a/lib/crypto/sha256.c
+++ b/lib/crypto/sha256.c
e variable 'sctx' anyway, which suggests that
*_ctx would be the more natural name for the actual struct.
Therefore: update the SHA-224 and SHA-256 APIs, implementation, and
calling code accordingly.
In the new structs, also strongly-type the compression function state.
Signed-off-by: Eri
function.
This renaming also required an update to lib/crypto/arm64/sha512.h,
since sha2-armv8.pl is shared by both SHA-256 and SHA-512.
Signed-off-by: Eric Biggers
---
include/crypto/internal/sha2.h | 6 --
lib/crypto/Kconfig | 8
lib/crypto/arm/Kconfig |
which functions are the same between SHA-224 and SHA-256.
Also, this is a prerequisite for using different context types for each.
Signed-off-by: Eric Biggers
---
include/crypto/sha2.h | 10 --
lib/crypto/sha256.c | 10 ++
2 files changed, 18 insertions(+), 2 deletions(-)
diff
code from purgatory, where it isn't needed
Eric Biggers (14):
libceph: Rename hmac_sha256() to ceph_hmac_sha256()
cxl/test: Simplify fw_buf_checksum_show()
lib/crypto: sha256: Reorder some code
lib/crypto: sha256: Remove sha256_blocks_simd()
lib/crypto: sha256: Add sha224() an
that.
No code changes other than reordering.
Signed-off-by: Eric Biggers
---
include/crypto/sha2.h | 60 +--
lib/crypto/sha256.c | 12 -
2 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/include/crypto/sha2.h b/include/crypto/sha2.h
First, just use sha256() instead of a sequence of sha256_init(),
sha256_update(), and sha256_final(). The result is the same.
Second, use *phN instead of open-coding the conversion of bytes to hex.
Signed-off-by: Eric Biggers
---
tools/testing/cxl/test/mem.c | 21 ++---
1 file
Rename hmac_sha256() to ceph_hmac_sha256(), to avoid a naming conflict
with the upcoming hmac_sha256() library function.
This code will be able to use the HMAC-SHA256 library, but that's left
for a later commit.
Signed-off-by: Eric Biggers
---
net/ceph/messenger_v2.c | 12 ++--
1
Put the IVs before the round constants, since the IVs are used first.
Put __sha512_final() just above sha384_final() and sha512_final(), which
are the functions that call it.
No code changes other than reordering.
Signed-off-by: Eric Biggers
---
lib/crypto/sha512.c | 72
Rename hmac_sha256() to ceph_hmac_sha256(), to avoid a naming conflict
with the upcoming hmac_sha256() library function.
This code will be able to use the HMAC-SHA256 library, but that's left
for a later commit.
Signed-off-by: Eric Biggers
---
net/ceph/messenger_v2.c | 12 ++--
1
First, just use sha256() instead of a sequence of sha256_init(),
sha256_update(), and sha256_final(). The result is the same.
Second, use *phN instead of open-coding the conversion of bytes to hex.
Signed-off-by: Eric Biggers
---
tools/testing/cxl/test/mem.c | 21 ++---
1 file
Make the export and import functions for the sha224, sha256,
hmac(sha224), and hmac(sha256) shash algorithms use the same format as
the padlock-sha and nx-sha256 drivers, as required by Herbert.
Signed-off-by: Eric Biggers
---
crypto/sha256.c | 95
Remove sha256_is_arch_optimized(), since it is no longer used.
Signed-off-by: Eric Biggers
---
arch/mips/cavium-octeon/crypto/octeon-sha256.c | 6 --
include/crypto/internal/sha2.h | 8
lib/crypto/arm/sha256.c| 7 ---
lib/crypto/arm64
his footgun and simplifying the code is well
worth the very small performance cost of doing the check.
Signed-off-by: Eric Biggers
---
include/crypto/internal/sha2.h | 6 --
lib/crypto/Kconfig | 8
lib/crypto/arm/Kconfig | 1 -
lib/crypto/arm/sha25
It appears the legacy export format is intended to have the value of the
bytecount field be block-aligned, so update __crypto_sha512_export() and
__crypto_sha512_import() to match.
Fixes: e62c2fe56418 ("crypto: sha512 - Use same state format as legacy drivers")
Signed-off-by: Er
1 - 100 of 471 matches
Mail list logo
