Hi Marcel,

 >>
>> Right now I wouldn't worry about this.  If we encounter a situation where we actually benefit from this, then lets revisit then.  Right now we are going to be encrypting/decrypting data on the order of a few hundred bytes.  EAPoL-Key Data is capped at about 32K, so even in the absolute worst case I don't think we need to worry about this.
>
> Actually we might want to do this directly inside iwd instead of ELL. That background is pretty much that we need to run a basic selftest on available ciphers and algs anyway first. Not all kernels have the required ciphers (or even hash algorithm) that we need. So the advantage doing it in iwd direct without a framework in ELL is that we can quickly test the kernel and then just abort.
>

I tend to disagree.  We might as well make ell into a proper API.  If we 
need to enumerate supported AF_ALGs and add that functionality to ell, 
then that's what we have to do.

In the end, the fastest way to implement hashing and crypto is natively. 
  So if we decide to add that to ell at a later date, then we 
automatically make iwd faster without re-writing any code.

> It would also be an easier place to figure out what we really need in the end and what performance impact we are accepting by using the kernel crypto subsystem and AF_ALG.
>
> The checksum stuff has been added to ELL since we had that in GLib. However the HMAC part has never been added to ELL. That has been kept in iwd. And I am actually considering doing native AF_ALG for the checksum and HMAC without involving ELL. Reason is that we can be more efficient with the file descriptors and system calls if we target specific parts.
>

Yes, I thought that was pretty strange, but fixing it wasn't my priority 
right now.  In the end our target use case does not warrant any sort of 
'efficiency' tricks / optimizations, so I don't see the point. 
Especially given that the code is essentially the same in src/aes.c and 
ell/checksum.c

Regards,
-Denis