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)
On Sun, Apr 27, 2025 at 06:11:38AM -0700, Eric Biggers wrote:
>
> By the way, as I mentioned in my cover letter:
>
> For now the SHA-256 library is well-covered by the crypto_shash
> self-tests, but I plan to add a test for the library directly later.
>
> But due to your gratuitous change
On Sun, Apr 27, 2025 at 05:56:43AM -0700, Eric Biggers wrote:
> On Sun, Apr 27, 2025 at 08:41:38PM +0800, Herbert Xu wrote:
> > On Sun, Apr 27, 2025 at 05:35:14AM -0700, Eric Biggers wrote:
> > >
> > > Well, barely a day and you've already ruined my patch series. Now
> > > instead of a
> > > clea
On Sun, Apr 27, 2025 at 08:41:38PM +0800, Herbert Xu wrote:
> On Sun, Apr 27, 2025 at 05:35:14AM -0700, Eric Biggers wrote:
> >
> > Well, barely a day and you've already ruined my patch series. Now instead
> > of a
> > clean design where the crypto_shash API is built on top of the normal
> > lib
On Sun, Apr 27, 2025 at 05:35:14AM -0700, Eric Biggers wrote:
>
> Well, barely a day and you've already ruined my patch series. Now instead of
> a
> clean design where the crypto_shash API is built on top of the normal library
> API (sha256_update() etc.), there's now a special low-level API
> "s
On Sun, Apr 27, 2025 at 02:30:41PM +0800, Herbert Xu wrote:
> Changes in v2:
> - Rebase on top of lib partial block helper series.
> - Restore the block-only shash implementation of sha256.
> - Move the SIMD hardirq test out of the block functions so that
> it is only done for the lib/crypto inte
Changes in v2:
- Rebase on top of lib partial block helper series.
- Restore the block-only shash implementation of sha256.
- Move the SIMD hardirq test out of the block functions so that
it is only done for the lib/crypto interface.
- Split the lib/crypto sha256 module to break cycle in allmod b
On Fri, 25 Apr 2025 at 23:51, Eric Biggers wrote:
>
> Following the example of several other algorithms (e.g. CRC32, ChaCha,
> Poly1305, BLAKE2s), this series refactors the kernel's existing
> architecture-optimized SHA-256 code to be available via the library API,
> instead of just via the crypto
This is based on cryptodev commit bf0b4f15267ca404 plus the series
https://lore.kernel.org/linux-crypto/20250422152716.5923-1-ebigg...@kernel.org/.
It can also be retrieved from:
git fetch
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git sha256-lib-v1
Following the example
13 matches
Mail list logo
