Proposal: Remove bundled libaes_siv, use OpenSSL native AES-SIV

[Hal Murray]

Apologies for not responding to your previous message yet.  I've got some 
stuff typed in, but I'm crappy at my time management anyway and got 
sidetracked on the Pi-3 issue.  (It's not ours.)  This area is one of the 
items that was big enough that I was going to split it out from the email 
I'm working on.

So here goes...

Another reason for using the OpenSSL API is that there are newer AEAD 
modes that end up with shorter packets.

I'll be happy if any fixes in this area have a configure time switch to 
use the old code.

There are 2 reasons to keep the old code.  It's much faster and it works 
with FIPS.

-------

On faster.

It's just one of the areas I'm interested in.  There are some crypto-speed 
hacks in attic, mostly lower level.  I think there is at least one that 
does AEAD, maybe making cookies.

I have some hacks to testing the speed of networks and NTP servers.  (A 
friend wrote a book on understanding performance issues.  I was a 
proofreader and played with the code.)  The server side of NTP is pretty 
simple.  With several threads, we should be able to keep up with a gigabit 
link.  Crypto makes the packets longer so fewer packets per second but 
much more CPU.  I did enough poking around to be pretty sure that keeping 
up with the wire was a reasonable goal.

Some of my hacks tested real NTP servers.  Some tests were just echo 
servers, but they had an optional spin loop before sending the packet 
back.  That was to simulate the CPU tme to do the crypto.

The limiting factor for echoing short packets is the CPU time for the 
kernel thread processing interrupts.  A lot of those cycles go to waking 
up a waiting thread.  I haven't tried a short spin before waiting so the 
server thread on a busy server doesn't have to get woken up.  Down hill 
with a tailwind, I managed to echo a million packets per second.

It's easy, CPU wise, to test NTP performance. especially the crypto stuff. 
 The send side can send the same packet over and over -- the setup cost, 
including crypto, is moved outside the loop.  The receive side doesn't 
have to check anything or do any crypto.  So a client on a system in the 
same ballpark of CPU speed can keep up with a server that is doing all the 
work.

It would be nice to have some good/clean performance tests and publish 
numbers for each release.

On the other hand, I can't make a good case for why the project really 
needs to be interested in bleeding edge server performance.

Do you have a good contact at OpenSSL?  If we had good numbers, is there 
any chance they would make their code go faster?

---------

On FIPS...

I don't understand the FIPS bureaucracy and/or how OpenSSL interacts with 
it.

The FIPS stuff requires a bunch of paperwork.  They have to hire a lab to 
do something that takes a long time.  The result only applies to a 
specific version.  (I don't know what happens if they patch that version.)

I'm pretty sure that OpenSSL in FIPS mode didn't include the routines you 
are calling.  There was some discussion on the NTP-WG.  That was a year or 
2 or ?? ago.

I haven't heard anything about them being added.  One sort of common sense 
says since they are just using routines that are FIPS approved then they 
should be OK.  But FIPS is full of paperwork, so maybe it doesn't work 
that way.  Maybe it would need test vectors and such and actually checked 
by the FIPS process.

I think there are some openssl CLI routines to tell you what modes are 
available.  Have you gone down that rathole?  Have you tested your code on 
a FIPS system?


-- 
These are my opinions.  I hate spam.