linux-kernel - Re: [PATCH v2 0/5] crypto: add algif

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Oct 2015 08:43:16 +0900
From:	David Woodhouse <dwmw2@...radead.org>
To:	Stephan Mueller <smueller@...onox.de>
Cc:	Marcel Holtmann <marcel@...tmann.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	linux-crypto@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-api@...r.kernel.org, David Howells <dhowells@...hat.com>
Subject: Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

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,
> > 
> > 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



Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5691 bytes)