Re: crypto/sha3-buffer: Add support for OpenSSL.

On 04/09/2025 06:20, Collin Funk wrote: Bruno Haible writes: Collin Funk wrote: 256 bytes seems like enough for the foreseeable future. I agree: that's more than 3x the 72 bytes that it currently needs. I think it is okay to leave the abort () calls for EVP_DigestFinal_ex and EVP_DigestUp

Re: crypto/sha3-buffer: Add support for OpenSSL.

Collin Funk wrote: > > max_align_t evp_ctx_buffer[256 / sizeof (max_align_t)]; > > I had assumed that 256 bytes would be aligned everywhere, but > max_align_t seams more robust, thanks. The alignment of an array of N elements with base type T is the same as the alignment of T. A compiler is fre

Re: crypto/sha3-buffer: Add support for OpenSSL.

Bruno Haible writes: > Collin Funk wrote: >> 256 bytes seems like enough for the foreseeable future. > > I agree: that's more than 3x the 72 bytes that it currently needs. > >> I think it is okay to leave the abort () calls for EVP_DigestFinal_ex >> and EVP_DigestUpdate which seem like they shoul

Re: crypto/sha3-buffer: Add support for OpenSSL.

On Thu, Sep 4, 2025 at 1:26 AM Collin Funk wrote: > Simon Josefsson writes: > > > Collin Funk writes: > > > >> Second, I used xalloc-die as a conditional dependency. This is because > >> the EVP functions are documented as returning 0 on failure. In practice, > >> I can only see this being the

Re: crypto/sha3-buffer: Add support for OpenSSL.

Pádraig Brady writes: > A minor naming thing is the openssl docs say: > > "The EVP_MD_CTX_create() and EVP_MD_CTX_destroy() functions > were renamed to EVP_MD_CTX_new() and EVP_MD_CTX_free() in OpenSSL 1.1.0, > respectively." > > So it's probably best to use EVP_MD_CTX_new() rather than EVP_MD_

Re: crypto/sha3-buffer: Add support for OpenSSL.

On 06/09/2025 03:32, Collin Funk wrote: Hi Pádraig, Collin Funk writes: So in summary, I'd revert the previous patch, and we'll figure out how to proceed from there. Thanks, I'll have a look later today. I'll probably just move SHA-3 to returning bool for errors (e.g. OOM). In coreutils we

Re: crypto/sha3-buffer: Add support for OpenSSL.

A minor naming thing is the openssl docs say: "The EVP_MD_CTX_create() and EVP_MD_CTX_destroy() functions were renamed to EVP_MD_CTX_new() and EVP_MD_CTX_free() in OpenSSL 1.1.0, respectively." So it's probably best to use EVP_MD_CTX_new() rather than EVP_MD_CTX_create(). You already check for

Re: crypto/sha3-buffer: Add support for OpenSSL.

On 05/09/2025 05:06, Collin Funk wrote: Pádraig Brady writes: Would it be better to call EVP_MD_CTX_init() rather than memset() ? Or even simpler, remove the explicit init and use EVP_DigestInit() rather than EVP_DigestInit_ex(), which the docs imply does an implicit init of the ctx. The Ope

Re: crypto/sha3-buffer: Add support for OpenSSL.

Hi Pádraig, Collin Funk writes: >> So in summary, I'd revert the previous patch, >> and we'll figure out how to proceed from there. > > Thanks, I'll have a look later today. I'll probably just move SHA-3 to > returning bool for errors (e.g. OOM). In coreutils we can xalloc_die, in > libraries th

Re: crypto/sha3-buffer: Add support for OpenSSL.

On Fri, Sep 5, 2025 at 11:10 AM Pádraig Brady wrote: > On 05/09/2025 05:06, Collin Funk wrote: > > Pádraig Brady writes: > > > >> Would it be better to call EVP_MD_CTX_init() rather than memset() ? > >> Or even simpler, remove the explicit init and use EVP_DigestInit() > >> rather than EVP_Diges

Re: crypto/sha3-buffer: Add support for OpenSSL.

Pádraig Brady writes: > Wow the openssl docs are bad. Looking at the source I see: My thoughts were the same, but I did not want to be rude to the openssl folks. :) > On the create side we have: > > EVP_MD_CTX_create = EVP_MD_CTX_new() + EVP_MD_CTX_init() > EVP_MD_CTX_new = malloc() + memse

Re: crypto/sha3-buffer: Add support for OpenSSL.

Pádraig Brady writes: > Would it be better to call EVP_MD_CTX_init() rather than memset() ? > Or even simpler, remove the explicit init and use EVP_DigestInit() > rather than EVP_DigestInit_ex(), which the docs imply does an implicit > init of the ctx. The OpenSSL API naming convention isn't my

Re: crypto/sha3-buffer: Add support for OpenSSL.

Simon Josefsson writes: > Collin Funk writes: > >> Second, I used xalloc-die as a conditional dependency. This is because >> the EVP functions are documented as returning 0 on failure. In practice, >> I can only see this being the case for EVP_MD_CTX_create, but that >> should be rare (e.g. OOM)

Re: crypto/sha3-buffer: Add support for OpenSSL.

On 02/09/2025 07:27, Collin Funk wrote: Hi, Here is a patch to add OpenSSL support for SHA-3 using the EVP API. There are two things I am not 100% happy with, but I do not see a way around. First, we must call EVP_MD_CTX_create to malloc an EVP_MD_CTX. This is because an EVP_MD_CTX field cannot

Re: crypto/sha3-buffer: Add support for OpenSSL.

Collin Funk writes: > Second, I used xalloc-die as a conditional dependency. This is because > the EVP functions are documented as returning 0 on failure. In practice, > I can only see this being the case for EVP_MD_CTX_create, but that > should be rare (e.g. OOM). I would rather not change the p

Re: crypto/sha3-buffer: Add support for OpenSSL.

Collin Funk wrote: > 256 bytes seems like enough for the foreseeable future. I agree: that's more than 3x the 72 bytes that it currently needs. > I think it is okay to leave the abort () calls for EVP_DigestFinal_ex > and EVP_DigestUpdate which seem like they should never fail outside of > progra

Re: crypto/sha3-buffer: Add support for OpenSSL.

On Tue, Sep 2, 2025 at 1:16 PM Pádraig Brady wrote: > On 02/09/2025 07:27, Collin Funk wrote: > > Here is a patch to add OpenSSL support for SHA-3 using the EVP API. > > There are two things I am not 100% happy with, but I do not see a way > > around. > > > > First, we must call EVP_MD_CTX_create

Re: crypto/sha3-buffer: Add support for OpenSSL.

Hi Collin, > But now I realize that we cannot use xalloc_die > here. I just noticed the following: > > $ gnulib-tool --create-testdir --dir testdir1 crypto/sha3 > gnulib-tool: warning: module crypto/sha3 depends on a module with an > incompatible license: xalloc-die > > I rather keep th

Re: crypto/sha3-buffer: Add support for OpenSSL.

Jeffrey Walton writes: > On Tue, Sep 2, 2025 at 1:16 PM Pádraig Brady wrote: > >> On 02/09/2025 07:27, Collin Funk wrote: >> > Here is a patch to add OpenSSL support for SHA-3 using the EVP API. >> > There are two things I am not 100% happy with, but I do not see a way >> > around. >> > >> > Fir

Re: crypto/sha3-buffer: Add support for OpenSSL.

ctx): Just call sha3_finish_ctx similar to the other crypto + modules. + (sha3_finish_ctx): Remove call to EVP_MD_CTX_free. Call + EVP_DigestFinal_ex. + crypto/sha3-buffer: Add support for OpenSSL. * lib/sha3.c (DEFINE_SHA3_INIT_CTX, sha3_read_ctx, sha3_finish_ctx) (DEFINE_SHA3_BUFFER, sha3_process_byt

Re: crypto/sha3-buffer: Add support for OpenSSL.

l have to do. I don't think it is worth the effort for a seperate *-lgpl module. Pushed the attached which also fixes the memory leak that others noticed. Collin >From a351f5c211db7197bf48fd4b87c71338d7ab6a1f Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Mon, 1

Re: crypto/sha3-buffer: Add support for OpenSSL.

On 2025-09-02 09:25, Collin Funk wrote: But I am cheap You're not as cheap as UCLA. My GNU/Linux desktop there is still based on an AMD Phenom II X4 910e (released 2010). No AVX of any flavor though it does support the same SSE2 that came out with the Pentium 4 in the year 2000. And don't

Re: crypto/sha3-buffer: Add support for OpenSSL.

Hi Jeffrey, Jeffrey Walton writes: > SHA3 uses Keccak core. Keccak is hardware accelerated for AVX2 and AVX512; > not SSE2, SSE4.2 and friends. In contrast, SHA2 is accelerated using SSE2. > See . > > Maybe the test machine lacks AVX

Re: crypto/sha3-buffer: Add support for OpenSSL.

On Tue, Sep 2, 2025 at 2:27 AM Collin Funk wrote: > Hi, > > Here is a patch to add OpenSSL support for SHA-3 using the EVP API. > There are two things I am not 100% happy with, but I do not see a way > around. > > First, we must call EVP_MD_CTX_create to malloc an EVP_MD_CTX. This is > because an

Re: crypto/sha3-buffer: Add support for OpenSSL.

Collin Funk wrote: > +Link: > +$(LIB_CRYPTO) > + Due to the added dependency on 'xalloc-die', which depends on 'gettext-h', we also need this line: $(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise > @@ -24,7 +24,15 @@ check_PROGRAMS += test-sha3-224-buffer test-sha3-256-buffer > chec

crypto/sha3-buffer: Add support for OpenSSL.

01 Message-ID: <1cbaff1c43fecf206b1d7ab56509d48be0d35d2c.1756794420.git.collin.fu...@gmail.com> From: Collin Funk Date: Mon, 1 Sep 2025 22:57:22 -0700 Subject: [PATCH] crypto/sha3-buffer: Add support for OpenSSL. * lib/sha3.c (DEFINE_SHA3_INIT_CTX, sha3_read_ctx, sha3_finish_ctx) (DEFINE_SHA3_BUFFER,