RE: [External] Re: Nay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

-----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.


Steffen Nurpmeso wrote in
 |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.
 |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

    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

  a_XTLS__JFETCH:/* C99 */{
        EVP_MD_CTX *mdcp;

        if((mdcp = EVP_MD_CTX_new()) == NIL)
           *mdp = NIL;
           if(!EVP_DigestInit_ex(mdcp, *mdp, NIL))
              *mdp = NIL;
        goto jleave;

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){
    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;

     if((cipher = EVP_CIPHER_fetch(NIL, cp, NIL)) != NIL){
        *freeit = TRU1;
        goto jleave;

..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!

|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)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux