|
I see. Well, I'll comment here since I don't have a Github presence yet.
I have no issues with using provider-specific param names. But as far as the OpenSSL provider (fips=yes or fips=no), I'd say that most of the digest algorithms are pretty stable by now, especially the old fogies. It would be useful to keep providing the OpenSSL
internal (currently deprecated) state structures, but only as a method of interpreting the internal state after calling for a pointer to it. So as long as I know which digest I'm using, we can still interpret and manually serialize the state data as we have
already been doing, once we get a pointer to it. Just taking a glance at the 3.0.1 source code, I see that MD5, SHAx, and Blake2 seem to still use the deprecated interfaces under the covers.
I suppose MACs can be more complicated, but I'm only asking for digests.
From: Tomas Mraz <tomas@xxxxxxxxxxx>
Sent: Friday, October 25, 2024 1:40 AM
To: openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: Transferring hash state
We have this issue discussing this RFE:
https://gcc02.safelinks.protection.outlook.com/?url="">
Tomas Mraz, OpenSSL
On Fri, 2024-10-25 at 13:32 +1100, Viktor Dukhovni wrote:
> On Thu, Oct 24, 2024 at 09:24:19PM +0000, 'Sands, Daniel N.' via
> openssl-users wrote:
>
> > We have an application that performs hashing across multiple hosts
> > in
> > a kind of round-robin form. In the past, we could reach into
> > whatever
> > hash we were using and pull its state, and write it into the hash
> > state on the next host to continue processing. With the new opaque
> > hash structures, that ability seems to be lost. Is that the case,
> > or
> > is it still somehow possible?
>
> If you're using, e.g., SHA256, and willing to bypass the EVP layer
> abstractions, then the (deprecated, but still available in OpenSSL
> 3.x)
> functions that take a concrete SHA256_CTX admit serialising the
> context,
> because that structure is not opaque.
>
> <openssl/sha.h>
>
> typedef struct SHA256state_st {
> SHA_LONG h[8];
> SHA_LONG Nl, Nh;
> SHA_LONG data[SHA_LBLOCK];
> unsigned int num, md_len;
> } SHA256_CTX;
>
> OSSL_DEPRECATEDIN_3_0 int SHA256_Init(SHA256_CTX *c);
> OSSL_DEPRECATEDIN_3_0 int SHA256_Update(SHA256_CTX *c,
> OSSL_DEPRECATEDIN_3_0 int SHA256_Final(unsigned char *md,
> SHA256_CTX *c);
>
> If you want "algorithm agility", then unless I'm mistaken, I'm afraid
> that indeed the abstract interface currently lacks a way to serialise
> and deserialise the internal state, to allow to move "out of
> process".
> If some day implemented, This would surely require new "provider"
> mechanisms, and would be available only for provider/algorithm
> combinations that support such serialisation. Right now that set of
> provider/algorithm combinations is empty.
>
> --
> Viktor.
>
--
Tomáš Mráz, OpenSSL
--
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe@xxxxxxxxxxx.
To view this discussion visit
https://gcc02.safelinks.protection.outlook.com/?url="">.
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe@xxxxxxxxxxx.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/SA9PR09MB530965CF53570F7DC94234A9DB4F2%40SA9PR09MB5309.namprd09.prod.outlook.com.
|
