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:	Tue, 27 Oct 2015 18:19:01 +0900
From:	David Woodhouse <dwmw2@...radead.org>
To:	Stephan Mueller <smueller@...onox.de>,
	Marcel Holtmann <marcel@...tmann.org>
Cc:	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 Tue, 2015-10-27 at 10:12 +0100, Stephan Mueller wrote:
> 
> >after having discussions with David Howells and David Woodhouse, I don't
> >think we should expose akcipher via AF_ALG at all. I think the akcipher
> >operations for sign/verify/encrypt/decrypt should operate on asymmetric keys
> >in the first place. With akcipher you are pretty much bound to public and
> >private keys and the key is the important part and not the akcipher itself.
> >Especially since we want to support private keys in hardware (like TPM for
> >example).
> >
> >It seems more appropriate to use keyctl to derive the symmetric session key
> 
> Are you saying that you consider importing parts of TLS into the kernel? 
> Considering the use case where akcipher would be used to speed up network 
> protocols, I would imply that your comment refers to importing parts of that 
> network protocol into the kernel.
> 
> The key derivation that you mention here would be: RSA-based key exchange plus 
> the TLS KDF. Do we really want to load that into the kernel given that TLS is 
> one protocol and there are many others?

That's largely orthogonal to the point Marcel was making.

The point is that akcipher is limited to using keys for which we have
the private key material available directly in software. We cannot
expose that critically limited API to userspace. We need to expose an
API which supports hardware keys, and basically that means using the
kernel's key subsystem.

For a key which *happens* to be in software, the key subsystem may end
up *using* akcipher behind the scenes. But the API we expose to
userspace cannot simply be based on akcipher.

-- 
dwmw2



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