Hi
Thanks for your informative response but as per my analysis decryption of video is failing at EVP_DecryptFinal api. Is there any api which can be used. Also, hmac apis are depreciated, do I need to replace any apis for hmac. Please provide the solution for this.
Thanks & Regards
Shweta
-----Original Message-----
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Steffen Nurpmeso
Sent: Thursday, January 26, 2023 12:04 AM
To: openssl-users@xxxxxxxxxxx
Subject: [External] Re: Nay
WARNING: This message has originated from an External Source. This may be a phishing email that can result in unauthorized access to Honeywell systems. Please use proper judgment and caution when opening attachments, clicking links or responding.
P.S.
Steffen Nurpmeso wrote in
<20230125002226.WFpe5%steffen@xxxxxxxxxx>:
|As a potentially depressing, disappointing, malicious, bogus |... comment i want to cry out loud that *if* something is | | present for backwards compatibility with OpenSSL prior to | version 3 and is different to the EVP_CIPHER_fetch() | function since it does not attempt to "fetch" an | implementation of the cipher.
|and
...
|then the returned object *should*, in my opinion, have the same |semantics than it had for a quarter of a century (more or less).
|
|And that direct things like EVP_sha256() also are potentially |dead-end "hulls" i find even more terrible, especially given that |they are documented as |
| These functions return a EVP_MD structure that
| contains the implementation of the message digest.
...
And especially because the actual "fetch" is a one-liner
EVP_CIPHER_fetch(NULL,
cipher->nid == NID_undef ? "NULL" : OBJ_nid2sn(cipher->nid), "");
(unless i am mistaken in the loong way to the concrete thing) and several functions like PKCS7_encrypt() do not work with a CIPHER_CTX, and an easy workaround as is possible for digests
#ifdef a_XTLS_CRYPTO_FETCH
a_XTLS__JFETCH:/* C99 */{
EVP_MD_CTX *mdcp;
if((mdcp = EVP_MD_CTX_new()) == NIL)
*mdp = NIL;
else{
if(!EVP_DigestInit_ex(mdcp, *mdp, NIL))
*mdp = NIL;
EVP_MD_CTX_free(mdcp);
}
goto jleave;
}
#endif
is not possible because EncryptInit_ex takes additional parameters that may not be known (easily).
Maybe irony can be found in words as of postfix
Workaround: OpenSSL 3.x EVP_get_digestbyname() can return
lazily bound handles that may fail to work when one attempts
to use them, because no provider search happens until one
constructs an actual operation context. In sufficiently
hostile configurations, Postfix could mistakenly believe
that an algorithm is available, when in fact it is not. A
similar workaround may be needed for EVP_get_cipherbyname().
Fix by Viktor Dukhovni. Files: tls/tls.h, tls/tls_dane.c,
tls/tls_fprint.c, tls/tls_misc.c.
And, finally, how could anyone write a configurator, as is my
link_check tls_blake2 'TLS: BLAKE2 digests' \
'#define mx_XTLS_HAVE_BLAKE2' << \!
#include <openssl/evp.h>
int main(void){
EVP_blake2b512();
EVP_blake2s256();
return 0;
}
!
when the above is, in fact, totally meaningless, and _running_ this thing (as via run_check()) is not possible in cross-compilation scenarios?
Wouldn't it make sense to at least say those direct accessors are guaranteed to return a valid usable object if the above configuration check succeeds and the standard standard OSSL_LIB_CTX is in use (aka has not been set explicitly, or been used explicitily in a _fetch())?
Fine thing with the magic carpet change, but all programs i deal with (aka use) simply need that "old" behaviour, reliably.
Only my one cent.
So i for myself keep the cipher code "as-is", but then do
...looking up configure-time detected arrays of useful things..
..and (new!) set "cp" to the name of the found thing, and jump..
#if defined mx_HAVE_TLS_ALL_ALGORITHMS && !defined a_XTLS_CRYPTO_FETCH
if((cipher = EVP_get_cipherbyname(cp)) != NIL)
goto jleave;
#endif
#ifdef a_XTLS_CRYPTO_FETCH
a_XTLS__JFETCH:
if((cipher = EVP_CIPHER_fetch(NIL, cp, NIL)) != NIL){
*freeit = TRU1;
goto jleave;
}
#endif
..and do a "re-"fetch. Well it seems to work, and the call tree is pretty shallow for the new "freeit" parameter.
This is all dynamic now, a.k.a. the Olymp of programming, but waiting with cheering.
But congratulations for the QUIC implementation again!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off (By Robert Gernhardt)
