On Tue, Apr 29, 2025 at 07:38:49PM -0700, Eric Biggers wrote:
>
> Nothing requires that the export formats be consistent, but also the fact that
> padlock-sha uses a weird format in the first place is an artificial problem
> that
> you introduced just a couple weeks ago. And even if we *must* use
On Wed, Apr 30, 2025 at 10:27:15AM +0800, Herbert Xu wrote:
> On Tue, Apr 29, 2025 at 09:57:49AM -0700, Eric Biggers wrote:
> >
> > To be clear, the objections I have on your v2 patchset still hold. Your
> > unsolicited changes to my patches add unnecessary complexity and redundancy,
> > make the
On Tue, Apr 29, 2025 at 09:57:49AM -0700, Eric Biggers wrote:
>
> To be clear, the objections I have on your v2 patchset still hold. Your
> unsolicited changes to my patches add unnecessary complexity and redundancy,
> make the crypto_shash API even harder to use correctly, and also break the
> b
On Mon, Apr 28, 2025 at 01:17:02PM +0800, Herbert Xu wrote:
> Changes in v3:
> - Add shash sha256-lib/sha224-lib to provide test coverage for libsha256.
>
> This is based on
>
> https://patchwork.kernel.org/project/linux-crypto/list/?series=957558
>
> Original description:
>
> Following t
Changes in v3:
- Add shash sha256-lib/sha224-lib to provide test coverage for libsha256.
This is based on
https://patchwork.kernel.org/project/linux-crypto/list/?series=957558
Original description:
Following the example of several other algorithms (e.g. CRC32, ChaCha,
Poly1305, BLAKE2s)
