media: ov5640: change 1080p resolution to 1088p
[linux-2.6.git] / Documentation / crypto / api-intro.txt
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) and provide an 
23 abstraction to the underlying algorithms.  However, at the user 
24 level they are very simple.
25
26 Conceptually, the API layering looks like this:
27
28   [transform api]  (user interface)
29   [transform ops]  (per-type logic glue e.g. cipher.c, compress.c)
30   [algorithm api]  (for registering algorithms)
31   
32 The idea is to make the user interface and algorithm registration API
33 very simple, while hiding the core logic from both.  Many good ideas
34 from existing APIs such as Cryptoapi and Nettle have been adapted for this.
35
36 The API currently supports five main types of transforms: AEAD (Authenticated
37 Encryption with Associated Data), Block Ciphers, Ciphers, Compressors and
38 Hashes.
39
40 Please note that Block Ciphers is somewhat of a misnomer.  It is in fact
41 meant to support all ciphers including stream ciphers.  The difference
42 between Block Ciphers and Ciphers is that the latter operates on exactly
43 one block while the former can operate on an arbitrary amount of data,
44 subject to block size requirements (i.e., non-stream ciphers can only
45 process multiples of blocks).
46
47 Support for hardware crypto devices via an asynchronous interface is
48 under development.
49
50 Here's an example of how to use the API:
51
52         #include <linux/crypto.h>
53         #include <linux/err.h>
54         #include <linux/scatterlist.h>
55         
56         struct scatterlist sg[2];
57         char result[128];
58         struct crypto_hash *tfm;
59         struct hash_desc desc;
60         
61         tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
62         if (IS_ERR(tfm))
63                 fail();
64                 
65         /* ... set up the scatterlists ... */
66
67         desc.tfm = tfm;
68         desc.flags = 0;
69         
70         if (crypto_hash_digest(&desc, sg, 2, result))
71                 fail();
72         
73         crypto_free_hash(tfm);
74
75     
76 Many real examples are available in the regression test module (tcrypt.c).
77
78
79 DEVELOPER NOTES
80
81 Transforms may only be allocated in user context, and cryptographic
82 methods may only be called from softirq and user contexts.  For
83 transforms with a setkey method it too should only be called from
84 user context.
85
86 When using the API for ciphers, performance will be optimal if each
87 scatterlist contains data which is a multiple of the cipher's block
88 size (typically 8 bytes).  This prevents having to do any copying
89 across non-aligned page fragment boundaries.
90
91
92 ADDING NEW ALGORITHMS
93
94 When submitting a new algorithm for inclusion, a mandatory requirement
95 is that at least a few test vectors from known sources (preferably
96 standards) be included.
97
98 Converting existing well known code is preferred, as it is more likely
99 to have been reviewed and widely tested.  If submitting code from LGPL
100 sources, please consider changing the license to GPL (see section 3 of
101 the LGPL).
102
103 Algorithms submitted must also be generally patent-free (e.g. IDEA
104 will not be included in the mainline until around 2011), and be based
105 on a recognized standard and/or have been subjected to appropriate
106 peer review.
107
108 Also check for any RFCs which may relate to the use of specific algorithms,
109 as well as general application notes such as RFC2451 ("The ESP CBC-Mode
110 Cipher Algorithms").
111
112 It's a good idea to avoid using lots of macros and use inlined functions
113 instead, as gcc does a good job with inlining, while excessive use of
114 macros can cause compilation problems on some platforms.
115
116 Also check the TODO list at the web site listed below to see what people
117 might already be working on.
118
119
120 BUGS
121
122 Send bug reports to:
123 linux-crypto@vger.kernel.org
124 Cc: Herbert Xu <herbert@gondor.apana.org.au>,
125     David S. Miller <davem@redhat.com>
126
127
128 FURTHER INFORMATION
129
130 For further patches and various updates, including the current TODO
131 list, see:
132 http://gondor.apana.org.au/~herbert/crypto/
133
134
135 AUTHORS
136
137 James Morris
138 David S. Miller
139 Herbert Xu
140
141
142 CREDITS
143
144 The following people provided invaluable feedback during the development
145 of the API:
146
147   Alexey Kuznetzov
148   Rusty Russell
149   Herbert Valerio Riedel
150   Jeff Garzik
151   Michael Richardson
152   Andrew Morton
153   Ingo Oeser
154   Christoph Hellwig
155
156 Portions of this API were derived from the following projects:
157   
158   Kerneli Cryptoapi (http://www.kerneli.org/)
159     Alexander Kjeldaas
160     Herbert Valerio Riedel
161     Kyle McMartin
162     Jean-Luc Cooke
163     David Bryson
164     Clemens Fruhwirth
165     Tobias Ringstrom
166     Harald Welte
167
168 and;
169   
170   Nettle (http://www.lysator.liu.se/~nisse/nettle/)
171     Niels Möller
172
173 Original developers of the crypto algorithms:
174
175   Dana L. How (DES)
176   Andrew Tridgell and Steve French (MD4)
177   Colin Plumb (MD5)
178   Steve Reid (SHA1)
179   Jean-Luc Cooke (SHA256, SHA384, SHA512)
180   Kazunori Miyazawa / USAGI (HMAC)
181   Matthew Skala (Twofish)
182   Dag Arne Osvik (Serpent)
183   Brian Gladman (AES)
184   Kartikey Mahendra Bhatt (CAST6)
185   Jon Oberheide (ARC4)
186   Jouni Malinen (Michael MIC)
187   NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
188
189 SHA1 algorithm contributors:
190   Jean-Francois Dive
191   
192 DES algorithm contributors:
193   Raimar Falke
194   Gisle Sælensminde
195   Niels Möller
196
197 Blowfish algorithm contributors:
198   Herbert Valerio Riedel
199   Kyle McMartin
200
201 Twofish algorithm contributors:
202   Werner Koch
203   Marc Mutz
204
205 SHA256/384/512 algorithm contributors:
206   Andrew McDonald
207   Kyle McMartin
208   Herbert Valerio Riedel
209   
210 AES algorithm contributors:
211   Alexander Kjeldaas
212   Herbert Valerio Riedel
213   Kyle McMartin
214   Adam J. Richter
215   Fruhwirth Clemens (i586)
216   Linus Torvalds (i586)
217
218 CAST5 algorithm contributors:
219   Kartikey Mahendra Bhatt (original developers unknown, FSF copyright).
220
221 TEA/XTEA algorithm contributors:
222   Aaron Grothe
223   Michael Ringe
224
225 Khazad algorithm contributors:
226   Aaron Grothe
227
228 Whirlpool algorithm contributors:
229   Aaron Grothe
230   Jean-Luc Cooke
231
232 Anubis algorithm contributors:
233   Aaron Grothe
234
235 Tiger algorithm contributors:
236   Aaron Grothe
237
238 VIA PadLock contributors:
239   Michal Ludvig
240
241 Camellia algorithm contributors:
242   NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
243
244 Generic scatterwalk code by Adam J. Richter <adam@yggdrasil.com>
245
246 Please send any credits updates or corrections to:
247 Herbert Xu <herbert@gondor.apana.org.au>
248