aboutsummaryrefslogtreecommitdiffstats
path: root/crypto/Kconfig
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@ppc970.osdl.org>2005-04-16 18:20:36 -0400
committerLinus Torvalds <torvalds@ppc970.osdl.org>2005-04-16 18:20:36 -0400
commit1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch)
tree0bba044c4ce775e45a88a51686b5d9f90697ea9d /crypto/Kconfig
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
Diffstat (limited to 'crypto/Kconfig')
-rw-r--r--crypto/Kconfig292
1 files changed, 292 insertions, 0 deletions
diff --git a/crypto/Kconfig b/crypto/Kconfig
new file mode 100644
index 000000000000..536754faf4d2
--- /dev/null
+++ b/crypto/Kconfig
@@ -0,0 +1,292 @@
1#
2# Cryptographic API Configuration
3#
4
5menu "Cryptographic options"
6
7config CRYPTO
8 bool "Cryptographic API"
9 help
10 This option provides the core Cryptographic API.
11
12config CRYPTO_HMAC
13 bool "HMAC support"
14 depends on CRYPTO
15 help
16 HMAC: Keyed-Hashing for Message Authentication (RFC2104).
17 This is required for IPSec.
18
19config CRYPTO_NULL
20 tristate "Null algorithms"
21 depends on CRYPTO
22 help
23 These are 'Null' algorithms, used by IPsec, which do nothing.
24
25config CRYPTO_MD4
26 tristate "MD4 digest algorithm"
27 depends on CRYPTO
28 help
29 MD4 message digest algorithm (RFC1320).
30
31config CRYPTO_MD5
32 tristate "MD5 digest algorithm"
33 depends on CRYPTO
34 help
35 MD5 message digest algorithm (RFC1321).
36
37config CRYPTO_SHA1
38 tristate "SHA1 digest algorithm"
39 depends on CRYPTO
40 help
41 SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2).
42
43config CRYPTO_SHA1_Z990
44 tristate "SHA1 digest algorithm for IBM zSeries z990"
45 depends on CRYPTO && ARCH_S390
46 help
47 SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2).
48
49config CRYPTO_SHA256
50 tristate "SHA256 digest algorithm"
51 depends on CRYPTO
52 help
53 SHA256 secure hash standard (DFIPS 180-2).
54
55 This version of SHA implements a 256 bit hash with 128 bits of
56 security against collision attacks.
57
58config CRYPTO_SHA512
59 tristate "SHA384 and SHA512 digest algorithms"
60 depends on CRYPTO
61 help
62 SHA512 secure hash standard (DFIPS 180-2).
63
64 This version of SHA implements a 512 bit hash with 256 bits of
65 security against collision attacks.
66
67 This code also includes SHA-384, a 384 bit hash with 192 bits
68 of security against collision attacks.
69
70config CRYPTO_WP512
71 tristate "Whirlpool digest algorithms"
72 depends on CRYPTO
73 help
74 Whirlpool hash algorithm 512, 384 and 256-bit hashes
75
76 Whirlpool-512 is part of the NESSIE cryptographic primitives.
77 Whirlpool will be part of the ISO/IEC 10118-3:2003(E) standard
78
79 See also:
80 <http://planeta.terra.com.br/informatica/paulobarreto/WhirlpoolPage.html>
81
82config CRYPTO_TGR192
83 tristate "Tiger digest algorithms"
84 depends on CRYPTO
85 help
86 Tiger hash algorithm 192, 160 and 128-bit hashes
87
88 Tiger is a hash function optimized for 64-bit processors while
89 still having decent performance on 32-bit processors.
90 Tiger was developed by Ross Anderson and Eli Biham.
91
92 See also:
93 <http://www.cs.technion.ac.il/~biham/Reports/Tiger/>.
94
95config CRYPTO_DES
96 tristate "DES and Triple DES EDE cipher algorithms"
97 depends on CRYPTO
98 help
99 DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3).
100
101config CRYPTO_DES_Z990
102 tristate "DES and Triple DES cipher algorithms for IBM zSeries z990"
103 depends on CRYPTO && ARCH_S390
104 help
105 DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3).
106
107config CRYPTO_BLOWFISH
108 tristate "Blowfish cipher algorithm"
109 depends on CRYPTO
110 help
111 Blowfish cipher algorithm, by Bruce Schneier.
112
113 This is a variable key length cipher which can use keys from 32
114 bits to 448 bits in length. It's fast, simple and specifically
115 designed for use on "large microprocessors".
116
117 See also:
118 <http://www.schneier.com/blowfish.html>
119
120config CRYPTO_TWOFISH
121 tristate "Twofish cipher algorithm"
122 depends on CRYPTO
123 help
124 Twofish cipher algorithm.
125
126 Twofish was submitted as an AES (Advanced Encryption Standard)
127 candidate cipher by researchers at CounterPane Systems. It is a
128 16 round block cipher supporting key sizes of 128, 192, and 256
129 bits.
130
131 See also:
132 <http://www.schneier.com/twofish.html>
133
134config CRYPTO_SERPENT
135 tristate "Serpent cipher algorithm"
136 depends on CRYPTO
137 help
138 Serpent cipher algorithm, by Anderson, Biham & Knudsen.
139
140 Keys are allowed to be from 0 to 256 bits in length, in steps
141 of 8 bits. Also includes the 'Tnepres' algorithm, a reversed
142 variant of Serpent for compatibility with old kerneli code.
143
144 See also:
145 <http://www.cl.cam.ac.uk/~rja14/serpent.html>
146
147config CRYPTO_AES
148 tristate "AES cipher algorithms"
149 depends on CRYPTO && !(X86 && !X86_64)
150 help
151 AES cipher algorithms (FIPS-197). AES uses the Rijndael
152 algorithm.
153
154 Rijndael appears to be consistently a very good performer in
155 both hardware and software across a wide range of computing
156 environments regardless of its use in feedback or non-feedback
157 modes. Its key setup time is excellent, and its key agility is
158 good. Rijndael's very low memory requirements make it very well
159 suited for restricted-space environments, in which it also
160 demonstrates excellent performance. Rijndael's operations are
161 among the easiest to defend against power and timing attacks.
162
163 The AES specifies three key sizes: 128, 192 and 256 bits
164
165 See <http://csrc.nist.gov/CryptoToolkit/aes/> for more information.
166
167config CRYPTO_AES_586
168 tristate "AES cipher algorithms (i586)"
169 depends on CRYPTO && (X86 && !X86_64)
170 help
171 AES cipher algorithms (FIPS-197). AES uses the Rijndael
172 algorithm.
173
174 Rijndael appears to be consistently a very good performer in
175 both hardware and software across a wide range of computing
176 environments regardless of its use in feedback or non-feedback
177 modes. Its key setup time is excellent, and its key agility is
178 good. Rijndael's very low memory requirements make it very well
179 suited for restricted-space environments, in which it also
180 demonstrates excellent performance. Rijndael's operations are
181 among the easiest to defend against power and timing attacks.
182
183 The AES specifies three key sizes: 128, 192 and 256 bits
184
185 See <http://csrc.nist.gov/encryption/aes/> for more information.
186
187config CRYPTO_CAST5
188 tristate "CAST5 (CAST-128) cipher algorithm"
189 depends on CRYPTO
190 help
191 The CAST5 encryption algorithm (synonymous with CAST-128) is
192 described in RFC2144.
193
194config CRYPTO_CAST6
195 tristate "CAST6 (CAST-256) cipher algorithm"
196 depends on CRYPTO
197 help
198 The CAST6 encryption algorithm (synonymous with CAST-256) is
199 described in RFC2612.
200
201config CRYPTO_TEA
202 tristate "TEA and XTEA cipher algorithms"
203 depends on CRYPTO
204 help
205 TEA cipher algorithm.
206
207 Tiny Encryption Algorithm is a simple cipher that uses
208 many rounds for security. It is very fast and uses
209 little memory.
210
211 Xtendend Tiny Encryption Algorithm is a modification to
212 the TEA algorithm to address a potential key weakness
213 in the TEA algorithm.
214
215config CRYPTO_ARC4
216 tristate "ARC4 cipher algorithm"
217 depends on CRYPTO
218 help
219 ARC4 cipher algorithm.
220
221 ARC4 is a stream cipher using keys ranging from 8 bits to 2048
222 bits in length. This algorithm is required for driver-based
223 WEP, but it should not be for other purposes because of the
224 weakness of the algorithm.
225
226config CRYPTO_KHAZAD
227 tristate "Khazad cipher algorithm"
228 depends on CRYPTO
229 help
230 Khazad cipher algorithm.
231
232 Khazad was a finalist in the initial NESSIE competition. It is
233 an algorithm optimized for 64-bit processors with good performance
234 on 32-bit processors. Khazad uses an 128 bit key size.
235
236 See also:
237 <http://planeta.terra.com.br/informatica/paulobarreto/KhazadPage.html>
238
239config CRYPTO_ANUBIS
240 tristate "Anubis cipher algorithm"
241 depends on CRYPTO
242 help
243 Anubis cipher algorithm.
244
245 Anubis is a variable key length cipher which can use keys from
246 128 bits to 320 bits in length. It was evaluated as a entrant
247 in the NESSIE competition.
248
249 See also:
250 <https://www.cosic.esat.kuleuven.ac.be/nessie/reports/>
251 <http://planeta.terra.com.br/informatica/paulobarreto/AnubisPage.html>
252
253
254config CRYPTO_DEFLATE
255 tristate "Deflate compression algorithm"
256 depends on CRYPTO
257 select ZLIB_INFLATE
258 select ZLIB_DEFLATE
259 help
260 This is the Deflate algorithm (RFC1951), specified for use in
261 IPSec with the IPCOMP protocol (RFC3173, RFC2394).
262
263 You will most probably want this if using IPSec.
264
265config CRYPTO_MICHAEL_MIC
266 tristate "Michael MIC keyed digest algorithm"
267 depends on CRYPTO
268 help
269 Michael MIC is used for message integrity protection in TKIP
270 (IEEE 802.11i). This algorithm is required for TKIP, but it
271 should not be used for other purposes because of the weakness
272 of the algorithm.
273
274config CRYPTO_CRC32C
275 tristate "CRC32c CRC algorithm"
276 depends on CRYPTO
277 select LIBCRC32C
278 help
279 Castagnoli, et al Cyclic Redundancy-Check Algorithm. Used
280 by iSCSI for header and data digests and by others.
281 See Castagnoli93. This implementation uses lib/libcrc32c.
282 Module will be crc32c.
283
284config CRYPTO_TEST
285 tristate "Testing module"
286 depends on CRYPTO
287 help
288 Quick & dirty crypto test module.
289
290source "drivers/crypto/Kconfig"
291endmenu
292