On 6/14/2020 2:54 AM, Dr. Matthias St. Pierre wrote:
> I don't see any reason to change our code, IMHO the clash is Python's
> fault: it declares a global typedef with a short name that has no
> python-specific prefix.
That is indeed rude, but the symbol could equally well have been
introduced by
Quick forst answer, EVP_MAC_CTX is a typedef of struct evp_mac_ctx_st,
which you find in crypto/evp/evp_local.h. It's quite small (smaller
than EVP_MD_CTX and EVP_PKEY_CTX):
struct evp_mac_ctx_st {
EVP_MAC *meth; /* Method structure */
void *data;
In general, things have slowed down.
The new EVP_MAC code takes 3 times as long as the old CMAC code on 1.1.1.
The new PKEY code takes twice as long as the old CMAC code on 1.1.1
The one ray of hope is that the API for EVP_MAC has split the part of the
setup that uses the key out of the init rou
Thanks. It's working now. Timings soon.
The first paragraph in the man page for EVP_DigestSign and friends says:
The EVP signature routines are a high level interface to digital signatures.
Input data is digested first before the signing takes place.
Down at the bottom, under CMAC, it says:
On Sun, 14 Jun 2020 07:16:27 +0200,
Hal Murray wrote:
>
> I can't get CMAC to work via PKEY. I get the same error on 1.1.1g and 3.0.0
>
> I'm using a cipher that works with the CMAC interface.
>
> Can anybody see what I'm missing?
Yup. It's designed to work with the set of functions EVP_Diges
> Does my test program do anything interesting on your system?
No. Except for compiling with warnings ;-)
> Python has:
> typedef void (*freefunc)(void *);
>
> That looks weird to me, but I'm not a language guy.
That's simply a C type definition for a pointer type named `freefunc`, which
can h
