d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a128aaea95
freebsd-dev/sys/opencrypto/cryptosoft.h

71 lines
2.0 KiB
C
Raw Normal View History

In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols. Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers. Obtained from: openbsd
2002-10-04 20:31:23 +00:00
/* $FreeBSD$ */
/* $OpenBSD: cryptosoft.h,v 1.10 2002/04/22 23:10:09 deraadt Exp $ */
/* -> /*- for license, minor formatting changes
2005-01-07 02:29:27 +00:00
/*-
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols. Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers. Obtained from: openbsd
2002-10-04 20:31:23 +00:00
* The author of this code is Angelos D. Keromytis (angelos@cis.upenn.edu)
*
* This code was written by Angelos D. Keromytis in Athens, Greece, in
* February 2000. Network Security Technologies Inc. (NSTI) kindly
* supported the development of this code.
*
* Copyright (c) 2000 Angelos D. Keromytis
*
* Permission to use, copy, and modify this software with or without fee
* is hereby granted, provided that this entire notice is included in
* all source code copies of any software which is or includes a copy or
* modification of this software.
*
* THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR
* IMPLIED WARRANTY. IN PARTICULAR, NONE OF THE AUTHORS MAKES ANY
* REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE
* MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR
* PURPOSE.
*/
#ifndef _CRYPTO_CRYPTOSOFT_H_
#define _CRYPTO_CRYPTOSOFT_H_
/* Software session entry */
struct swcr_data {
int sw_alg; /* Algorithm */
union {
struct {
u_int8_t *SW_ictx;
u_int8_t *SW_octx;
- Fix a very old bug in HMAC/SHA{384,512}. When HMAC is using SHA384 or SHA512, the blocksize is 128 bytes, not 64 bytes as anywhere else. The bug also exists in NetBSD, OpenBSD and various other independed implementations I look at. - We cannot decide which hash function to use for HMAC based on the key length, because any HMAC function can use any key length. To fix it split CRYPTO_SHA2_HMAC into three algorithm: CRYPTO_SHA2_256_HMAC, CRYPTO_SHA2_384_HMAC and CRYPTO_SHA2_512_HMAC. Those names are consistent with OpenBSD's naming. - Remove authsize field from auth_hash structure. - Allow consumer to define size of hash he wants to receive. This allows to use HMAC not only for IPsec, where 96 bits MAC is requested. The size of requested MAC is defined at newsession time in the cri_mlen field - when 0, entire MAC will be returned. - Add swcr_authprepare() function which prepares authentication key. - Allow to provide key for every authentication operation, not only at newsession time by honoring CRD_F_KEY_EXPLICIT flag. - Make giving key at newsession time optional - don't try to operate on it if its NULL. - Extend COPYBACK()/COPYDATA() macros to handle CRYPTO_BUF_CONTIG buffer type as well. - Accept CRYPTO_BUF_IOV buffer type in swcr_authcompute() as we have cuio_apply() now. - 16 bits for key length (SW_klen) is more than enough. Reviewed by: sam
2006-05-17 18:24:17 +00:00
u_int16_t SW_klen;
u_int16_t SW_mlen;
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols. Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers. Obtained from: openbsd
2002-10-04 20:31:23 +00:00
struct auth_hash *SW_axf;
} SWCR_AUTH;
struct {
u_int8_t *SW_kschedule;
struct enc_xform *SW_exf;
} SWCR_ENC;
struct {
u_int32_t SW_size;
struct comp_algo *SW_cxf;
} SWCR_COMP;
} SWCR_UN;
#define sw_ictx SWCR_UN.SWCR_AUTH.SW_ictx
#define sw_octx SWCR_UN.SWCR_AUTH.SW_octx
#define sw_klen SWCR_UN.SWCR_AUTH.SW_klen
- Fix a very old bug in HMAC/SHA{384,512}. When HMAC is using SHA384 or SHA512, the blocksize is 128 bytes, not 64 bytes as anywhere else. The bug also exists in NetBSD, OpenBSD and various other independed implementations I look at. - We cannot decide which hash function to use for HMAC based on the key length, because any HMAC function can use any key length. To fix it split CRYPTO_SHA2_HMAC into three algorithm: CRYPTO_SHA2_256_HMAC, CRYPTO_SHA2_384_HMAC and CRYPTO_SHA2_512_HMAC. Those names are consistent with OpenBSD's naming. - Remove authsize field from auth_hash structure. - Allow consumer to define size of hash he wants to receive. This allows to use HMAC not only for IPsec, where 96 bits MAC is requested. The size of requested MAC is defined at newsession time in the cri_mlen field - when 0, entire MAC will be returned. - Add swcr_authprepare() function which prepares authentication key. - Allow to provide key for every authentication operation, not only at newsession time by honoring CRD_F_KEY_EXPLICIT flag. - Make giving key at newsession time optional - don't try to operate on it if its NULL. - Extend COPYBACK()/COPYDATA() macros to handle CRYPTO_BUF_CONTIG buffer type as well. - Accept CRYPTO_BUF_IOV buffer type in swcr_authcompute() as we have cuio_apply() now. - 16 bits for key length (SW_klen) is more than enough. Reviewed by: sam
2006-05-17 18:24:17 +00:00
#define sw_mlen SWCR_UN.SWCR_AUTH.SW_mlen
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols. Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers. Obtained from: openbsd
2002-10-04 20:31:23 +00:00
#define sw_axf SWCR_UN.SWCR_AUTH.SW_axf
#define sw_kschedule SWCR_UN.SWCR_ENC.SW_kschedule
#define sw_exf SWCR_UN.SWCR_ENC.SW_exf
#define sw_size SWCR_UN.SWCR_COMP.SW_size
#define sw_cxf SWCR_UN.SWCR_COMP.SW_cxf
cryptosoft: Reduce generality of supported algorithm composition Fix a regression introduced in r336439. Rather than allowing any linked list of algorithms, allow at most two (typically, some combination of encrypt and/or MAC). Removes a WAITOK malloc in an unsleepable context (classic LOR) by placing both software algorithm contexts within the OCF-managed session object. Tested with 'cryptocheck -a all -d cryptosoft0', which includes some encrypt-and-MAC modes. PR: 230304 Reported by: sef@
2018-08-17 04:40:01 +00:00
};
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols. Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers. Obtained from: openbsd
2002-10-04 20:31:23 +00:00
cryptosoft: Reduce generality of supported algorithm composition Fix a regression introduced in r336439. Rather than allowing any linked list of algorithms, allow at most two (typically, some combination of encrypt and/or MAC). Removes a WAITOK malloc in an unsleepable context (classic LOR) by placing both software algorithm contexts within the OCF-managed session object. Tested with 'cryptocheck -a all -d cryptosoft0', which includes some encrypt-and-MAC modes. PR: 230304 Reported by: sef@
2018-08-17 04:40:01 +00:00
struct swcr_session {
struct swcr_data swcr_algorithms[2];
unsigned swcr_nalgs;
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols. Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers. Obtained from: openbsd
2002-10-04 20:31:23 +00:00
};
#ifdef _KERNEL
Overhaul driver/subsystem api's: o make all crypto drivers have a device_t; pseudo drivers like the s/w crypto driver synthesize one o change the api between the crypto subsystem and drivers to use kobj; cryptodev_if.m defines this api o use the fact that all crypto drivers now have a device_t to add support for specifying which of several potential devices to use when doing crypto operations o add new ioctls that allow user apps to select a specific crypto device to use (previous ioctls maintained for compatibility) o overhaul crypto subsystem code to eliminate lots of cruft and hide implementation details from drivers o bring in numerous fixes from Michale Richardson/hifn; mostly for 795x parts o add an optional mechanism for mmap'ing the hifn 795x public key h/w to user space for use by openssl (not enabled by default) o update crypto test tools to use new ioctl's and add cmd line options to specify a device to use for tests These changes will also enable much future work on improving the core crypto subsystem; including proper load balancing and interposing code between the core and drivers to dispatch small operations to the s/w driver as appropriate. These changes were instigated by the work of Michael Richardson. Reviewed by: pjd Approved by: re
2007-03-21 03:42:51 +00:00
extern u_int8_t hmac_ipad_buffer[];
extern u_int8_t hmac_opad_buffer[];
In-kernel crypto framework derived from openbsd. This facility provides a consistent interface to h/w and s/w crypto algorithms for use by the kernel and (for h/w at least) by user-mode apps. Access for user-level code is through a /dev/crypto device that'll eventually be used by openssl to (potentially) accelerate many applications. Coming soon is an IPsec that makes use of this service to accelerate ESP, AH, and IPCOMP protocols. Included here is the "core" crypto support, /dev/crypto driver, various crypto algorithms that are not already present in the KAME crypto area, and support routines used by crypto device drivers. Obtained from: openbsd
2002-10-04 20:31:23 +00:00
#endif /* _KERNEL */
#endif /* _CRYPTO_CRYPTO_H_ */
Reference in New Issue Copy Permalink