diff options
| author | mpi <> | 2014-04-16 09:41:43 +0000 |
|---|---|---|
| committer | mpi <> | 2014-04-16 09:41:43 +0000 |
| commit | d5b26300bc82f8a2a72ff6b17c328651da5310b5 (patch) | |
| tree | 99b4a896b398fa0f72a3528260ffcf7ce0270cb4 | |
| parent | 4f235418d4ced95818959221d4a4f9180ef89b47 (diff) | |
| download | openbsd-d5b26300bc82f8a2a72ff6b17c328651da5310b5.tar.gz openbsd-d5b26300bc82f8a2a72ff6b17c328651da5310b5.tar.bz2 openbsd-d5b26300bc82f8a2a72ff6b17c328651da5310b5.zip | |
Remove pointless man pages that were not installed.
ok miod@
Diffstat (limited to '')
| -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 | ||
