[PATCH] lib/crypto: sha1: use put_unaligned_be64() for length encoding

[PATCH] lib/crypto: sha1: use put_unaligned_be64() for length encoding

[Mohamad Raizudeen]

The SHA1 final code in __sha1_final() and hmac_sha1_final() writes the
64-bit message bit length of the SHA1 padding using direct access
pointer casts:

`*(__be64 *)&ctx->buf[SHA1_BLOCK_SIZE - 8] = cpu_to_be64(bitcount);`
`*(__be32 *)&ctx->sha_ctx.buf[SHA1_BLOCK_SIZE - 4] =
	 cpu_to_be32(8 * (SHA1_BLOCK_SIZE + SHA1_DIGEST_SIZE));`

The rest of this file already uses the unaligned access helpers like
get_unaligned_be32() for reading input and put_unaligned_be32() for writing
the digest, for all structured buffer accesses. Replace both casts with
put_unaligned_be64() for consistency.

In hmac_sha1_final(), this also writes the full 64-bit length field
explicitly rather than writing only 32 bits and relying on a preceding
memset() to zero the upper 32 bits. The resulting bytes are identical,
nothing changes functionally.

Signed-off-by: Mohamad Raizudeen <raizudeen.kerneldev@gmail.com>
---
 lib/crypto/sha1.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/crypto/sha1.c b/lib/crypto/sha1.c
index b687b89d97cb..17d97160d578 100644
--- a/lib/crypto/sha1.c
+++ b/lib/crypto/sha1.c
@@ -183,7 +183,7 @@ static void __sha1_final(struct sha1_ctx *ctx, u8 out[SHA1_DIGEST_SIZE])
 		partial = 0;
 	}
 	memset(&ctx->buf[partial], 0, SHA1_BLOCK_SIZE - 8 - partial);
-	*(__be64 *)&ctx->buf[SHA1_BLOCK_SIZE - 8] = cpu_to_be64(bitcount);
+	put_unaligned_be64(bitcount, &ctx->buf[SHA1_BLOCK_SIZE - 8]);
 	sha1_blocks(&ctx->state, ctx->buf, 1);
 
 	for (size_t i = 0; i < SHA1_DIGEST_SIZE; i += 4)
@@ -267,8 +267,8 @@ void hmac_sha1_final(struct hmac_sha1_ctx *ctx, u8 out[SHA1_DIGEST_SIZE])
 	memset(&ctx->sha_ctx.buf[SHA1_DIGEST_SIZE], 0,
 	       SHA1_BLOCK_SIZE - SHA1_DIGEST_SIZE);
 	ctx->sha_ctx.buf[SHA1_DIGEST_SIZE] = 0x80;
-	*(__be32 *)&ctx->sha_ctx.buf[SHA1_BLOCK_SIZE - 4] =
-		cpu_to_be32(8 * (SHA1_BLOCK_SIZE + SHA1_DIGEST_SIZE));
+	put_unaligned_be64((u64)8 * (SHA1_BLOCK_SIZE + SHA1_DIGEST_SIZE),
+			&ctx->sha_ctx.buf[SHA1_BLOCK_SIZE - 8]);
 
 	/* Compute the outer hash, which gives the HMAC value. */
 	sha1_blocks(&ctx->ostate, ctx->sha_ctx.buf, 1);
-- 
2.53.0

Re: [PATCH] lib/crypto: sha1: use put_unaligned_be64() for length encoding

[Simon Richter]

[-- Attachment #1.1: Type: text/plain, Size: 1000 bytes --]

Hi,

On 10/11/26 14:15, Mohamad Raizudeen wrote:

> The rest of this file already uses the unaligned access helpers like
> get_unaligned_be32() for reading input and put_unaligned_be32() for writing
> the digest, for all structured buffer accesses. Replace both casts with
> put_unaligned_be64() for consistency.

These aren't unaligned accesses, though.

> In hmac_sha1_final(), this also writes the full 64-bit length field
> explicitly rather than writing only 32 bits and relying on a preceding
> memset() to zero the upper 32 bits. The resulting bytes are identical,
> nothing changes functionally.

These aren't unaligned either, and the size here is fixed (which is also 
why we don't need to handle the case where the size does not fit into 
the current block).

The get_unaligned and put_unaligned functions aren't used as convenience 
functions, but because the data might actually be unaligned, so we need 
to eat the cost of doing an unaligned access.

    Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] lib/crypto: sha1: use put_unaligned_be64() for length encoding

[Mohamad Raizudeen]

On Sun, Oct 11, 2026 at 03:10:44PM +0900, Simon Richter wrote:
> Hi,
> 
> On 10/11/26 14:15, Mohamad Raizudeen wrote:
> 
> > The rest of this file already uses the unaligned access helpers like
> > get_unaligned_be32() for reading input and put_unaligned_be32() for writing
> > the digest, for all structured buffer accesses. Replace both casts with
> > put_unaligned_be64() for consistency.
> 
> These aren't unaligned accesses, though.
> 
> > In hmac_sha1_final(), this also writes the full 64-bit length field
> > explicitly rather than writing only 32 bits and relying on a preceding
> > memset() to zero the upper 32 bits. The resulting bytes are identical,
> > nothing changes functionally.
> 
> These aren't unaligned either, and the size here is fixed (which is also why
> we don't need to handle the case where the size does not fit into the
> current block).
> 
> The get_unaligned and put_unaligned functions aren't used as convenience
> functions, but because the data might actually be unaligned, so we need to
> eat the cost of doing an unaligned access.
> 
>    Simon

Hi,

Well, you are right. My patch would have added unnecessary overhead on
strict alignment architectures.

Withdrawing this patch.

Thanks,
Mohamad Raizudeen