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