+++ /dev/null
-=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
+++ /dev/null
-=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<algorithm>_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<algorithm>_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<algorithm>_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<algorithm>_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<algorithm>_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<algorithm>_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<blowfish(3)|blowfish(3)>, L<des(3)|des(3)>, L<idea(3)|idea(3)>,
-L<rc2(3)|rc2(3)>
-
-=cut
-
+++ /dev/null
-=pod
-
-=head1 NAME
-
-MDC2, MDC2_Init, MDC2_Update, MDC2_Final - MDC2 hash function
-
-=head1 SYNOPSIS
-
- #include <openssl/mdc2.h>
-
- 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<n>
-bytes at B<d> and places it in B<md> (which must have space for
-MDC2_DIGEST_LENGTH == 16 bytes of output). If B<md> 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<MDC2_CTX> structure.
-
-MDC2_Update() can be called repeatedly with chunks of the message to
-be hashed (B<len> bytes at B<data>).
-
-MDC2_Final() places the message digest in B<md>, which must have space
-for MDC2_DIGEST_LENGTH == 16 bytes of output, and erases the B<MDC2_CTX>.
-
-Applications should use the higher level functions
-L<EVP_DigestInit(3)|EVP_DigestInit(3)> 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<sha(3)|sha(3)>, L<EVP_DigestInit(3)|EVP_DigestInit(3)>
-
-=head1 HISTORY
-
-MDC2(), MDC2_Init(), MDC2_Update() and MDC2_Final() are available since
-SSLeay 0.8.
-
-=cut
projects / openbsd / commitdiff