An API for user-space access to kernel cryptography

Posted Aug 26, 2010 5:44 UTC (Thu) by ringerc (subscriber, #3071)
Parent article: An API for user-space access to kernel cryptography

"and after you take into account price/performance, most hardware crypto [accelerators] have marginal performance benefits; in fact, more often than not, it's a lose."

I'd mostly agree with that, personally - but there's a very big "except".

The Via C3, Via C7, and newer Intel Xeon processors have hardware crypto acceleration on-CPU for a variety of algorithms. My 400MHz C3 thin clients at work dramatically outperform the 2.2GHz Intel Core 2 Duo machines on many crypto tasks.

Personally I don't care about isolating the keys from the apps using them for my use cases - if I did, I'd be using the TPM, or smart cards. I can see how it'd potentially be useful, but I'm not convinced that keeping the keys in kernel memory is much better than keeping them in a separate user-space process.

(For that matter, even dedicated key-isolation crypto hardware like smartcards have proven vulnerable to power- and timing- attacks. No key isolation is perfect - the question is whether moving it into the kernel is better _enough_ to justify the time/effort/complexity cost).

to post comments

An API for user-space access to kernel cryptography

Posted Aug 26, 2010 10:16 UTC (Thu) by alankila (guest, #47141) [Link] (4 responses)

Wouldn't these facilities be accessed just by executing some instructions made for this purpose, and therefore they are available to any program?

An API for user-space access to kernel cryptography

Posted Aug 27, 2010 7:51 UTC (Fri) by cladisch (✭ supporter ✭, #50193) [Link] (3 responses)

There are hardware accelerators that are not integrated into the CPU execution units but that exist as separate devices.

An API for user-space access to kernel cryptography

Posted Aug 28, 2010 9:25 UTC (Sat) by jengelh (subscriber, #33263) [Link] (1 responses)

Perhaps it's better to do the crypto stuff like libusb, that is, have the kernel export only the data channel and have an userspace library (perhaps even daemon if there is concurrency to deal with) to do the crypto context setup etc.

An API for user-space access to kernel cryptography

Posted Aug 28, 2010 15:27 UTC (Sat) by kleptog (subscriber, #1183) [Link]

Oh, I was thinking that the logical step would be cryptfs, where you mount a file system and get a bunch of directories representing encryption algorithms and you just open() the one you want and then use send/recvmsg with options to do the work you want.

No seriously, I don't understand why this needs to be in the kernel, a root-owned daemon should be more than enough.

An API for user-space access to kernel cryptography

Posted Aug 30, 2010 10:19 UTC (Mon) by mjthayer (guest, #39183) [Link]

> There are hardware accelerators that are not integrated into the CPU execution units but that exist as separate devices.

To me it would seem reasonable to have a crypto API in the kernel with no software fallback, so that it is available if it makes sense to do it in hardware, but the interface user has to handle the fallback themselves if the hardware isn't there.