Thanks.
> and a CMAC key using the function EVP_PKEY_new_CMAC_key():
That's the step I was missing. Right in front of my eyes.
I'm still missing something though.
Does this look reasonable:
cipher = EVP_aes_128_cbc();
pkey = EVP_PKEY_new_CMAC_key(NULL, key, keylength, cipher);
ctx
$ valgrind --leak-check=full ./client
==18674== Memcheck, a memory error detector
==18674== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==18674== Using Valgrind-3.16.0.GIT and LibVEX; rerun with -h for copyright
info
==18674== Command: ./client
==18674==
ZS\!Uڃȕe;+UbH1XF
汹S
Could you please try to re-run the client via Valgrind?
On Fri, Jun 12, 2020 at 7:03 AM Xinzhe Wang wrote:
> When KTLS is enabled, multiple client's handshake will lead to unexpected
> eof while reading and data corrupt(possible memory leak).
>
> Tested OpenSSL version: master, 3.0.0-alpha1
> Ke
On 12/06/2020 00:27, Hal Murray wrote:
>
> levi...@openssl.org said:
>> In 1.1.1 and earlier, there is a different idea, using EVP_PKEY routines to
>> "sign" with a MAC. We have a EVP_PKEY to EVP_MAC bridge in 3.0.0 to bridge
>> the gap.
>
> Thanks, but...
>
> The EVP_PKEY seems to assume a
