xref: /freebsd/share/man/man9/crypto.9 (revision 162ae9c834f6d9f9cb443bd62cceb23e0b5fef48)
1.\"	$OpenBSD: crypto.9,v 1.19 2002/07/16 06:31:57 angelos Exp $
2.\"
3.\" The author of this manual page is Angelos D. Keromytis (angelos@cis.upenn.edu)
4.\"
5.\" Copyright (c) 2000, 2001 Angelos D. Keromytis
6.\"
7.\" Permission to use, copy, and modify this software with or without fee
8.\" is hereby granted, provided that this entire notice is included in
9.\" all source code copies of any software which is or includes a copy or
10.\" modification of this software.
11.\"
12.\" THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR
13.\" IMPLIED WARRANTY. IN PARTICULAR, NONE OF THE AUTHORS MAKES ANY
14.\" REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE
15.\" MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR
16.\" PURPOSE.
17.\"
18.\" $FreeBSD$
19.\"
20.Dd December 17, 2019
21.Dt CRYPTO 9
22.Os
23.Sh NAME
24.Nm crypto
25.Nd API for cryptographic services in the kernel
26.Sh SYNOPSIS
27.In opencrypto/cryptodev.h
28.Ft int32_t
29.Fn crypto_get_driverid "device_t dev" "size_t session_size" "int flags"
30.Ft int
31.Fn crypto_register "uint32_t driverid" "int alg" "uint16_t maxoplen" "uint32_t flags"
32.Ft int
33.Fn crypto_kregister "uint32_t driverid" "int kalg" "uint32_t flags"
34.Ft int
35.Fn crypto_unregister "uint32_t driverid" "int alg"
36.Ft int
37.Fn crypto_unregister_all "uint32_t driverid"
38.Ft void
39.Fn crypto_done "struct cryptop *crp"
40.Ft void
41.Fn crypto_kdone "struct cryptkop *krp"
42.Ft int
43.Fn crypto_find_driver "const char *match"
44.Ft int
45.Fn crypto_newsession "crypto_session_t *cses" "struct cryptoini *cri" "int crid"
46.Ft int
47.Fn crypto_freesession "crypto_session_t cses"
48.Ft int
49.Fn crypto_dispatch "struct cryptop *crp"
50.Ft int
51.Fn crypto_kdispatch "struct cryptkop *krp"
52.Ft int
53.Fn crypto_unblock "uint32_t driverid" "int what"
54.Ft "struct cryptop *"
55.Fn crypto_getreq "int num"
56.Ft void
57.Fn crypto_freereq "struct cryptop *crp"
58.Bd -literal
59#define	CRYPTO_SYMQ	0x1
60#define	CRYPTO_ASYMQ	0x2
61
62#define EALG_MAX_BLOCK_LEN      16
63
64struct cryptoini {
65	int                cri_alg;
66	int                cri_klen;
67	int                cri_mlen;
68	caddr_t            cri_key;
69	uint8_t            cri_iv[EALG_MAX_BLOCK_LEN];
70	struct cryptoini  *cri_next;
71};
72
73struct cryptodesc {
74	int                crd_skip;
75	int                crd_len;
76	int                crd_inject;
77	int                crd_flags;
78	struct cryptoini   CRD_INI;
79#define crd_iv          CRD_INI.cri_iv
80#define crd_key         CRD_INI.cri_key
81#define crd_alg         CRD_INI.cri_alg
82#define crd_klen        CRD_INI.cri_klen
83	struct cryptodesc *crd_next;
84};
85
86struct cryptop {
87	TAILQ_ENTRY(cryptop) crp_next;
88	crypto_session_t   crp_session;
89	int                crp_ilen;
90	int                crp_olen;
91	int                crp_etype;
92	int                crp_flags;
93	caddr_t            crp_buf;
94	caddr_t            crp_opaque;
95	struct cryptodesc *crp_desc;
96	int              (*crp_callback) (struct cryptop *);
97	caddr_t            crp_mac;
98};
99
100struct crparam {
101        caddr_t         crp_p;
102        u_int           crp_nbits;
103};
104
105#define CRK_MAXPARAM    8
106
107struct cryptkop {
108        TAILQ_ENTRY(cryptkop) krp_next;
109        u_int              krp_op;         /* ie. CRK_MOD_EXP or other */
110        u_int              krp_status;     /* return status */
111        u_short            krp_iparams;    /* # of input parameters */
112        u_short            krp_oparams;    /* # of output parameters */
113        uint32_t           krp_hid;
114        struct crparam     krp_param[CRK_MAXPARAM];
115        int               (*krp_callback)(struct cryptkop *);
116};
117.Ed
118.Sh DESCRIPTION
119.Nm
120is a framework for drivers of cryptographic hardware to register with
121the kernel so
122.Dq consumers
123(other kernel subsystems, and
124users through the
125.Pa /dev/crypto
126device) are able to make use of it.
127Drivers register with the framework the algorithms they support,
128and provide entry points (functions) the framework may call to
129establish, use, and tear down sessions.
130Sessions are used to cache cryptographic information in a particular driver
131(or associated hardware), so initialization is not needed with every request.
132Consumers of cryptographic services pass a set of
133descriptors that instruct the framework (and the drivers registered
134with it) of the operations that should be applied on the data (more
135than one cryptographic operation can be requested).
136.Pp
137Keying operations are supported as well.
138Unlike the symmetric operators described above,
139these sessionless commands perform mathematical operations using
140input and output parameters.
141.Pp
142Since the consumers may not be associated with a process, drivers may
143not
144.Xr sleep 9 .
145The same holds for the framework.
146Thus, a callback mechanism is used
147to notify a consumer that a request has been completed (the
148callback is specified by the consumer on a per-request basis).
149The callback is invoked by the framework whether the request was
150successfully completed or not.
151An error indication is provided in the latter case.
152A specific error code,
153.Er EAGAIN ,
154is used to indicate that a session handle has changed and that the
155request may be re-submitted immediately with the new session.
156Errors are only returned to the invoking function if not
157enough information to call the callback is available (meaning, there
158was a fatal error in verifying the arguments).
159For session initialization and teardown no callback mechanism is used.
160.Pp
161The
162.Fn crypto_find_driver
163returns the driver id of the device whose name matches
164.Fa match .
165.Fa match
166can either be the exact name of a device including the unit
167or the driver name without a unit.
168In the latter case,
169the id of the first device with the matching driver name is returned.
170If no matching device is found,
171the value -1 is returned.
172.Pp
173The
174.Fn crypto_newsession
175routine is called by consumers of cryptographic services (such as the
176.Xr ipsec 4
177stack) that wish to establish a new session with the framework.
178The
179.Fa cri
180argument points to a
181.Vt cryptoini
182structure containing all the necessary information for
183the driver to establish the session.
184The
185.Fa crid
186argument is either a specific driver id or a bitmask of flags.
187The flags are
188.Dv CRYPTOCAP_F_HARDWARE ,
189to select hardware devices,
190or
191.Dv CRYPTOCAP_F_SOFTWARE ,
192to select software devices.
193If both are specified, hardware devices are preferred over software
194devices.
195On success, the opaque session handle of the new session will be stored in
196.Fa *cses .
197The
198.Vt cryptoini
199structure pointed to by
200.Fa cri
201contains these fields:
202.Bl -tag -width ".Va cri_next"
203.It Va cri_alg
204An algorithm identifier.
205Currently supported algorithms are:
206.Pp
207.Bl -tag -width ".Dv CRYPTO_RIPEMD160_HMAC" -compact
208.It Dv CRYPTO_AES_128_NIST_GMAC
209.It Dv CRYPTO_AES_192_NIST_GMAC
210.It Dv CRYPTO_AES_256_NIST_GMAC
211.It Dv CRYPTO_AES_CBC
212.It Dv CRYPTO_AES_CCM_16
213.It Dv CRYPTO_AES_CCM_CBC_MAC
214.It Dv CRYPTO_AES_ICM
215.It Dv CRYPTO_AES_NIST_GCM_16
216.It Dv CRYPTO_AES_NIST_GMAC
217.It Dv CRYPTO_AES_XTS
218.It Dv CRYPTO_ARC4
219.It Dv CRYPTO_BLAKE2B
220.It Dv CRYPTO_BLAKE2S
221.It Dv CRYPTO_BLF_CBC
222.It Dv CRYPTO_CAMELLIA_CBC
223.It Dv CRYPTO_CAST_CBC
224.It Dv CRYPTO_CHACHA20
225.It Dv CRYPTO_DEFLATE_COMP
226.It Dv CRYPTO_DES_CBC
227.It Dv CRYPTO_3DES_CBC
228.It Dv CRYPTO_MD5
229.It Dv CRYPTO_MD5_HMAC
230.It Dv CRYPTO_MD5_KPDK
231.It Dv CRYPTO_NULL_HMAC
232.It Dv CRYPTO_NULL_CBC
233.It Dv CRYPTO_POLY1305
234.It Dv CRYPTO_RIPEMD160
235.It Dv CRYPTO_RIPEMD160_HMAC
236.It Dv CRYPTO_SHA1
237.It Dv CRYPTO_SHA1_HMAC
238.It Dv CRYPTO_SHA1_KPDK
239.It Dv CRYPTO_SHA2_224
240.It Dv CRYPTO_SHA2_224_HMAC
241.It Dv CRYPTO_SHA2_256
242.It Dv CRYPTO_SHA2_256_HMAC
243.It Dv CRYPTO_SHA2_384
244.It Dv CRYPTO_SHA2_384_HMAC
245.It Dv CRYPTO_SHA2_512
246.It Dv CRYPTO_SHA2_512_HMAC
247.It Dv CRYPTO_SKIPJACK_CBC
248.El
249.It Va cri_klen
250For variable-size key algorithms, the length of the key in bits.
251.It Va cri_mlen
252If non-zero, truncate the calculated hash to this many bytes.
253.It Va cri_key
254The key to be used.
255.It Va cri_iv
256An explicit initialization vector if it does not prefix
257the data.
258This field is ignored during initialization
259.Pq Nm crypto_newsession .
260If no IV is explicitly passed (see below on details), a random IV is used
261by the device driver processing the request.
262.It Va cri_next
263Pointer to another
264.Vt cryptoini
265structure.
266This is used to establish dual-algorithm sessions, such as combining a
267cipher with a MAC.
268.El
269.Pp
270The
271.Vt cryptoini
272structure and its contents will not be modified or referenced by the
273framework or any cryptographic drivers.
274The memory associated with
275.Fa cri
276can be released once
277.Fn crypto_newsession
278returns.
279.Pp
280.Fn crypto_freesession
281is called with the session handle returned by
282.Fn crypto_newsession
283to free the session.
284.Pp
285.Fn crypto_dispatch
286is called to process a request.
287The various fields in the
288.Vt cryptop
289structure are:
290.Bl -tag -width ".Va crp_callback"
291.It Va crp_session
292The session handle.
293.It Va crp_ilen
294The total length in bytes of the buffer to be processed.
295.It Va crp_olen
296On return, contains the total length of the result.
297For symmetric crypto operations, this will be the same as the input length.
298This will be used if the framework needs to allocate a new
299buffer for the result (or for re-formatting the input).
300.It Va crp_callback
301Callback routine invoked when a request is completed via
302.Fn crypto_done .
303The callback routine should inspect the
304.Va crp_etype
305to determine if the request was successfully completed.
306.It Va crp_etype
307The error type, if any errors were encountered, or zero if
308the request was successfully processed.
309If the
310.Er EAGAIN
311error code is returned, the session handle has changed (and has been recorded
312in the
313.Va crp_session
314field).
315The consumer should record the new session handle and use it in all subsequent
316requests.
317In this case, the request may be re-submitted immediately.
318This mechanism is used by the framework to perform
319session migration (move a session from one driver to another, because
320of availability, performance, or other considerations).
321.Pp
322This field is only valid in the context of the callback routine specified by
323.Va crp_callback .
324Errors are returned to the invoker of
325.Fn crypto_process
326only when enough information is not present to call the callback
327routine (i.e., if the pointer passed is
328.Dv NULL
329or if no callback routine was specified).
330.It Va crp_flags
331A bitmask of flags associated with this request.
332Currently defined flags are:
333.Bl -tag -width ".Dv CRYPTO_F_CBIFSYNC"
334.It Dv CRYPTO_F_IMBUF
335The buffer is an mbuf chain pointed to by
336.Va crp_mbuf .
337.It Dv CRYPTO_F_IOV
338The buffer is a
339.Vt uio
340structure pointed to by
341.Va crp_uio .
342.It Dv CRYPTO_F_BATCH
343Batch operation if possible.
344.It Dv CRYPTO_F_CBIMM
345Do callback immediately instead of doing it from a dedicated kernel thread.
346.It Dv CRYPTO_F_DONE
347Operation completed.
348.It Dv CRYPTO_F_CBIFSYNC
349Do callback immediately if operation is synchronous (that the driver
350specified the
351.Dv CRYPTOCAP_F_SYNC
352flag).
353.It Dv CRYPTO_F_ASYNC
354Try to do the crypto operation in a pool of workers
355if the operation is synchronous (that is, if the driver specified the
356.Dv CRYPTOCAP_F_SYNC
357flag).
358It aims to speed up processing by dispatching crypto operations
359on different processors.
360.It Dv CRYPTO_F_ASYNC_KEEPORDER
361Dispatch callbacks in the same order they are posted.
362Only relevant if the
363.Dv CRYPTO_F_ASYNC
364flag is set and if the operation is synchronous.
365.El
366.It Va crp_buf
367Data buffer unless
368.Dv CRYPTO_F_IMBUF
369or
370.Dv CRYPTO_F_IOV
371is set in
372.Va crp_flags .
373The length in bytes is set in
374.Va crp_ilen .
375.It Va crp_mbuf
376Data buffer mbuf chain when
377.Dv CRYPTO_F_IMBUF
378is set in
379.Va crp_flags .
380.It Va crp_uio
381.Vt struct uio
382data buffer when
383.Dv CRYPTO_F_IOV
384is set in
385.Va crp_flags .
386.It Va crp_opaque
387Cookie passed through the crypto framework untouched.
388It is
389intended for the invoking application's use.
390.It Va crp_desc
391A linked list of descriptors.
392Each descriptor provides
393information about what type of cryptographic operation should be done
394on the input buffer.
395The various fields are:
396.Bl -tag -width ".Va crd_inject"
397.It Va crd_iv
398When the flag
399.Dv CRD_F_IV_EXPLICIT
400is set, this field contains the IV.
401.It Va crd_key
402When the
403.Dv CRD_F_KEY_EXPLICIT
404flag is set, the
405.Va crd_key
406points to a buffer with encryption or authentication key.
407.It Va crd_alg
408An algorithm to use.
409Must be the same as the one given at newsession time.
410.It Va crd_klen
411The
412.Va crd_key
413key length.
414.It Va crd_skip
415The offset in the input buffer where processing should start.
416.It Va crd_len
417How many bytes, after
418.Va crd_skip ,
419should be processed.
420.It Va crd_inject
421The
422.Va crd_inject
423field specifies an offset in bytes from the beginning of the buffer.
424For encryption algorithms, this may be where the IV will be inserted
425when encrypting or where the IV may be found for
426decryption (subject to
427.Va crd_flags ) .
428For MAC algorithms, this is where the result of the keyed hash will be
429inserted.
430.It Va crd_flags
431The following flags are defined:
432.Bl -tag -width 3n
433.It Dv CRD_F_ENCRYPT
434For encryption algorithms, this bit is set when encryption is required
435(when not set, decryption is performed).
436.It Dv CRD_F_IV_PRESENT
437.\" This flag name has nothing to do w/ it's behavior, fix the name.
438For encryption, if this bit is not set the IV used to encrypt the packet
439will be written at the location pointed to by
440.Va crd_inject .
441The IV length is assumed to be equal to the blocksize of the
442encryption algorithm.
443For encryption, if this bit is set, nothing is done.
444For decryption, this flag has no meaning.
445Applications that do special
446.Dq "IV cooking" ,
447such as the half-IV mode in
448.Xr ipsec 4 ,
449can use this flag to indicate that the IV should not be written on the packet.
450This flag is typically used in conjunction with the
451.Dv CRD_F_IV_EXPLICIT
452flag.
453.It Dv CRD_F_IV_EXPLICIT
454This bit is set when the IV is explicitly
455provided by the consumer in the
456.Va crd_iv
457field.
458Otherwise, for encryption operations the IV is provided for by
459the driver used to perform the operation, whereas for decryption
460operations the offset of the IV is provided by the
461.Va crd_inject
462field.
463This flag is typically used when the IV is calculated
464.Dq "on the fly"
465by the consumer, and does not precede the data.
466.It Dv CRD_F_KEY_EXPLICIT
467For encryption and authentication (MAC) algorithms, this bit is set when the key
468is explicitly provided by the consumer in the
469.Va crd_key
470field for the given operation.
471Otherwise, the key is taken at newsession time from the
472.Va cri_key
473field.
474As calculating the key schedule may take a while, it is recommended that often
475used keys are given their own session.
476.It Dv CRD_F_COMP
477For compression algorithms, this bit is set when compression is required (when
478not set, decompression is performed).
479.El
480.It Va CRD_INI
481This
482.Vt cryptoini
483structure will not be modified by the framework or the device drivers.
484Since this information accompanies every cryptographic
485operation request, drivers may re-initialize state on-demand
486(typically an expensive operation).
487Furthermore, the cryptographic
488framework may re-route requests as a result of full queues or hardware
489failure, as described above.
490.It Va crd_next
491Point to the next descriptor.
492Linked operations are useful in protocols such as
493.Xr ipsec 4 ,
494where multiple cryptographic transforms may be applied on the same
495block of data.
496.El
497.El
498.Pp
499.Fn crypto_getreq
500allocates a
501.Vt cryptop
502structure with a linked list of
503.Fa num
504.Vt cryptodesc
505structures.
506.Pp
507.Fn crypto_freereq
508deallocates a structure
509.Vt cryptop
510and any
511.Vt cryptodesc
512structures linked to it.
513Note that it is the responsibility of the
514callback routine to do the necessary cleanups associated with the
515opaque field in the
516.Vt cryptop
517structure.
518.Pp
519.Fn crypto_kdispatch
520is called to perform a keying operation.
521The various fields in the
522.Vt cryptkop
523structure are:
524.Bl -tag -width ".Va krp_callback"
525.It Va krp_op
526Operation code, such as
527.Dv CRK_MOD_EXP .
528.It Va krp_status
529Return code.
530This
531.Va errno Ns -style
532variable indicates whether lower level reasons
533for operation failure.
534.It Va krp_iparams
535Number of input parameters to the specified operation.
536Note that each operation has a (typically hardwired) number of such parameters.
537.It Va krp_oparams
538Number of output parameters from the specified operation.
539Note that each operation has a (typically hardwired) number of such parameters.
540.It Va krp_kvp
541An array of kernel memory blocks containing the parameters.
542.It Va krp_hid
543Identifier specifying which low-level driver is being used.
544.It Va krp_callback
545Callback called on completion of a keying operation.
546.El
547.Sh DRIVER-SIDE API
548The
549.Fn crypto_get_driverid ,
550.Fn crypto_get_driver_session ,
551.Fn crypto_register ,
552.Fn crypto_kregister ,
553.Fn crypto_unregister ,
554.Fn crypto_unblock ,
555and
556.Fn crypto_done
557routines are used by drivers that provide support for cryptographic
558primitives to register and unregister with the kernel crypto services
559framework.
560.Pp
561Drivers must first use the
562.Fn crypto_get_driverid
563function to acquire a driver identifier, specifying the
564.Fa flags
565as an argument.
566One of
567.Dv CRYPTOCAP_F_SOFTWARE
568or
569.Dv CRYPTOCAP_F_HARDWARE
570must be specified.
571The
572.Dv CRYPTOCAP_F_SYNC
573may also be specified, and should be specified if the driver does all of
574it's operations synchronously.
575Drivers must pass the size of their session structure as the second argument.
576An appropriately sized memory will be allocated by the framework, zeroed, and
577passed to the driver's
578.Fn newsession
579method.
580.Pp
581For each algorithm the driver supports, it must then call
582.Fn crypto_register .
583The first two arguments are the driver and algorithm identifiers.
584The next two arguments specify the largest possible operator length (in bits,
585important for public key operations) and flags for this algorithm.
586.Pp
587.Fn crypto_unregister
588is called by drivers that wish to withdraw support for an algorithm.
589The two arguments are the driver and algorithm identifiers, respectively.
590Typically, drivers for
591PCMCIA
592crypto cards that are being ejected will invoke this routine for all
593algorithms supported by the card.
594.Fn crypto_unregister_all
595will unregister all algorithms registered by a driver
596and the driver will be disabled (no new sessions will be allocated on
597that driver, and any existing sessions will be migrated to other
598drivers).
599The same will be done if all algorithms associated with a driver are
600unregistered one by one.
601After a call to
602.Fn crypto_unregister_all
603there will be no threads in either the newsession or freesession function
604of the driver.
605.Pp
606The calling convention for the driver-supplied routines are:
607.Pp
608.Bl -item -compact
609.It
610.Ft int
611.Fn \*[lp]*newsession\*[rp] "device_t" "crypto_session_t" "struct cryptoini *" ;
612.It
613.Ft void
614.Fn \*[lp]*freesession\*[rp] "device_t" "crypto_session_t" ;
615.It
616.Ft int
617.Fn \*[lp]*process\*[rp] "device_t" "struct cryptop *" "int" ;
618.It
619.Ft int
620.Fn \*[lp]*kprocess\*[rp] "device_t" "struct cryptkop *" "int" ;
621.El
622.Pp
623On invocation, the first argument to
624all routines is the
625.Fa device_t
626that was provided to
627.Fn crypto_get_driverid .
628The second argument to
629.Fn newsession
630is the opaque session handle for the new session.
631The third argument is identical to that of
632.Fn crypto_newsession .
633.Pp
634Drivers obtain a pointer to their session memory by invoking
635.Fn crypto_get_driver_session
636on the opaque
637.Vt crypto_session_t
638handle.
639.Pp
640The
641.Fn freesession
642routine takes as arguments the opaque data value and the session handle.
643It should clear any context associated with the session (clear hardware
644registers, memory, etc.).
645If no resources need to be released other than the contents of session memory,
646the method is optional.
647The
648.Nm
649framework will zero and release the allocated session memory (after running the
650.Fn freesession
651method, if one exists).
652.Pp
653The
654.Fn process
655routine is invoked with a request to perform crypto processing.
656This routine must not block or sleep, but should queue the request and return
657immediately or process the request to completion.
658In case of an unrecoverable error, the error indication must be placed in the
659.Va crp_etype
660field of the
661.Vt cryptop
662structure.
663When the request is completed, or an error is detected, the
664.Fn process
665routine must invoke
666.Fn crypto_done .
667Session migration may be performed, as mentioned previously.
668.Pp
669In case of a temporary resource exhaustion, the
670.Fn process
671routine may return
672.Er ERESTART
673in which case the crypto services will requeue the request, mark the driver
674as
675.Dq blocked ,
676and stop submitting requests for processing.
677The driver is then responsible for notifying the crypto services
678when it is again able to process requests through the
679.Fn crypto_unblock
680routine.
681This simple flow control mechanism should only be used for short-lived
682resource exhaustion as it causes operations to be queued in the crypto
683layer.
684Doing so is preferable to returning an error in such cases as
685it can cause network protocols to degrade performance by treating the
686failure much like a lost packet.
687.Pp
688The
689.Fn kprocess
690routine is invoked with a request to perform crypto key processing.
691This routine must not block, but should queue the request and return
692immediately.
693Upon processing the request, the callback routine should be invoked.
694In case of an unrecoverable error, the error indication must be placed in the
695.Va krp_status
696field of the
697.Vt cryptkop
698structure.
699When the request is completed, or an error is detected, the
700.Fn kprocess
701routine should invoked
702.Fn crypto_kdone .
703.Sh RETURN VALUES
704.Fn crypto_register ,
705.Fn crypto_kregister ,
706.Fn crypto_unregister ,
707.Fn crypto_newsession ,
708.Fn crypto_freesession ,
709and
710.Fn crypto_unblock
711return 0 on success, or an error code on failure.
712.Fn crypto_get_driverid
713returns a non-negative value on error, and \-1 on failure.
714.Fn crypto_getreq
715returns a pointer to a
716.Vt cryptop
717structure and
718.Dv NULL
719on failure.
720.Fn crypto_dispatch
721returns
722.Er EINVAL
723if its argument or the callback function was
724.Dv NULL ,
725and 0 otherwise.
726The callback is provided with an error code in case of failure, in the
727.Va crp_etype
728field.
729.Sh FILES
730.Bl -tag -width ".Pa sys/opencrypto/crypto.c"
731.It Pa sys/opencrypto/crypto.c
732most of the framework code
733.El
734.Sh SEE ALSO
735.Xr crypto 4 ,
736.Xr ipsec 4 ,
737.Xr crypto 7 ,
738.Xr malloc 9 ,
739.Xr sleep 9
740.Sh HISTORY
741The cryptographic framework first appeared in
742.Ox 2.7
743and was written by
744.An Angelos D. Keromytis Aq Mt angelos@openbsd.org .
745.Sh BUGS
746The framework currently assumes that all the algorithms in a
747.Fn crypto_newsession
748operation must be available by the same driver.
749If that is not the case, session initialization will fail.
750.Pp
751The framework also needs a mechanism for determining which driver is
752best for a specific set of algorithms associated with a session.
753Some type of benchmarking is in order here.
754.Pp
755Multiple instances of the same algorithm in the same session are not
756supported.
757