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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1445992622.3405.148.camel@infradead.org>
Date:	Wed, 28 Oct 2015 09:37:02 +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:47 +0100, Stephan Mueller wrote:
> 
> Ohh, I see. So, you are saying that there should not be a setpub/privkey for 
> the akcipher AF_ALG interface?!
> 
> If somebody wants to use akcipher, he shall set the key via the keyring and 
> akcipher shall obtain it from the keyring?
> 
> However, for the actual data shoveling, AF_ALG should still be used?

That might seem ideal, but Herbert doesn't want that — he wants
akcipher to work *only* with its own internal keys, not with keys from
the kernel's key subsystem.

David has patches (not upstream yet; used for testing) which expose a
verify operation for kernel keys through sys_keyctl(). Adding the other
three operations would be feasible.

Perhaps if we *really* want this to appear through AF_ALG, the key
subsystem could register its own RSA (and other) implementation(s) with
the crypto subsystem. Then we could find some way that we can pass the
key_serial_t through alg_setkey() instead of the actual key data
without it (or Herbert) noticing that's what we're doing. But... ick.
And I don't think we can select algorithms based on the actual key
rather than the type. We should do it properly, if at all. And define
the API as taking key IDs instead of having it be a nasty special-case
hack for a specific (but really, very generic) algorithm provider.

-- 
dwmw2



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

Powered by blists - more mailing lists