api-intro.txt 6.1 KB

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