| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 |  | 
 | 2 |                     Scatterlist Cryptographic API | 
 | 3 |                     | 
 | 4 | INTRODUCTION | 
 | 5 |  | 
 | 6 | The Scatterlist Crypto API takes page vectors (scatterlists) as | 
 | 7 | arguments, and works directly on pages.  In some cases (e.g. ECB | 
 | 8 | mode ciphers), this will allow for pages to be encrypted in-place | 
 | 9 | with no copying. | 
 | 10 |  | 
 | 11 | One of the initial goals of this design was to readily support IPsec, | 
 | 12 | so that processing can be applied to paged skb's without the need | 
 | 13 | for linearization. | 
 | 14 |  | 
 | 15 |  | 
 | 16 | DETAILS | 
 | 17 |  | 
 | 18 | At the lowest level are algorithms, which register dynamically with the | 
 | 19 | API. | 
 | 20 |  | 
 | 21 | 'Transforms' are user-instantiated objects, which maintain state, handle all | 
 | 22 | of the implementation logic (e.g. manipulating page vectors), provide an  | 
 | 23 | abstraction to the underlying algorithms, and handle common logical  | 
 | 24 | operations (e.g. cipher modes, HMAC for digests).  However, at the user  | 
 | 25 | level they are very simple. | 
 | 26 |  | 
 | 27 | Conceptually, the API layering looks like this: | 
 | 28 |  | 
 | 29 |   [transform api]  (user interface) | 
 | 30 |   [transform ops]  (per-type logic glue e.g. cipher.c, digest.c) | 
 | 31 |   [algorithm api]  (for registering algorithms) | 
 | 32 |    | 
 | 33 | The idea is to make the user interface and algorithm registration API | 
 | 34 | very simple, while hiding the core logic from both.  Many good ideas | 
 | 35 | from existing APIs such as Cryptoapi and Nettle have been adapted for this. | 
 | 36 |  | 
 | 37 | The API currently supports three types of transforms: Ciphers, Digests and | 
 | 38 | Compressors.  The compression algorithms especially seem to be performing | 
 | 39 | very well so far. | 
 | 40 |  | 
 | 41 | Support for hardware crypto devices via an asynchronous interface is | 
 | 42 | under development. | 
 | 43 |  | 
 | 44 | Here's an example of how to use the API: | 
 | 45 |  | 
 | 46 | 	#include <linux/crypto.h> | 
 | 47 | 	 | 
 | 48 | 	struct scatterlist sg[2]; | 
 | 49 | 	char result[128]; | 
 | 50 | 	struct crypto_tfm *tfm; | 
 | 51 | 	 | 
 | 52 | 	tfm = crypto_alloc_tfm("md5", 0); | 
 | 53 | 	if (tfm == NULL) | 
 | 54 | 		fail(); | 
 | 55 | 		 | 
 | 56 | 	/* ... set up the scatterlists ... */ | 
 | 57 | 	 | 
 | 58 | 	crypto_digest_init(tfm); | 
 | 59 | 	crypto_digest_update(tfm, &sg, 2); | 
 | 60 | 	crypto_digest_final(tfm, result); | 
 | 61 | 	 | 
 | 62 | 	crypto_free_tfm(tfm); | 
 | 63 |  | 
 | 64 |      | 
 | 65 | Many real examples are available in the regression test module (tcrypt.c). | 
 | 66 |  | 
 | 67 |  | 
 | 68 | CONFIGURATION NOTES | 
 | 69 |  | 
 | 70 | As Triple DES is part of the DES module, for those using modular builds, | 
 | 71 | add the following line to /etc/modprobe.conf: | 
 | 72 |  | 
 | 73 |   alias des3_ede des | 
 | 74 |  | 
 | 75 | The Null algorithms reside in the crypto_null module, so these lines | 
 | 76 | should also be added: | 
 | 77 |  | 
 | 78 |   alias cipher_null crypto_null | 
 | 79 |   alias digest_null crypto_null | 
 | 80 |   alias compress_null crypto_null | 
 | 81 |  | 
 | 82 | The SHA384 algorithm shares code within the SHA512 module, so you'll | 
 | 83 | also need: | 
 | 84 |   alias sha384 sha512 | 
 | 85 |  | 
 | 86 |  | 
 | 87 | DEVELOPER NOTES | 
 | 88 |  | 
 | 89 | Transforms may only be allocated in user context, and cryptographic | 
 | 90 | methods may only be called from softirq and user contexts. | 
 | 91 |  | 
 | 92 | When using the API for ciphers, performance will be optimal if each | 
 | 93 | scatterlist contains data which is a multiple of the cipher's block | 
 | 94 | size (typically 8 bytes).  This prevents having to do any copying | 
 | 95 | across non-aligned page fragment boundaries. | 
 | 96 |  | 
 | 97 |  | 
 | 98 | ADDING NEW ALGORITHMS | 
 | 99 |  | 
 | 100 | When submitting a new algorithm for inclusion, a mandatory requirement | 
 | 101 | is that at least a few test vectors from known sources (preferably | 
 | 102 | standards) be included. | 
 | 103 |  | 
 | 104 | Converting existing well known code is preferred, as it is more likely | 
 | 105 | to have been reviewed and widely tested.  If submitting code from LGPL | 
 | 106 | sources, please consider changing the license to GPL (see section 3 of | 
 | 107 | the LGPL). | 
 | 108 |  | 
 | 109 | Algorithms submitted must also be generally patent-free (e.g. IDEA | 
 | 110 | will not be included in the mainline until around 2011), and be based | 
 | 111 | on a recognized standard and/or have been subjected to appropriate | 
 | 112 | peer review. | 
 | 113 |  | 
 | 114 | Also check for any RFCs which may relate to the use of specific algorithms, | 
 | 115 | as well as general application notes such as RFC2451 ("The ESP CBC-Mode | 
 | 116 | Cipher Algorithms"). | 
 | 117 |  | 
 | 118 | It's a good idea to avoid using lots of macros and use inlined functions | 
 | 119 | instead, as gcc does a good job with inlining, while excessive use of | 
 | 120 | macros can cause compilation problems on some platforms. | 
 | 121 |  | 
 | 122 | Also check the TODO list at the web site listed below to see what people | 
 | 123 | might already be working on. | 
 | 124 |  | 
 | 125 |  | 
 | 126 | BUGS | 
 | 127 |  | 
 | 128 | Send bug reports to: | 
 | 129 | James Morris <jmorris@redhat.com> | 
 | 130 | Cc: David S. Miller <davem@redhat.com> | 
 | 131 |  | 
 | 132 |  | 
 | 133 | FURTHER INFORMATION | 
 | 134 |  | 
 | 135 | For further patches and various updates, including the current TODO | 
 | 136 | list, see: | 
 | 137 | http://samba.org/~jamesm/crypto/ | 
 | 138 |  | 
 | 139 |  | 
 | 140 | AUTHORS | 
 | 141 |  | 
 | 142 | James Morris | 
 | 143 | David S. Miller | 
 | 144 |  | 
 | 145 |  | 
 | 146 | CREDITS | 
 | 147 |  | 
 | 148 | The following people provided invaluable feedback during the development | 
 | 149 | of the API: | 
 | 150 |  | 
 | 151 |   Alexey Kuznetzov | 
 | 152 |   Rusty Russell | 
 | 153 |   Herbert Valerio Riedel | 
 | 154 |   Jeff Garzik | 
 | 155 |   Michael Richardson | 
 | 156 |   Andrew Morton | 
 | 157 |   Ingo Oeser | 
 | 158 |   Christoph Hellwig | 
 | 159 |  | 
 | 160 | Portions of this API were derived from the following projects: | 
 | 161 |    | 
 | 162 |   Kerneli Cryptoapi (http://www.kerneli.org/) | 
 | 163 |     Alexander Kjeldaas | 
 | 164 |     Herbert Valerio Riedel | 
 | 165 |     Kyle McMartin | 
 | 166 |     Jean-Luc Cooke | 
 | 167 |     David Bryson | 
 | 168 |     Clemens Fruhwirth | 
 | 169 |     Tobias Ringstrom | 
 | 170 |     Harald Welte | 
 | 171 |  | 
 | 172 | and; | 
 | 173 |    | 
 | 174 |   Nettle (http://www.lysator.liu.se/~nisse/nettle/) | 
 | 175 |     Niels Möller | 
 | 176 |  | 
 | 177 | Original developers of the crypto algorithms: | 
 | 178 |  | 
 | 179 |   Dana L. How (DES) | 
 | 180 |   Andrew Tridgell and Steve French (MD4) | 
 | 181 |   Colin Plumb (MD5) | 
 | 182 |   Steve Reid (SHA1) | 
 | 183 |   Jean-Luc Cooke (SHA256, SHA384, SHA512) | 
 | 184 |   Kazunori Miyazawa / USAGI (HMAC) | 
 | 185 |   Matthew Skala (Twofish) | 
 | 186 |   Dag Arne Osvik (Serpent) | 
 | 187 |   Brian Gladman (AES) | 
 | 188 |   Kartikey Mahendra Bhatt (CAST6) | 
 | 189 |   Jon Oberheide (ARC4) | 
 | 190 |   Jouni Malinen (Michael MIC) | 
 | 191 |  | 
 | 192 | SHA1 algorithm contributors: | 
 | 193 |   Jean-Francois Dive | 
 | 194 |    | 
 | 195 | DES algorithm contributors: | 
 | 196 |   Raimar Falke | 
 | 197 |   Gisle Sælensminde | 
 | 198 |   Niels Möller | 
 | 199 |  | 
 | 200 | Blowfish algorithm contributors: | 
 | 201 |   Herbert Valerio Riedel | 
 | 202 |   Kyle McMartin | 
 | 203 |  | 
 | 204 | Twofish algorithm contributors: | 
 | 205 |   Werner Koch | 
 | 206 |   Marc Mutz | 
 | 207 |  | 
 | 208 | SHA256/384/512 algorithm contributors: | 
 | 209 |   Andrew McDonald | 
 | 210 |   Kyle McMartin | 
 | 211 |   Herbert Valerio Riedel | 
 | 212 |    | 
 | 213 | AES algorithm contributors: | 
 | 214 |   Alexander Kjeldaas | 
 | 215 |   Herbert Valerio Riedel | 
 | 216 |   Kyle McMartin | 
 | 217 |   Adam J. Richter | 
 | 218 |   Fruhwirth Clemens (i586) | 
 | 219 |   Linus Torvalds (i586) | 
 | 220 |  | 
 | 221 | CAST5 algorithm contributors: | 
 | 222 |   Kartikey Mahendra Bhatt (original developers unknown, FSF copyright). | 
 | 223 |  | 
 | 224 | TEA/XTEA algorithm contributors: | 
 | 225 |   Aaron Grothe | 
| Aaron Grothe | fb4f10e | 2005-09-01 17:42:46 -0700 | [diff] [blame] | 226 |   Michael Ringe | 
| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 227 |  | 
 | 228 | Khazad algorithm contributors: | 
 | 229 |   Aaron Grothe | 
 | 230 |  | 
 | 231 | Whirlpool algorithm contributors: | 
 | 232 |   Aaron Grothe | 
 | 233 |   Jean-Luc Cooke | 
 | 234 |  | 
 | 235 | Anubis algorithm contributors: | 
 | 236 |   Aaron Grothe | 
 | 237 |  | 
 | 238 | Tiger algorithm contributors: | 
 | 239 |   Aaron Grothe | 
 | 240 |  | 
 | 241 | Generic scatterwalk code by Adam J. Richter <adam@yggdrasil.com> | 
 | 242 |  | 
 | 243 | Please send any credits updates or corrections to: | 
 | 244 | James Morris <jmorris@redhat.com> | 
 | 245 |  |