aboutsummaryrefslogtreecommitdiffstats
path: root/security
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2018-10-09 17:46:51 +0100
committerJames Morris <james.morris@microsoft.com>2018-10-26 09:30:46 +0100
commit70025f84e5b79627a6739533c4fe7cef5b605886 (patch)
tree7c0f426ac0a78f0a3733726c94c4d3aa4fd733cb /security
parentMerge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (diff)
downloadlinux-dev-70025f84e5b79627a6739533c4fe7cef5b605886.tar.xz
linux-dev-70025f84e5b79627a6739533c4fe7cef5b605886.zip
KEYS: Provide key type operations for asymmetric key ops [ver #2]
Provide five new operations in the key_type struct that can be used to provide access to asymmetric key operations. These will be implemented for the asymmetric key type in a later patch and may refer to a key retained in RAM by the kernel or a key retained in crypto hardware. int (*asym_query)(const struct kernel_pkey_params *params, struct kernel_pkey_query *info); int (*asym_eds_op)(struct kernel_pkey_params *params, const void *in, void *out); int (*asym_verify_signature)(struct kernel_pkey_params *params, const void *in, const void *in2); Since encrypt, decrypt and sign are identical in their interfaces, they're rolled together in the asym_eds_op() operation and there's an operation ID in the params argument to distinguish them. Verify is different in that we supply the data and the signature instead and get an error value (or 0) as the only result on the expectation that this may well be how a hardware crypto device may work. Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Denis Kenzior <denkenz@gmail.com> Tested-by: Denis Kenzior <denkenz@gmail.com> Signed-off-by: James Morris <james.morris@microsoft.com>
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions