<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Hi Hal,</div><div dir="ltr"><br></div><div dir="ltr">There is libressl from the OpenBSD team</div><div dir="ltr"><br></div><div dir="ltr"><a href="https://www.libressl.org/">https://www.libressl.org/</a></div><div dir="ltr"><br></div><div dir="ltr">It was forked from openssl in 2014 </div><div dir="ltr"><br></div><div dir="ltr">Mike</div><div dir="ltr"><br><blockquote type="cite">On 16 Jun 2020, at 07:55, Hal Murray via devel <devel@ntpsec.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span></span><br><span>They are up to alpha3. I've been trying it.</span><br><span></span><br><span>I added a tweak to wscript to support this, and some notes in HOWTO-OpenSSL</span><br><span>That recipe also works for getting 1.1.1 on old systems so they can use NTS.</span><br><span></span><br><span>---------</span><br><span></span><br><span>There are several big changes in 3.0.0</span><br><span> The CMAC_* API that we have been using is now DEPRECATED.</span><br><span> The low level crypto stuff that we use has slowed down.</span><br><span> There is a blizzard of shadow warnings for freefunc if Python.h is included.</span><br><span></span><br><span>I added attic/cmac-timing to time the various ways to do the CMAC calculations.</span><br><span>It's also a convenient place to debug the recipe. In addition to the old way, </span><br><span>there is a way that works on both old and new OpenSSL, and another way that </span><br><span>only works with the new code.</span><br><span></span><br><span>The new way has split the setup/init code into two parts. One does the setup </span><br><span>stuff derived from a key. The other initializes the internal data. The </span><br><span>second part is quick. If we can afford the memory for a context for each key, </span><br><span>we can speed up CMAC calculations a whole lot. We should be able to get half </span><br><span>of that speedup on the server by having the transmit side reuse the context </span><br><span>setup by the receive side. But the new way is so slow that even with that </span><br><span>hack, the CMAC calculation much slower than the old code.</span><br><span></span><br><span>---------</span><br><span></span><br><span>I don't understand the shadow warnings. Python.h typedef's freefunc as a </span><br><span>function prototype. OpenSSL uses it as a named parameter in function </span><br><span>prototypes. I'd expect parameter names to be in a different name space from </span><br><span>types and don't see why a parameter name can shadow anything in client code. </span><br><span>(It might be a problem for the implementer, but that's not my problem.)</span><br><span></span><br><span>As you can probably guess, I'm in over my head in this area.</span><br><span></span><br><span>The good news is that the warnings go away if we reverse the order of </span><br><span>including the header files.</span><br><span></span><br><span>------------</span><br><span></span><br><span>The general slowth is annoying but not critical.</span><br><span></span><br><span>Does anybody know of any other crypto libraries we might investigate?</span><br><span></span><br><span></span><br><span></span><br><span>-- </span><br><span>These are my opinions. I hate spam.</span><br><span></span><br><span></span><br><span></span><br><span>_______________________________________________</span><br><span>devel mailing list</span><br><span>devel@ntpsec.org</span><br><span>http://lists.ntpsec.org/mailman/listinfo/devel</span><br></div></blockquote></body></html>