Ranting about OCF / crypto(9)

[John Baldwin]

On Wednesday, January 10, 2018 11:56:21 PM Benjamin Kaduk wrote:
> Replying mostly with my upstream OpenSSL hat on, not least to note
> my regret that OpenSSL's historic poor API design choices reflect so
> heavily herein...
> 
> On Wed, Jan 10, 2018 at 04:18:52PM -0800, John Baldwin wrote:
> > While working on hooking the ccr(4) driver into our in-kernel crypto
> > framework (along with some out-of-tree patches to extend OpenSSL's
> > /dev/crypto engine to support AES-CTR/XTS/GCM and some further changes to
> 
> Note that on master/proto-1.1.1, the cryptodev engine got swapped
> out for the one from https://github.com/openssl/openssl/pull/3744,
> since the OpenBSD folks would not agree to relicense.  (Apparently
> the move to the Apache license is probably actually going to
> happen.)   But I'd be happy to help review patches to add additional
> functionality.

Hmm, I tried mailing the person who worked on that new engine a while ago
to see if they were open to accepting upstream patches and never got a
reply.  If you are able to work with upstream then I will talk to you more
offline about CTR/XTS/GCM support for 1.1.1.

> >   - TLS-style requests (using TLS's different methods of
> >     combining auth and encryption methods when those are
> >     separate)
> 
> My brain is trying to ask "is that really a good idea?" about
> putting the old (bad/broken) TLS mac+encrypt schemes in the kernel,
> from the vantage point of making it easier to do insecure things.

It's more about being able to offload TLS encryption.  Hardware engines
support combined auth+enc operations, so we need to have requests at
that granularity.  When I last looked, OpenSSL 1.0.x at least didn't
really support CBC+SHA as a real NID (there's a special NID only used
by the userland aesni bits, but no engine implements it).  Not all of
the TLS world is GCM yet, so offloading non-GCM TLS is still desirable.
My understanding is that TLS now supports IPSec-style EtM via some RFC
I can't recall, but trying to read the code in OpenSSL 1.0.x at least
I couldn't find anything that seemed to support that.

> >   - Simple compression / decompression requests.  While this isn't
> >     "crypto", per se, I do think it is probably still simpler to
> >     manage this via OCF than a completely separate interface.
> 
> Probably, though perhaps less so after the removal of arbitrary
> stacking depths.  And mixing compression with encryption has its own
> risks, of course.

I probably think you wouldn't mix but would either do compression, auth,
hash, or auth+enc.  NetBSD's /dev/crypto does support stacking
compression + auth + enc in a single ioctl, but it doesn't provide any
way to control the ordering so in practice I think it was just a way to
permit offloading compression alone.

> >   In terms of algorithms, I suspect there are some older algorithms
> >   we could drop.  Modern hardware doesn't offload DES for example.
> >   Both ccr(4) and aesni(4) only support AES for encryption.  We
> >   do need to keep algorithms required for IPSec in the kernel, but
> >   we could probably drop some others?
> 
> Yes, it's probably time for DES to go.  Maybe others as well.
> 
> > - To better support OpenSSL's engine, the /dev/crypto hash interface
> >   should not require monotonic buffers, but support requests for
> >   large buffers that span multiple requests (so you can do something
> >   akin to the 'Init' / 'Update' (N times) / 'Final' model existing
> >   software hashing APIs use).  In particular, the bigger win for
> >   hashing in hardware is when you can offload the hashing of a large
> >   thing rather than small requests.
> 
> Something of an aside, but we are growing some support for
> "one-shot" stuff as a result of Ed25519 support landing, but the
> Init/Update/Final mindset is still pretty baked in, for now.

Also, the new /dev/crypto engine for 1.1.x supports a Linux API for hashes
that assumes Init/Update/Final.  My thinking is to implement the Linux API
(really just a new flag IIRC) for this so that hopefully the 1.1.x engine
doesn't need any changes to support this.  It would be nice if OpenSSL
would use the HMAC nids for HMAC requests instead of the plain hashes
perhaps?  (That seems relevant to the 977 issue you quoted and right now
FreeBSD's /dev/crypto is an existing implementation that would benefit
from HMAC using HMAC NIDs instead of digest NIDs.)  I don't think it would
require a change in the engine interface, btw.  I think it means that
HMAC() needs to first try to find an engine that supports the HMAC NID,
and if that fails it could then use the current code which generates PADs
in software and looks for an engine that implements the digest NID.

-- 
John Baldwin