Thread (30 messages) 30 messages, 5 authors, 2015-12-14

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

From: David Woodhouse <hidden>
Date: 2015-10-27 23:43:33
Also in: linux-crypto, lkml

On Wed, 2015-10-28 at 00:35 +0100, Stephan Mueller wrote:
Am Mittwoch, 28. Oktober 2015, 08:15:16 schrieb David Woodhouse:

Hi David,
quoted
Absolutely. The interface needs to support *both*.

I've spent a lot of time chasing through userspace stacks, fixing
broken assumptions that we will *always* have the actual key material
in a file — and making libraries and applications accept PKCS#11 URIs
referring to keys in hardware as well as filenames.

I am violently opposed to exposing an API from the kernel which makes
that *same* fundamental mistake, and ties its users to using *only*
software keys.

FROM THE BEGINNING, users of this new API should be able to cope with
the fact that they might not *have* the key material, and that they
might simply be referring to a key which exists elsewhere. Such as in
the TPM, or within an SGX software enclave.
Albeit that all sounds like the crown jewel, how do you propose that shall 
happen?

Assume that you have a web server that has a pub and priv key in its current 
configuration -- I guess that is the vast majority of configs.

Can you please elaborate how the process for such a web server shall really 
work?
1. Create a kernel-side key.
2. Use it.

That may require adding an API similar to the one you're proposing, but
working with kernel keys instead of directly with akcipher. Or perhaps
the key subsystem can already offer what you need in userspace. David?

-- 
dwmw2

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help