diff options
author | mpi <> | 2014-04-16 09:41:43 +0000 |
---|---|---|
committer | mpi <> | 2014-04-16 09:41:43 +0000 |
commit | f07c2e093541aacc69da893d98de5de30830a555 (patch) | |
tree | 99b4a896b398fa0f72a3528260ffcf7ce0270cb4 /src/lib | |
parent | bf2220a44cf28b09cc5803cff9dc8a0c57ea9444 (diff) | |
download | openbsd-f07c2e093541aacc69da893d98de5de30830a555.tar.gz openbsd-f07c2e093541aacc69da893d98de5de30830a555.tar.bz2 openbsd-f07c2e093541aacc69da893d98de5de30830a555.zip |
Remove pointless man pages that were not installed.
ok miod@
Diffstat (limited to 'src/lib')
-rw-r--r-- | src/lib/libssl/src/doc/crypto/OPENSSL_Applink.pod | 21 | ||||
-rw-r--r-- | src/lib/libssl/src/doc/crypto/OPENSSL_ia32cap.pod | 43 | ||||
-rw-r--r-- | src/lib/libssl/src/doc/crypto/des_modes.pod | 255 | ||||
-rw-r--r-- | src/lib/libssl/src/doc/crypto/mdc2.pod | 64 |
4 files changed, 0 insertions, 383 deletions
diff --git a/src/lib/libssl/src/doc/crypto/OPENSSL_Applink.pod b/src/lib/libssl/src/doc/crypto/OPENSSL_Applink.pod deleted file mode 100644 index e54de12cc8..0000000000 --- a/src/lib/libssl/src/doc/crypto/OPENSSL_Applink.pod +++ /dev/null | |||
@@ -1,21 +0,0 @@ | |||
1 | =pod | ||
2 | |||
3 | =head1 NAME | ||
4 | |||
5 | OPENSSL_Applink - glue between OpenSSL BIO and Win32 compiler run-time | ||
6 | |||
7 | =head1 SYNOPSIS | ||
8 | |||
9 | __declspec(dllexport) void **OPENSSL_Applink(); | ||
10 | |||
11 | =head1 DESCRIPTION | ||
12 | |||
13 | OPENSSL_Applink is application-side interface which provides a glue | ||
14 | between OpenSSL BIO layer and Win32 compiler run-time environment. | ||
15 | Even though it appears at application side, it's essentially OpenSSL | ||
16 | private interface. For this reason application developers are not | ||
17 | expected to implement it, but to compile provided module with | ||
18 | compiler of their choice and link it into the target application. | ||
19 | The referred module is available as <openssl>/ms/applink.c. | ||
20 | |||
21 | =cut | ||
diff --git a/src/lib/libssl/src/doc/crypto/OPENSSL_ia32cap.pod b/src/lib/libssl/src/doc/crypto/OPENSSL_ia32cap.pod deleted file mode 100644 index 2e659d34a5..0000000000 --- a/src/lib/libssl/src/doc/crypto/OPENSSL_ia32cap.pod +++ /dev/null | |||
@@ -1,43 +0,0 @@ | |||
1 | =pod | ||
2 | |||
3 | =head1 NAME | ||
4 | |||
5 | OPENSSL_ia32cap - finding the IA-32 processor capabilities | ||
6 | |||
7 | =head1 SYNOPSIS | ||
8 | |||
9 | unsigned long *OPENSSL_ia32cap_loc(void); | ||
10 | #define OPENSSL_ia32cap (*(OPENSSL_ia32cap_loc())) | ||
11 | |||
12 | =head1 DESCRIPTION | ||
13 | |||
14 | Value returned by OPENSSL_ia32cap_loc() is address of a variable | ||
15 | containing IA-32 processor capabilities bit vector as it appears in EDX | ||
16 | register after executing CPUID instruction with EAX=1 input value (see | ||
17 | Intel Application Note #241618). Naturally it's meaningful on IA-32[E] | ||
18 | platforms only. The variable is normally set up automatically upon | ||
19 | toolkit initialization, but can be manipulated afterwards to modify | ||
20 | crypto library behaviour. For the moment of this writing six bits are | ||
21 | significant, namely: | ||
22 | |||
23 | 1. bit #28 denoting Hyperthreading, which is used to distiguish | ||
24 | cores with shared cache; | ||
25 | 2. bit #26 denoting SSE2 support; | ||
26 | 3. bit #25 denoting SSE support; | ||
27 | 4. bit #23 denoting MMX support; | ||
28 | 5. bit #20, reserved by Intel, is used to choose between RC4 code | ||
29 | pathes; | ||
30 | 6. bit #4 denoting presence of Time-Stamp Counter. | ||
31 | |||
32 | For example, clearing bit #26 at run-time disables high-performance | ||
33 | SSE2 code present in the crypto library. You might have to do this if | ||
34 | target OpenSSL application is executed on SSE2 capable CPU, but under | ||
35 | control of OS which does not support SSE2 extentions. Even though you | ||
36 | can manipulate the value programmatically, you most likely will find it | ||
37 | more appropriate to set up an environment variable with the same name | ||
38 | prior starting target application, e.g. on Intel P4 processor 'env | ||
39 | OPENSSL_ia32cap=0x12900010 apps/openssl', to achieve same effect | ||
40 | without modifying the application source code. Alternatively you can | ||
41 | reconfigure the toolkit with no-sse2 option and recompile. | ||
42 | |||
43 | =cut | ||
diff --git a/src/lib/libssl/src/doc/crypto/des_modes.pod b/src/lib/libssl/src/doc/crypto/des_modes.pod deleted file mode 100644 index e883ca8fde..0000000000 --- a/src/lib/libssl/src/doc/crypto/des_modes.pod +++ /dev/null | |||
@@ -1,255 +0,0 @@ | |||
1 | =pod | ||
2 | |||
3 | =for comment openssl_manual_section:7 | ||
4 | |||
5 | =head1 NAME | ||
6 | |||
7 | des_modes - the variants of DES and other crypto algorithms of OpenSSL | ||
8 | |||
9 | =head1 DESCRIPTION | ||
10 | |||
11 | Several crypto algorithms for OpenSSL can be used in a number of modes. Those | ||
12 | are used for using block ciphers in a way similar to stream ciphers, among | ||
13 | other things. | ||
14 | |||
15 | =head1 OVERVIEW | ||
16 | |||
17 | =head2 Electronic Codebook Mode (ECB) | ||
18 | |||
19 | Normally, this is found as the function I<algorithm>_ecb_encrypt(). | ||
20 | |||
21 | =over 2 | ||
22 | |||
23 | =item * | ||
24 | |||
25 | 64 bits are enciphered at a time. | ||
26 | |||
27 | =item * | ||
28 | |||
29 | The order of the blocks can be rearranged without detection. | ||
30 | |||
31 | =item * | ||
32 | |||
33 | The same plaintext block always produces the same ciphertext block | ||
34 | (for the same key) making it vulnerable to a 'dictionary attack'. | ||
35 | |||
36 | =item * | ||
37 | |||
38 | An error will only affect one ciphertext block. | ||
39 | |||
40 | =back | ||
41 | |||
42 | =head2 Cipher Block Chaining Mode (CBC) | ||
43 | |||
44 | Normally, this is found as the function I<algorithm>_cbc_encrypt(). | ||
45 | Be aware that des_cbc_encrypt() is not really DES CBC (it does | ||
46 | not update the IV); use des_ncbc_encrypt() instead. | ||
47 | |||
48 | =over 2 | ||
49 | |||
50 | =item * | ||
51 | |||
52 | a multiple of 64 bits are enciphered at a time. | ||
53 | |||
54 | =item * | ||
55 | |||
56 | The CBC mode produces the same ciphertext whenever the same | ||
57 | plaintext is encrypted using the same key and starting variable. | ||
58 | |||
59 | =item * | ||
60 | |||
61 | The chaining operation makes the ciphertext blocks dependent on the | ||
62 | current and all preceding plaintext blocks and therefore blocks can not | ||
63 | be rearranged. | ||
64 | |||
65 | =item * | ||
66 | |||
67 | The use of different starting variables prevents the same plaintext | ||
68 | enciphering to the same ciphertext. | ||
69 | |||
70 | =item * | ||
71 | |||
72 | An error will affect the current and the following ciphertext blocks. | ||
73 | |||
74 | =back | ||
75 | |||
76 | =head2 Cipher Feedback Mode (CFB) | ||
77 | |||
78 | Normally, this is found as the function I<algorithm>_cfb_encrypt(). | ||
79 | |||
80 | =over 2 | ||
81 | |||
82 | =item * | ||
83 | |||
84 | a number of bits (j) <= 64 are enciphered at a time. | ||
85 | |||
86 | =item * | ||
87 | |||
88 | The CFB mode produces the same ciphertext whenever the same | ||
89 | plaintext is encrypted using the same key and starting variable. | ||
90 | |||
91 | =item * | ||
92 | |||
93 | The chaining operation makes the ciphertext variables dependent on the | ||
94 | current and all preceding variables and therefore j-bit variables are | ||
95 | chained together and can not be rearranged. | ||
96 | |||
97 | =item * | ||
98 | |||
99 | The use of different starting variables prevents the same plaintext | ||
100 | enciphering to the same ciphertext. | ||
101 | |||
102 | =item * | ||
103 | |||
104 | The strength of the CFB mode depends on the size of k (maximal if | ||
105 | j == k). In my implementation this is always the case. | ||
106 | |||
107 | =item * | ||
108 | |||
109 | Selection of a small value for j will require more cycles through | ||
110 | the encipherment algorithm per unit of plaintext and thus cause | ||
111 | greater processing overheads. | ||
112 | |||
113 | =item * | ||
114 | |||
115 | Only multiples of j bits can be enciphered. | ||
116 | |||
117 | =item * | ||
118 | |||
119 | An error will affect the current and the following ciphertext variables. | ||
120 | |||
121 | =back | ||
122 | |||
123 | =head2 Output Feedback Mode (OFB) | ||
124 | |||
125 | Normally, this is found as the function I<algorithm>_ofb_encrypt(). | ||
126 | |||
127 | =over 2 | ||
128 | |||
129 | |||
130 | =item * | ||
131 | |||
132 | a number of bits (j) <= 64 are enciphered at a time. | ||
133 | |||
134 | =item * | ||
135 | |||
136 | The OFB mode produces the same ciphertext whenever the same | ||
137 | plaintext enciphered using the same key and starting variable. More | ||
138 | over, in the OFB mode the same key stream is produced when the same | ||
139 | key and start variable are used. Consequently, for security reasons | ||
140 | a specific start variable should be used only once for a given key. | ||
141 | |||
142 | =item * | ||
143 | |||
144 | The absence of chaining makes the OFB more vulnerable to specific attacks. | ||
145 | |||
146 | =item * | ||
147 | |||
148 | The use of different start variables values prevents the same | ||
149 | plaintext enciphering to the same ciphertext, by producing different | ||
150 | key streams. | ||
151 | |||
152 | =item * | ||
153 | |||
154 | Selection of a small value for j will require more cycles through | ||
155 | the encipherment algorithm per unit of plaintext and thus cause | ||
156 | greater processing overheads. | ||
157 | |||
158 | =item * | ||
159 | |||
160 | Only multiples of j bits can be enciphered. | ||
161 | |||
162 | =item * | ||
163 | |||
164 | OFB mode of operation does not extend ciphertext errors in the | ||
165 | resultant plaintext output. Every bit error in the ciphertext causes | ||
166 | only one bit to be in error in the deciphered plaintext. | ||
167 | |||
168 | =item * | ||
169 | |||
170 | OFB mode is not self-synchronizing. If the two operation of | ||
171 | encipherment and decipherment get out of synchronism, the system needs | ||
172 | to be re-initialized. | ||
173 | |||
174 | =item * | ||
175 | |||
176 | Each re-initialization should use a value of the start variable | ||
177 | different from the start variable values used before with the same | ||
178 | key. The reason for this is that an identical bit stream would be | ||
179 | produced each time from the same parameters. This would be | ||
180 | susceptible to a 'known plaintext' attack. | ||
181 | |||
182 | =back | ||
183 | |||
184 | =head2 Triple ECB Mode | ||
185 | |||
186 | Normally, this is found as the function I<algorithm>_ecb3_encrypt(). | ||
187 | |||
188 | =over 2 | ||
189 | |||
190 | =item * | ||
191 | |||
192 | Encrypt with key1, decrypt with key2 and encrypt with key3 again. | ||
193 | |||
194 | =item * | ||
195 | |||
196 | As for ECB encryption but increases the key length to 168 bits. | ||
197 | There are theoretic attacks that can be used that make the effective | ||
198 | key length 112 bits, but this attack also requires 2^56 blocks of | ||
199 | memory, not very likely, even for the NSA. | ||
200 | |||
201 | =item * | ||
202 | |||
203 | If both keys are the same it is equivalent to encrypting once with | ||
204 | just one key. | ||
205 | |||
206 | =item * | ||
207 | |||
208 | If the first and last key are the same, the key length is 112 bits. | ||
209 | There are attacks that could reduce the effective key strength | ||
210 | to only slightly more than 56 bits, but these require a lot of memory. | ||
211 | |||
212 | =item * | ||
213 | |||
214 | If all 3 keys are the same, this is effectively the same as normal | ||
215 | ecb mode. | ||
216 | |||
217 | =back | ||
218 | |||
219 | =head2 Triple CBC Mode | ||
220 | |||
221 | Normally, this is found as the function I<algorithm>_ede3_cbc_encrypt(). | ||
222 | |||
223 | =over 2 | ||
224 | |||
225 | |||
226 | =item * | ||
227 | |||
228 | Encrypt with key1, decrypt with key2 and then encrypt with key3. | ||
229 | |||
230 | =item * | ||
231 | |||
232 | As for CBC encryption but increases the key length to 168 bits with | ||
233 | the same restrictions as for triple ecb mode. | ||
234 | |||
235 | =back | ||
236 | |||
237 | =head1 NOTES | ||
238 | |||
239 | This text was been written in large parts by Eric Young in his original | ||
240 | documentation for SSLeay, the predecessor of OpenSSL. In turn, he attributed | ||
241 | it to: | ||
242 | |||
243 | AS 2805.5.2 | ||
244 | Australian Standard | ||
245 | Electronic funds transfer - Requirements for interfaces, | ||
246 | Part 5.2: Modes of operation for an n-bit block cipher algorithm | ||
247 | Appendix A | ||
248 | |||
249 | =head1 SEE ALSO | ||
250 | |||
251 | L<blowfish(3)|blowfish(3)>, L<des(3)|des(3)>, L<idea(3)|idea(3)>, | ||
252 | L<rc2(3)|rc2(3)> | ||
253 | |||
254 | =cut | ||
255 | |||
diff --git a/src/lib/libssl/src/doc/crypto/mdc2.pod b/src/lib/libssl/src/doc/crypto/mdc2.pod deleted file mode 100644 index 41f648af36..0000000000 --- a/src/lib/libssl/src/doc/crypto/mdc2.pod +++ /dev/null | |||
@@ -1,64 +0,0 @@ | |||
1 | =pod | ||
2 | |||
3 | =head1 NAME | ||
4 | |||
5 | MDC2, MDC2_Init, MDC2_Update, MDC2_Final - MDC2 hash function | ||
6 | |||
7 | =head1 SYNOPSIS | ||
8 | |||
9 | #include <openssl/mdc2.h> | ||
10 | |||
11 | unsigned char *MDC2(const unsigned char *d, unsigned long n, | ||
12 | unsigned char *md); | ||
13 | |||
14 | int MDC2_Init(MDC2_CTX *c); | ||
15 | int MDC2_Update(MDC2_CTX *c, const unsigned char *data, | ||
16 | unsigned long len); | ||
17 | int MDC2_Final(unsigned char *md, MDC2_CTX *c); | ||
18 | |||
19 | =head1 DESCRIPTION | ||
20 | |||
21 | MDC2 is a method to construct hash functions with 128 bit output from | ||
22 | block ciphers. These functions are an implementation of MDC2 with | ||
23 | DES. | ||
24 | |||
25 | MDC2() computes the MDC2 message digest of the B<n> | ||
26 | bytes at B<d> and places it in B<md> (which must have space for | ||
27 | MDC2_DIGEST_LENGTH == 16 bytes of output). If B<md> is NULL, the digest | ||
28 | is placed in a static array. | ||
29 | |||
30 | The following functions may be used if the message is not completely | ||
31 | stored in memory: | ||
32 | |||
33 | MDC2_Init() initializes a B<MDC2_CTX> structure. | ||
34 | |||
35 | MDC2_Update() can be called repeatedly with chunks of the message to | ||
36 | be hashed (B<len> bytes at B<data>). | ||
37 | |||
38 | MDC2_Final() places the message digest in B<md>, which must have space | ||
39 | for MDC2_DIGEST_LENGTH == 16 bytes of output, and erases the B<MDC2_CTX>. | ||
40 | |||
41 | Applications should use the higher level functions | ||
42 | L<EVP_DigestInit(3)|EVP_DigestInit(3)> etc. instead of calling the | ||
43 | hash functions directly. | ||
44 | |||
45 | =head1 RETURN VALUES | ||
46 | |||
47 | MDC2() returns a pointer to the hash value. | ||
48 | |||
49 | MDC2_Init(), MDC2_Update() and MDC2_Final() return 1 for success, 0 otherwise. | ||
50 | |||
51 | =head1 CONFORMING TO | ||
52 | |||
53 | ISO/IEC 10118-2, with DES | ||
54 | |||
55 | =head1 SEE ALSO | ||
56 | |||
57 | L<sha(3)|sha(3)>, L<EVP_DigestInit(3)|EVP_DigestInit(3)> | ||
58 | |||
59 | =head1 HISTORY | ||
60 | |||
61 | MDC2(), MDC2_Init(), MDC2_Update() and MDC2_Final() are available since | ||
62 | SSLeay 0.8. | ||
63 | |||
64 | =cut | ||