PATCH: Padding bug in cSHAKE-128/256
Jonathan Plata
jonathan.plata at lightshipsec.com
Wed Sep 9 16:12:25 CEST 2026
Hello!
cshake_input_s()'s padlen computation,
padlen = ctx->blocksize - (len_written % ctx->blocksize);
does not handle the case where len_written is already an exact
multiple of ctx->blocksize: the modulo evaluates to 0, so padlen
comes out as ctx->blocksize (a full block) instead of 0. SP 800-185's
bytepad (sec. 2.3.3) specifies padding with zero bytes only until the
total length becomes a multiple of the rate -- when it already is,
no padding bytes should be added at all.
The bug results in a full extra block of zero bytes added to the
Keccak sponge, producing a wrong cSHAKE digest whenever the encoded
N (function-name string) + S (customization string) length lands
exactly on a rate boundary (168 bytes for cSHAKE128, 136 for
cSHAKE256).
Concretely: cSHAKE128 with an empty N and a 161-byte S
(2-byte rate prefix + 2-byte encode_string(empty N) + 3-byte
encode_string(S) length-prefix + 161 == 168 == the cSHAKE128 rate)
triggers it; cSHAKE256 with an empty N and a 129-byte S hits the
same condition against its 136-byte rate.
Found via NIST ACVP cSHAKE-128/256 conformance vectors: a fixture
covering random S lengths reliably produces a wrong digest at S = 161
(cSHAKE128) and S = 129 (cSHAKE256), and only those lengths (adjacent
lengths pass), consistent with this exact rate-boundary condition.
Confirmed against libgcrypt 1.11.2 and 1.12.0 (unchanged between the
two).
Signed-off-by: Jonathan Plata <jonathan.plata at lightshipsec.com>
---
cipher/keccak.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cipher/keccak.c b/cipher/keccak.c
index a0ba1fbb..1351da16 100644
--- a/cipher/keccak.c
+++ b/cipher/keccak.c
@@ -1694,7 +1694,7 @@ cshake_input_s (KECCAK_CONTEXT *ctx, const void *s, unsigned int s_len,
keccak_write (ctx, s, s_len);
len_written += buf[0] + 1 + s_len;
- padlen = ctx->blocksize - (len_written % ctx->blocksize);
+ padlen = (ctx->blocksize - (len_written % ctx->blocksize)) % ctx->blocksize;
memset (buf, 0, padlen);
keccak_write (ctx, buf, padlen);
}
--
2.34.1
[cid:image001.png at 01DD4040.AC77CD40]
Jonathan Plata | Software Developer
Lightship Security, Inc.
Tel: 512-362-6594
https://lightshipsec.com<https://lightshipsec.com/>
This email and attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee, you may not disseminate, distribute or copy this email. Please notify the sender immediately if you have received this email in error and delete it from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20260909/fab954a6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4162 bytes
Desc: image001.png
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20260909/fab954a6/attachment.png>
More information about the Gcrypt-devel
mailing list