From f07c2e093541aacc69da893d98de5de30830a555 Mon Sep 17 00:00:00 2001 From: mpi <> Date: Wed, 16 Apr 2014 09:41:43 +0000 Subject: Remove pointless man pages that were not installed. ok miod@ --- src/lib/libssl/src/doc/crypto/OPENSSL_Applink.pod | 21 -- src/lib/libssl/src/doc/crypto/OPENSSL_ia32cap.pod | 43 ---- src/lib/libssl/src/doc/crypto/des_modes.pod | 255 ---------------------- src/lib/libssl/src/doc/crypto/mdc2.pod | 64 ------ 4 files changed, 383 deletions(-) delete mode 100644 src/lib/libssl/src/doc/crypto/OPENSSL_Applink.pod delete mode 100644 src/lib/libssl/src/doc/crypto/OPENSSL_ia32cap.pod delete mode 100644 src/lib/libssl/src/doc/crypto/des_modes.pod delete mode 100644 src/lib/libssl/src/doc/crypto/mdc2.pod (limited to 'src') 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 @@ -=pod - -=head1 NAME - -OPENSSL_Applink - glue between OpenSSL BIO and Win32 compiler run-time - -=head1 SYNOPSIS - - __declspec(dllexport) void **OPENSSL_Applink(); - -=head1 DESCRIPTION - -OPENSSL_Applink is application-side interface which provides a glue -between OpenSSL BIO layer and Win32 compiler run-time environment. -Even though it appears at application side, it's essentially OpenSSL -private interface. For this reason application developers are not -expected to implement it, but to compile provided module with -compiler of their choice and link it into the target application. -The referred module is available as /ms/applink.c. - -=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 @@ -=pod - -=head1 NAME - -OPENSSL_ia32cap - finding the IA-32 processor capabilities - -=head1 SYNOPSIS - - unsigned long *OPENSSL_ia32cap_loc(void); - #define OPENSSL_ia32cap (*(OPENSSL_ia32cap_loc())) - -=head1 DESCRIPTION - -Value returned by OPENSSL_ia32cap_loc() is address of a variable -containing IA-32 processor capabilities bit vector as it appears in EDX -register after executing CPUID instruction with EAX=1 input value (see -Intel Application Note #241618). Naturally it's meaningful on IA-32[E] -platforms only. The variable is normally set up automatically upon -toolkit initialization, but can be manipulated afterwards to modify -crypto library behaviour. For the moment of this writing six bits are -significant, namely: - -1. bit #28 denoting Hyperthreading, which is used to distiguish - cores with shared cache; -2. bit #26 denoting SSE2 support; -3. bit #25 denoting SSE support; -4. bit #23 denoting MMX support; -5. bit #20, reserved by Intel, is used to choose between RC4 code - pathes; -6. bit #4 denoting presence of Time-Stamp Counter. - -For example, clearing bit #26 at run-time disables high-performance -SSE2 code present in the crypto library. You might have to do this if -target OpenSSL application is executed on SSE2 capable CPU, but under -control of OS which does not support SSE2 extentions. Even though you -can manipulate the value programmatically, you most likely will find it -more appropriate to set up an environment variable with the same name -prior starting target application, e.g. on Intel P4 processor 'env -OPENSSL_ia32cap=0x12900010 apps/openssl', to achieve same effect -without modifying the application source code. Alternatively you can -reconfigure the toolkit with no-sse2 option and recompile. - -=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 @@ -=pod - -=for comment openssl_manual_section:7 - -=head1 NAME - -des_modes - the variants of DES and other crypto algorithms of OpenSSL - -=head1 DESCRIPTION - -Several crypto algorithms for OpenSSL can be used in a number of modes. Those -are used for using block ciphers in a way similar to stream ciphers, among -other things. - -=head1 OVERVIEW - -=head2 Electronic Codebook Mode (ECB) - -Normally, this is found as the function I_ecb_encrypt(). - -=over 2 - -=item * - -64 bits are enciphered at a time. - -=item * - -The order of the blocks can be rearranged without detection. - -=item * - -The same plaintext block always produces the same ciphertext block -(for the same key) making it vulnerable to a 'dictionary attack'. - -=item * - -An error will only affect one ciphertext block. - -=back - -=head2 Cipher Block Chaining Mode (CBC) - -Normally, this is found as the function I_cbc_encrypt(). -Be aware that des_cbc_encrypt() is not really DES CBC (it does -not update the IV); use des_ncbc_encrypt() instead. - -=over 2 - -=item * - -a multiple of 64 bits are enciphered at a time. - -=item * - -The CBC mode produces the same ciphertext whenever the same -plaintext is encrypted using the same key and starting variable. - -=item * - -The chaining operation makes the ciphertext blocks dependent on the -current and all preceding plaintext blocks and therefore blocks can not -be rearranged. - -=item * - -The use of different starting variables prevents the same plaintext -enciphering to the same ciphertext. - -=item * - -An error will affect the current and the following ciphertext blocks. - -=back - -=head2 Cipher Feedback Mode (CFB) - -Normally, this is found as the function I_cfb_encrypt(). - -=over 2 - -=item * - -a number of bits (j) <= 64 are enciphered at a time. - -=item * - -The CFB mode produces the same ciphertext whenever the same -plaintext is encrypted using the same key and starting variable. - -=item * - -The chaining operation makes the ciphertext variables dependent on the -current and all preceding variables and therefore j-bit variables are -chained together and can not be rearranged. - -=item * - -The use of different starting variables prevents the same plaintext -enciphering to the same ciphertext. - -=item * - -The strength of the CFB mode depends on the size of k (maximal if -j == k). In my implementation this is always the case. - -=item * - -Selection of a small value for j will require more cycles through -the encipherment algorithm per unit of plaintext and thus cause -greater processing overheads. - -=item * - -Only multiples of j bits can be enciphered. - -=item * - -An error will affect the current and the following ciphertext variables. - -=back - -=head2 Output Feedback Mode (OFB) - -Normally, this is found as the function I_ofb_encrypt(). - -=over 2 - - -=item * - -a number of bits (j) <= 64 are enciphered at a time. - -=item * - -The OFB mode produces the same ciphertext whenever the same -plaintext enciphered using the same key and starting variable. More -over, in the OFB mode the same key stream is produced when the same -key and start variable are used. Consequently, for security reasons -a specific start variable should be used only once for a given key. - -=item * - -The absence of chaining makes the OFB more vulnerable to specific attacks. - -=item * - -The use of different start variables values prevents the same -plaintext enciphering to the same ciphertext, by producing different -key streams. - -=item * - -Selection of a small value for j will require more cycles through -the encipherment algorithm per unit of plaintext and thus cause -greater processing overheads. - -=item * - -Only multiples of j bits can be enciphered. - -=item * - -OFB mode of operation does not extend ciphertext errors in the -resultant plaintext output. Every bit error in the ciphertext causes -only one bit to be in error in the deciphered plaintext. - -=item * - -OFB mode is not self-synchronizing. If the two operation of -encipherment and decipherment get out of synchronism, the system needs -to be re-initialized. - -=item * - -Each re-initialization should use a value of the start variable -different from the start variable values used before with the same -key. The reason for this is that an identical bit stream would be -produced each time from the same parameters. This would be -susceptible to a 'known plaintext' attack. - -=back - -=head2 Triple ECB Mode - -Normally, this is found as the function I_ecb3_encrypt(). - -=over 2 - -=item * - -Encrypt with key1, decrypt with key2 and encrypt with key3 again. - -=item * - -As for ECB encryption but increases the key length to 168 bits. -There are theoretic attacks that can be used that make the effective -key length 112 bits, but this attack also requires 2^56 blocks of -memory, not very likely, even for the NSA. - -=item * - -If both keys are the same it is equivalent to encrypting once with -just one key. - -=item * - -If the first and last key are the same, the key length is 112 bits. -There are attacks that could reduce the effective key strength -to only slightly more than 56 bits, but these require a lot of memory. - -=item * - -If all 3 keys are the same, this is effectively the same as normal -ecb mode. - -=back - -=head2 Triple CBC Mode - -Normally, this is found as the function I_ede3_cbc_encrypt(). - -=over 2 - - -=item * - -Encrypt with key1, decrypt with key2 and then encrypt with key3. - -=item * - -As for CBC encryption but increases the key length to 168 bits with -the same restrictions as for triple ecb mode. - -=back - -=head1 NOTES - -This text was been written in large parts by Eric Young in his original -documentation for SSLeay, the predecessor of OpenSSL. In turn, he attributed -it to: - - AS 2805.5.2 - Australian Standard - Electronic funds transfer - Requirements for interfaces, - Part 5.2: Modes of operation for an n-bit block cipher algorithm - Appendix A - -=head1 SEE ALSO - -L, L, L, -L - -=cut - 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 @@ -=pod - -=head1 NAME - -MDC2, MDC2_Init, MDC2_Update, MDC2_Final - MDC2 hash function - -=head1 SYNOPSIS - - #include - - unsigned char *MDC2(const unsigned char *d, unsigned long n, - unsigned char *md); - - int MDC2_Init(MDC2_CTX *c); - int MDC2_Update(MDC2_CTX *c, const unsigned char *data, - unsigned long len); - int MDC2_Final(unsigned char *md, MDC2_CTX *c); - -=head1 DESCRIPTION - -MDC2 is a method to construct hash functions with 128 bit output from -block ciphers. These functions are an implementation of MDC2 with -DES. - -MDC2() computes the MDC2 message digest of the B -bytes at B and places it in B (which must have space for -MDC2_DIGEST_LENGTH == 16 bytes of output). If B is NULL, the digest -is placed in a static array. - -The following functions may be used if the message is not completely -stored in memory: - -MDC2_Init() initializes a B structure. - -MDC2_Update() can be called repeatedly with chunks of the message to -be hashed (B bytes at B). - -MDC2_Final() places the message digest in B, which must have space -for MDC2_DIGEST_LENGTH == 16 bytes of output, and erases the B. - -Applications should use the higher level functions -L etc. instead of calling the -hash functions directly. - -=head1 RETURN VALUES - -MDC2() returns a pointer to the hash value. - -MDC2_Init(), MDC2_Update() and MDC2_Final() return 1 for success, 0 otherwise. - -=head1 CONFORMING TO - -ISO/IEC 10118-2, with DES - -=head1 SEE ALSO - -L, L - -=head1 HISTORY - -MDC2(), MDC2_Init(), MDC2_Update() and MDC2_Final() are available since -SSLeay 0.8. - -=cut -- cgit v1.2.3-55-g6feb