Thanks for the quick response Matt.
Is there any specific reason why it was designed that way in 1.1.1?
It looks little odd that we need a non-NULL EVP_cipher object even though
we do not use it/need it.
I am looking for support for ARM architecture. I can't wait till 3.0.
Is there any chance we m
Hi
Can any guide me how to use fips api in openssl?
I try to use like below but it always returns null.
ctx = EVP_CIPHER_CTX_new() ;
ciph = EVP_CIPHER_fetch(NULL, "aes-128-cbc", "fips=yes") ;
I am doubting fips provider is not loaded.
Regards
Manish
On 2020-01-13 11:23:35 [+], Matt Caswell wrote:
> The current behaviour is that the first key share we see that also
> exists in our supported groups list is the one that we use. There isn't
> a way at the moment to configure things in order to specify a preference
> order.
>
> https://github.
On Friday, 10 January 2020 23:41:20 CET, Sebastian Andrzej Siewior wrote:
Hi,
gnutls-cli sends by default (in the supported groups extension)
`secp256r1' first and later `x25519'. The key_share extension contains a
key for both types. The server has both types configured both groups and
`x25519'
On 13/01/2020 06:20, Phani 2004 wrote:
> Hi Team,
>
> I am trying to add support on an hardware engine for aes-cbc-hmac-sha1.
> I have observed that currently aes-cbc-hmac-sha1 is supported only for
> x86 architecture.
> "EVP_aes_128_cbc_hmac_sha1" api returns NULL for non-x86 platforms. The
>
On 10/01/2020 22:41, Sebastian Andrzej Siewior wrote:
> gnutls-cli sends by default (in the supported groups extension)
> `secp256r1' first and later `x25519'. The key_share extension contains a
> key for both types. The server has both types configured both groups and
> `x25519' comes first.
>