OpenSSL 3.0.0
Hal Murray
hmurray at megapathdsl.net
Tue Jun 16 06:54:57 UTC 2020
They are up to alpha3. I've been trying it.
I added a tweak to wscript to support this, and some notes in HOWTO-OpenSSL
That recipe also works for getting 1.1.1 on old systems so they can use NTS.
---------
There are several big changes in 3.0.0
The CMAC_* API that we have been using is now DEPRECATED.
The low level crypto stuff that we use has slowed down.
There is a blizzard of shadow warnings for freefunc if Python.h is included.
I added attic/cmac-timing to time the various ways to do the CMAC calculations.
It's also a convenient place to debug the recipe. In addition to the old way,
there is a way that works on both old and new OpenSSL, and another way that
only works with the new code.
The new way has split the setup/init code into two parts. One does the setup
stuff derived from a key. The other initializes the internal data. The
second part is quick. If we can afford the memory for a context for each key,
we can speed up CMAC calculations a whole lot. We should be able to get half
of that speedup on the server by having the transmit side reuse the context
setup by the receive side. But the new way is so slow that even with that
hack, the CMAC calculation much slower than the old code.
---------
I don't understand the shadow warnings. Python.h typedef's freefunc as a
function prototype. OpenSSL uses it as a named parameter in function
prototypes. I'd expect parameter names to be in a different name space from
types and don't see why a parameter name can shadow anything in client code.
(It might be a problem for the implementer, but that's not my problem.)
As you can probably guess, I'm in over my head in this area.
The good news is that the warnings go away if we reverse the order of
including the header files.
------------
The general slowth is annoying but not critical.
Does anybody know of any other crypto libraries we might investigate?
--
These are my opinions. I hate spam.
More information about the devel
mailing list