All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: "Jason A . Donenfeld" <Jason@zx2c4.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Stephan Mueller <smueller@chronox.de>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 5/8] lib/crypto: Add SHA3 kunit tests
Date: Thu, 2 Oct 2025 09:07:51 -0700	[thread overview]
Message-ID: <20251002160751.GA1697@sol> (raw)
In-Reply-To: <2636465.1759410347@warthog.procyon.org.uk>

On Thu, Oct 02, 2025 at 02:05:47PM +0100, David Howells wrote:
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > SHA3-386 => SHA3-384
> 
> Hah.  Possibly I'm too practised at writing "386".
> 
> > If these expected outputs are from an external source, then that source
> > needs to be documented.  If they aren't, then the way in which they were
> > generated needs to be easily reproducible and documented, e.g. by adding
> > support for generating them to gen-hash-testvecs.py.
> 
> I generated them with openssl.  I'll add a note in the code.
> 
> > If that's the case, then running "./scripts/crypto/gen-hash-testvecs.py
> > sha3-256 > lib/crypto/tests/sha3_testvecs.h" should reproduce this file
> > exactly.  But it doesn't, so you must have manually edited this file.
> > 
> > It should match exactly.  That can be done by tweaking
> > gen-hash-testvecs.py to use the correct *_DIGEST_SIZE constant and
> > skipping the HMAC test if sha3-256 is requested.
> 
> gen-hash-testvecs.py doesn't know how to handle dashes in the algo name and
> they end up coming in the output as "SHA3-256_DIGEST_SIZE".
> 
> It also generated an HMAC thing despite sha3-256 not having HMAC support, so I
> just trimmed that off.
> 
> Anyway, I can modify the gen script to deal with both of those.

Yes, that's what I'm asking for.

> > >  def hash_final(ctx):
> > > +    if ctx.name == "shake_128":
> > > +        return ctx.digest(16)
> > > +    if ctx.name == "shake_256":
> > > +        return ctx.digest(32)
> > 
> > This addition is unnecessary.
> 
> Well, you can't generate SHAKE128 or SHAKE256 without it as the digest()
> method has a mandatory parameter for XOF algorithms.  This fixes that.

I know, but the script is never actually used with SHAKE128 or SHAKE256.

- Eric

  reply	other threads:[~2025-10-02 16:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-26 14:19 [PATCH v3 0/8] crypto, lib/crypto: Add SHAKE128/256 support and move SHA3 to lib/crypto David Howells
2025-09-26 14:19 ` [PATCH v3 1/8] s390/sha3: Rename conflicting functions David Howells
2025-09-29 11:39   ` Harald Freudenberger
2025-09-26 14:19 ` [PATCH v3 2/8] arm64/sha3: " David Howells
2025-09-26 14:19 ` [PATCH v3 3/8] lib/crypto: Add SHA3-224, SHA3-256, SHA3-384, SHA-512, SHAKE128, SHAKE256 David Howells
2025-09-26 21:09   ` Eric Biggers
2025-09-26 14:19 ` [PATCH v3 4/8] lib/crypto: Move the SHA3 Iota transform into the single round function David Howells
2025-09-26 14:19 ` [PATCH v3 5/8] lib/crypto: Add SHA3 kunit tests David Howells
2025-10-01 16:04   ` Eric Biggers
2025-10-01 16:08     ` Eric Biggers
2025-10-02 13:05     ` David Howells
2025-10-02 16:07       ` Eric Biggers [this message]
2025-09-26 14:19 ` [PATCH v3 6/8] crypto/sha3: Use lib/crypto/sha3 David Howells
2025-09-26 21:25   ` Eric Biggers
2025-09-26 14:19 ` [PATCH v3 7/8] crypto/sha3: Add SHAKE128/256 support David Howells
2025-09-26 21:14   ` Eric Biggers
2025-10-01 13:02     ` David Howells
2025-10-01 15:25       ` Eric Biggers
2025-09-26 14:19 ` [PATCH v3 8/8] crypto: SHAKE tests David Howells
2025-09-26 19:59 ` [PATCH v3 0/8] crypto, lib/crypto: Add SHAKE128/256 support and move SHA3 to lib/crypto Eric Biggers
2025-10-01 15:28   ` Eric Biggers
2025-10-02 13:14     ` David Howells
2025-10-02 16:27       ` Eric Biggers
2025-10-11  0:26         ` Eric Biggers
2025-10-16 12:35         ` David Howells
2025-10-16 14:34           ` David Howells
2025-10-16 14:56             ` Stephan Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251002160751.GA1697@sol \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smueller@chronox.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.