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