Re: Digest algorithms for Ruby
Thanks everyone, your replies were most helpful. On Sat, 2 Nov 2019 at 06:42, Jordan Brown wrote: > On 10/31/2019 7:35 AM, Viktor Dukhovni wrote: > > My advice would be to avoid specific support for any *particular* digest > algorithm. Instead, provide bindings to: > > - EVP_get_digestbyname(), > - EVP_MD_CTX_create(3), > - EVP_DigestInit_ex(3), > - EVP_DigestUpdate(3), > - EVP_DigestFinal_ex(3), > - EVP_MD_CTX_destroy(3) > > which can they use *any* available digest algorithm (by name). > > > That avoids having *your* software be dependent on the digest algorithms, > but it does so by exporting the dependency out to your caller. > > The bottom line for somebody trying to maintain compatibility is that when > you remove some algorithm X, there's always a risk that something in the > stack - be it software or user configuration - explicitly depends on X and > so will fail on upgrade. > > -- > Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris > >
Regarding interoperability between no-asm and asm enabled
Hi, I am using 'DTLS over SCTP' and the OpenSSL version is 1.1.1c. I compiled OpenSSL with target 'linux-arm64ilp32' on armv8. GCC used is aarch64_be_linux-gnuilp32-gcc. So it is ILP32 and Big-end. I compiled two sets of OpenSSL libraries: 1) OpenSSL with no-asm present 2) OpenSSL with no-asm absent (means, enabled the assembler instruction acceleration) I observed that the DTLS handshake fails when the client with lib 1) and server with lib 2) are run. When client sends the CCS, encrypted_handshake_finish_message, the server sends back the ALERT (Fatal, Illegal parameter). At the server side, when SSL_accept() fails, thr error code is 244 (SSL_R_UNEXPECTED_MESSAGE). Cipher used is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 However, the handshake is success when both client and server use the same lib type, either 1) or 2). This suggests that there is interoperability issue. Does anyone faced this issue? Rgds, Navi
