tech-crypto archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: /dev/crypto



On Thu, Nov 27, 2014 at 11:02:41AM +0000, Patrick Welche wrote:
> 
> His conclusion in
> 
>   http://mail-index.netbsd.org/tech-crypto/2005/05/29/msg000362.html

Note the referenced message is from 2005.

> is:
> 
>   For what it's worth, while working with both sides of /dev/crypto
>   (writing some applications and adding a hw-acceleration backend), I've
>   developed the strong impression that the /dev/crypto interface is
>   something of an afterthought or testing interface, and that the only
>   "first class" interface to crypto(4) is the kernel interface.

That may have been true in 2005, when there was no way to do asynchronous
requests.  I don't think it's true now.  At Coyote Point we put a lot of
work into enhancing the /dev/crypto interface (as well as the underlying
kernel subsystem) to allow high rate use from userspace.

We did this by adding request types for asynchronous request submission
and multiple request retrieval, while otherwise retaining backwards
compatibility with the old interface.

Unfortunately, since most applications use OpenSSL with its inherent
limitations (in particular, that its core SSL code and its ENGINE interface
don't allow any way to wait on asynchronous resources of any kind) this has
not proven terribly useful to others.  One thing that is particularly
frustrating to me is that neither the FreeBSD nor Linux maintainers of
the relevant code have picked up our enhancements, though I did point them
out to them at the time.

While at Coyote Point I also got the source code to a very high performance
enhanced version of OpenSSL (which had support for async requests added)
open-sourced by its author.  This was NetOctave's SSL library which used
their proprietary device driver interface, not /dev/crypto, but the core
modifications (and the whitepaper that described them) were certainly
relevant; unfortunately this (efficient support for coprocessor style
accellerators) is a path the OpenSSL team made pretty clear they were not
interested in walking.  Too bad.

*Sigh*.

Thor


Home | Main Index | Thread Index | Old Index