Re: Query regarding adding support aes-cbc-hmac-sha1 on non x86 platform through engine

2020-01-13 Thread Phani 2004
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

Using EVP api in fips mode (openssl3.0)

2020-01-13 Thread Manish Patidar
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

Re: Enforcing group / key_share order in TLS1.3

2020-01-13 Thread Sebastian Andrzej Siewior
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. > >

Re: Enforcing group / key_share order in TLS1.3

2020-01-13 Thread Hubert Kario
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

Re: Query regarding adding support aes-cbc-hmac-sha1 on non x86 platform through engine

2020-01-13 Thread Matt Caswell
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

Re: Enforcing group / key_share order in TLS1.3

2020-01-13 Thread Matt Caswell
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. >