Sync the list of man pages for libcrypto, explicity rename conflicting

pages instead of doing it in the Makefiles and move a libssl page where
it belongs.

ok miod@

9 files changed, 1500 insertions, 0 deletions

diff --git a/lib/libcrypto/doc/DES_set_key.pod b/lib/libcrypto/doc/DES_set_key.pod
new file mode 100644
index 00000000000..6f0cf1cc5e5
--- /dev/null
+++ b/lib/libcrypto/doc/DES_set_key.pod
@@ -0,0 +1,358 @@
+=pod
+
+=head1 NAME
+
+DES_random_key, DES_set_key, DES_key_sched, DES_set_key_checked,
+DES_set_key_unchecked, DES_set_odd_parity, DES_is_weak_key,
+DES_ecb_encrypt, DES_ecb2_encrypt, DES_ecb3_encrypt, DES_ncbc_encrypt,
+DES_cfb_encrypt, DES_ofb_encrypt, DES_pcbc_encrypt, DES_cfb64_encrypt,
+DES_ofb64_encrypt, DES_xcbc_encrypt, DES_ede2_cbc_encrypt,
+DES_ede2_cfb64_encrypt, DES_ede2_ofb64_encrypt, DES_ede3_cbc_encrypt,
+DES_ede3_cbcm_encrypt, DES_ede3_cfb64_encrypt, DES_ede3_ofb64_encrypt,
+DES_cbc_cksum, DES_quad_cksum, DES_string_to_key, DES_string_to_2keys,
+DES_fcrypt, DES_crypt, DES_enc_read, DES_enc_write - DES encryption
+
+=head1 SYNOPSIS
+
+ #include <openssl/des.h>
+
+ void DES_random_key(DES_cblock *ret);
+
+ int DES_set_key(const_DES_cblock *key, DES_key_schedule *schedule);
+ int DES_key_sched(const_DES_cblock *key, DES_key_schedule *schedule);
+ int DES_set_key_checked(const_DES_cblock *key,
+        DES_key_schedule *schedule);
+ void DES_set_key_unchecked(const_DES_cblock *key,
+        DES_key_schedule *schedule);
+
+ void DES_set_odd_parity(DES_cblock *key);
+ int DES_is_weak_key(const_DES_cblock *key);
+
+ void DES_ecb_encrypt(const_DES_cblock *input, DES_cblock *output, 
+        DES_key_schedule *ks, int enc);
+ void DES_ecb2_encrypt(const_DES_cblock *input, DES_cblock *output, 
+        DES_key_schedule *ks1, DES_key_schedule *ks2, int enc);
+ void DES_ecb3_encrypt(const_DES_cblock *input, DES_cblock *output, 
+        DES_key_schedule *ks1, DES_key_schedule *ks2, 
+        DES_key_schedule *ks3, int enc);
+
+ void DES_ncbc_encrypt(const unsigned char *input, unsigned char *output, 
+        long length, DES_key_schedule *schedule, DES_cblock *ivec, 
+        int enc);
+ void DES_cfb_encrypt(const unsigned char *in, unsigned char *out,
+        int numbits, long length, DES_key_schedule *schedule,
+        DES_cblock *ivec, int enc);
+ void DES_ofb_encrypt(const unsigned char *in, unsigned char *out,
+        int numbits, long length, DES_key_schedule *schedule,
+        DES_cblock *ivec);
+ void DES_pcbc_encrypt(const unsigned char *input, unsigned char *output, 
+        long length, DES_key_schedule *schedule, DES_cblock *ivec, 
+        int enc);
+ void DES_cfb64_encrypt(const unsigned char *in, unsigned char *out,
+        long length, DES_key_schedule *schedule, DES_cblock *ivec,
+        int *num, int enc);
+ void DES_ofb64_encrypt(const unsigned char *in, unsigned char *out,
+        long length, DES_key_schedule *schedule, DES_cblock *ivec,
+        int *num);
+
+ void DES_xcbc_encrypt(const unsigned char *input, unsigned char *output, 
+        long length, DES_key_schedule *schedule, DES_cblock *ivec, 
+        const_DES_cblock *inw, const_DES_cblock *outw, int enc);
+
+ void DES_ede2_cbc_encrypt(const unsigned char *input,
+        unsigned char *output, long length, DES_key_schedule *ks1,
+        DES_key_schedule *ks2, DES_cblock *ivec, int enc);
+ void DES_ede2_cfb64_encrypt(const unsigned char *in,
+        unsigned char *out, long length, DES_key_schedule *ks1,
+        DES_key_schedule *ks2, DES_cblock *ivec, int *num, int enc);
+ void DES_ede2_ofb64_encrypt(const unsigned char *in,
+        unsigned char *out, long length, DES_key_schedule *ks1,
+        DES_key_schedule *ks2, DES_cblock *ivec, int *num);
+
+ void DES_ede3_cbc_encrypt(const unsigned char *input,
+        unsigned char *output, long length, DES_key_schedule *ks1,
+        DES_key_schedule *ks2, DES_key_schedule *ks3, DES_cblock *ivec,
+        int enc);
+ void DES_ede3_cbcm_encrypt(const unsigned char *in, unsigned char *out, 
+        long length, DES_key_schedule *ks1, DES_key_schedule *ks2, 
+        DES_key_schedule *ks3, DES_cblock *ivec1, DES_cblock *ivec2, 
+        int enc);
+ void DES_ede3_cfb64_encrypt(const unsigned char *in, unsigned char *out, 
+        long length, DES_key_schedule *ks1, DES_key_schedule *ks2,
+        DES_key_schedule *ks3, DES_cblock *ivec, int *num, int enc);
+ void DES_ede3_ofb64_encrypt(const unsigned char *in, unsigned char *out, 
+        long length, DES_key_schedule *ks1, 
+        DES_key_schedule *ks2, DES_key_schedule *ks3, 
+        DES_cblock *ivec, int *num);
+
+ DES_LONG DES_cbc_cksum(const unsigned char *input, DES_cblock *output, 
+        long length, DES_key_schedule *schedule, 
+        const_DES_cblock *ivec);
+ DES_LONG DES_quad_cksum(const unsigned char *input, DES_cblock output[], 
+        long length, int out_count, DES_cblock *seed);
+ void DES_string_to_key(const char *str, DES_cblock *key);
+ void DES_string_to_2keys(const char *str, DES_cblock *key1,
+        DES_cblock *key2);
+
+ char *DES_fcrypt(const char *buf, const char *salt, char *ret);
+ char *DES_crypt(const char *buf, const char *salt);
+
+ int DES_enc_read(int fd, void *buf, int len, DES_key_schedule *sched,
+        DES_cblock *iv);
+ int DES_enc_write(int fd, const void *buf, int len,
+        DES_key_schedule *sched, DES_cblock *iv);
+
+=head1 DESCRIPTION
+
+This library contains a fast implementation of the DES encryption
+algorithm.
+
+There are two phases to the use of DES encryption.  The first is the
+generation of a I<DES_key_schedule> from a key, the second is the
+actual encryption.  A DES key is of type I<DES_cblock>. This type is
+consists of 8 bytes with odd parity.  The least significant bit in
+each byte is the parity bit.  The key schedule is an expanded form of
+the key; it is used to speed the encryption process.
+
+DES_random_key() generates a random key.  The PRNG must be seeded
+prior to using this function (see L<rand(3)|rand(3)>).  If the PRNG
+could not generate a secure key, 0 is returned.
+
+Before a DES key can be used, it must be converted into the
+architecture dependent I<DES_key_schedule> via the
+DES_set_key_checked() or DES_set_key_unchecked() function.
+
+DES_set_key_checked() will check that the key passed is of odd parity
+and is not a week or semi-weak key.  If the parity is wrong, then -1
+is returned.  If the key is a weak key, then -2 is returned.  If an
+error is returned, the key schedule is not generated.
+
+DES_set_key() works like
+DES_set_key_checked() if the I<DES_check_key> flag is non-zero,
+otherwise like DES_set_key_unchecked().  These functions are available
+for compatibility; it is recommended to use a function that does not
+depend on a global variable.
+
+DES_set_odd_parity() sets the parity of the passed I<key> to odd.
+
+DES_is_weak_key() returns 1 is the passed key is a weak key, 0 if it
+is ok.  The probability that a randomly generated key is weak is
+1/2^52, so it is not really worth checking for them.
+
+The following routines mostly operate on an input and output stream of
+I<DES_cblock>s.
+
+DES_ecb_encrypt() is the basic DES encryption routine that encrypts or
+decrypts a single 8-byte I<DES_cblock> in I<electronic code book>
+(ECB) mode.  It always transforms the input data, pointed to by
+I<input>, into the output data, pointed to by the I<output> argument.
+If the I<encrypt> argument is non-zero (DES_ENCRYPT), the I<input>
+(cleartext) is encrypted in to the I<output> (ciphertext) using the
+key_schedule specified by the I<schedule> argument, previously set via
+I<DES_set_key>. If I<encrypt> is zero (DES_DECRYPT), the I<input> (now
+ciphertext) is decrypted into the I<output> (now cleartext).  Input
+and output may overlap.  DES_ecb_encrypt() does not return a value.
+
+DES_ecb3_encrypt() encrypts/decrypts the I<input> block by using
+three-key Triple-DES encryption in ECB mode.  This involves encrypting
+the input with I<ks1>, decrypting with the key schedule I<ks2>, and
+then encrypting with I<ks3>.  This routine greatly reduces the chances
+of brute force breaking of DES and has the advantage of if I<ks1>,
+I<ks2> and I<ks3> are the same, it is equivalent to just encryption
+using ECB mode and I<ks1> as the key.
+
+The macro DES_ecb2_encrypt() is provided to perform two-key Triple-DES
+encryption by using I<ks1> for the final encryption.
+
+DES_ncbc_encrypt() encrypts/decrypts using the I<cipher-block-chaining>
+(CBC) mode of DES.  If the I<encrypt> argument is non-zero, the
+routine cipher-block-chain encrypts the cleartext data pointed to by
+the I<input> argument into the ciphertext pointed to by the I<output>
+argument, using the key schedule provided by the I<schedule> argument,
+and initialization vector provided by the I<ivec> argument.  If the
+I<length> argument is not an integral multiple of eight bytes, the
+last block is copied to a temporary area and zero filled.  The output
+is always an integral multiple of eight bytes.
+
+DES_xcbc_encrypt() is RSA's DESX mode of DES.  It uses I<inw> and
+I<outw> to 'whiten' the encryption.  I<inw> and I<outw> are secret
+(unlike the iv) and are as such, part of the key.  So the key is sort
+of 24 bytes.  This is much better than CBC DES.
+
+DES_ede3_cbc_encrypt() implements outer triple CBC DES encryption with
+three keys. This means that each DES operation inside the CBC mode is
+really an C<C=E(ks3,D(ks2,E(ks1,M)))>.  This mode is used by SSL.
+
+The DES_ede2_cbc_encrypt() macro implements two-key Triple-DES by
+reusing I<ks1> for the final encryption.  C<C=E(ks1,D(ks2,E(ks1,M)))>.
+This form of Triple-DES is used by the RSAREF library.
+
+DES_pcbc_encrypt() encrypt/decrypts using the propagating cipher block
+chaining mode used by Kerberos v4. Its parameters are the same as
+DES_ncbc_encrypt().
+
+DES_cfb_encrypt() encrypt/decrypts using cipher feedback mode.  This
+method takes an array of characters as input and outputs and array of
+characters.  It does not require any padding to 8 character groups.
+Note: the I<ivec> variable is changed and the new changed value needs to
+be passed to the next call to this function.  Since this function runs
+a complete DES ECB encryption per I<numbits>, this function is only
+suggested for use when sending small numbers of characters.
+
+DES_cfb64_encrypt()
+implements CFB mode of DES with 64bit feedback.  Why is this
+useful you ask?  Because this routine will allow you to encrypt an
+arbitrary number of bytes, no 8 byte padding.  Each call to this
+routine will encrypt the input bytes to output and then update ivec
+and num.  num contains 'how far' we are though ivec.  If this does
+not make much sense, read more about cfb mode of DES :-).
+
+DES_ede3_cfb64_encrypt() and DES_ede2_cfb64_encrypt() is the same as
+DES_cfb64_encrypt() except that Triple-DES is used.
+
+DES_ofb_encrypt() encrypts using output feedback mode.  This method
+takes an array of characters as input and outputs and array of
+characters.  It does not require any padding to 8 character groups.
+Note: the I<ivec> variable is changed and the new changed value needs to
+be passed to the next call to this function.  Since this function runs
+a complete DES ECB encryption per numbits, this function is only
+suggested for use when sending small numbers of characters.
+
+DES_ofb64_encrypt() is the same as DES_cfb64_encrypt() using Output
+Feed Back mode.
+
+DES_ede3_ofb64_encrypt() and DES_ede2_ofb64_encrypt() is the same as
+DES_ofb64_encrypt(), using Triple-DES.
+
+The following functions are included in the DES library for
+compatibility with the MIT Kerberos library.
+
+DES_cbc_cksum() produces an 8 byte checksum based on the input stream
+(via CBC encryption).  The last 4 bytes of the checksum are returned
+and the complete 8 bytes are placed in I<output>. This function is
+used by Kerberos v4.  Other applications should use
+L<EVP_DigestInit(3)|EVP_DigestInit(3)> etc. instead.
+
+DES_quad_cksum() is a Kerberos v4 function.  It returns a 4 byte
+checksum from the input bytes.  The algorithm can be iterated over the
+input, depending on I<out_count>, 1, 2, 3 or 4 times.  If I<output> is
+non-NULL, the 8 bytes generated by each pass are written into
+I<output>.
+
+The following are DES-based transformations:
+
+DES_fcrypt() is a fast version of the Unix crypt(3) function.  This
+version takes only a small amount of space relative to other fast
+crypt() implementations.  This is different to the normal crypt in
+that the third parameter is the buffer that the return value is
+written into.  It needs to be at least 14 bytes long.  This function
+is thread safe, unlike the normal crypt.
+
+DES_crypt() is a faster replacement for the normal system crypt().
+This function calls DES_fcrypt() with a static array passed as the
+third parameter.  This emulates the normal non-thread safe semantics
+of crypt(3).
+
+DES_enc_write() writes I<len> bytes to file descriptor I<fd> from
+buffer I<buf>. The data is encrypted via I<pcbc_encrypt> (default)
+using I<sched> for the key and I<iv> as a starting vector.  The actual
+data send down I<fd> consists of 4 bytes (in network byte order)
+containing the length of the following encrypted data.  The encrypted
+data then follows, padded with random data out to a multiple of 8
+bytes.
+
+DES_enc_read() is used to read I<len> bytes from file descriptor
+I<fd> into buffer I<buf>. The data being read from I<fd> is assumed to
+have come from DES_enc_write() and is decrypted using I<sched> for
+the key schedule and I<iv> for the initial vector.
+
+B<Warning:> The data format used by DES_enc_write() and DES_enc_read()
+has a cryptographic weakness: When asked to write more than MAXWRITE
+bytes, DES_enc_write() will split the data into several chunks that
+are all encrypted using the same IV.  So don't use these functions
+unless you are sure you know what you do (in which case you might not
+want to use them anyway).  They cannot handle non-blocking sockets.
+DES_enc_read() uses an internal state and thus cannot be used on
+multiple files.
+
+I<DES_rw_mode> is used to specify the encryption mode to use with
+DES_enc_read() and DES_end_write().  If set to I<DES_PCBC_MODE> (the
+default), DES_pcbc_encrypt is used.  If set to I<DES_CBC_MODE>
+DES_cbc_encrypt is used.
+
+=head1 NOTES
+
+Single-key DES is insecure due to its short key size.  ECB mode is
+not suitable for most applications; see L<des_modes(7)|des_modes(7)>.
+
+The L<evp(3)|evp(3)> library provides higher-level encryption functions.
+
+=head1 BUGS
+
+DES_3cbc_encrypt() is flawed and must not be used in applications.
+
+DES_cbc_encrypt() does not modify B<ivec>; use DES_ncbc_encrypt()
+instead.
+
+DES_cfb_encrypt() and DES_ofb_encrypt() operates on input of 8 bits.
+What this means is that if you set numbits to 12, and length to 2, the
+first 12 bits will come from the 1st input byte and the low half of
+the second input byte.  The second 12 bits will have the low 8 bits
+taken from the 3rd input byte and the top 4 bits taken from the 4th
+input byte.  The same holds for output.  This function has been
+implemented this way because most people will be using a multiple of 8
+and because once you get into pulling bytes input bytes apart things
+get ugly!
+
+DES_string_to_key() is available for backward compatibility with the
+MIT library.  New applications should use a cryptographic hash function.
+The same applies for DES_string_to_2key().
+
+=head1 CONFORMING TO
+
+ANSI X3.106
+
+The B<des> library was written to be source code compatible with
+the MIT Kerberos library.
+
+=head1 SEE ALSO
+
+crypt(3), L<des_modes(7)|des_modes(7)>, L<evp(3)|evp(3)>, L<rand(3)|rand(3)>
+
+=head1 HISTORY
+
+In OpenSSL 0.9.7, all des_ functions were renamed to DES_ to avoid
+clashes with older versions of libdes.  Compatibility des_ functions
+are provided for a short while, as well as crypt().
+Declarations for these are in <openssl/des_old.h>. There is no DES_
+variant for des_random_seed().
+This will happen to other functions
+as well if they are deemed redundant (des_random_seed() just calls
+RAND_seed() and is present for backward compatibility only), buggy or
+already scheduled for removal.
+
+des_cbc_cksum(), des_cbc_encrypt(), des_ecb_encrypt(),
+des_is_weak_key(), des_key_sched(), des_pcbc_encrypt(),
+des_quad_cksum(), des_random_key() and des_string_to_key()
+are available in the MIT Kerberos library;
+des_check_key_parity(), des_fixup_key_parity() and des_is_weak_key()
+are available in newer versions of that library.
+
+des_set_key_checked() and des_set_key_unchecked() were added in
+OpenSSL 0.9.5.
+
+des_generate_random_block(), des_init_random_number_generator(),
+des_new_random_key(), des_set_random_generator_seed() and
+des_set_sequence_number() and des_rand_data() are used in newer
+versions of Kerberos but are not implemented here.
+
+des_random_key() generated cryptographically weak random data in
+SSLeay and in OpenSSL prior version 0.9.5, as well as in the original
+MIT library.
+
+=head1 AUTHOR
+
+Eric Young (eay@cryptsoft.com). Modified for the OpenSSL project
+(http://www.openssl.org).
+
+=cut
diff --git a/lib/libcrypto/doc/ERR.pod b/lib/libcrypto/doc/ERR.pod
new file mode 100644
index 00000000000..6f729554d2a
--- /dev/null
+++ b/lib/libcrypto/doc/ERR.pod
@@ -0,0 +1,187 @@
+=pod
+
+=head1 NAME
+
+err - error codes
+
+=head1 SYNOPSIS
+
+ #include <openssl/err.h>
+
+ unsigned long ERR_get_error(void);
+ unsigned long ERR_peek_error(void);
+ unsigned long ERR_get_error_line(const char **file, int *line);
+ unsigned long ERR_peek_error_line(const char **file, int *line);
+ unsigned long ERR_get_error_line_data(const char **file, int *line,
+         const char **data, int *flags);
+ unsigned long ERR_peek_error_line_data(const char **file, int *line,
+         const char **data, int *flags);
+
+ int ERR_GET_LIB(unsigned long e);
+ int ERR_GET_FUNC(unsigned long e);
+ int ERR_GET_REASON(unsigned long e);
+
+ void ERR_clear_error(void);
+
+ char *ERR_error_string(unsigned long e, char *buf);
+ const char *ERR_lib_error_string(unsigned long e);
+ const char *ERR_func_error_string(unsigned long e);
+ const char *ERR_reason_error_string(unsigned long e);
+
+ void ERR_print_errors(BIO *bp);
+ void ERR_print_errors_fp(FILE *fp);
+
+ void ERR_load_crypto_strings(void);
+ void ERR_free_strings(void);
+
+ void ERR_remove_state(unsigned long pid);
+
+ void ERR_put_error(int lib, int func, int reason, const char *file,
+         int line);
+ void ERR_add_error_data(int num, ...);
+
+ void ERR_load_strings(int lib,ERR_STRING_DATA str[]);
+ unsigned long ERR_PACK(int lib, int func, int reason);
+ int ERR_get_next_error_library(void);
+
+=head1 DESCRIPTION
+
+When a call to the OpenSSL library fails, this is usually signalled
+by the return value, and an error code is stored in an error queue
+associated with the current thread. The B<err> library provides
+functions to obtain these error codes and textual error messages.
+
+The L<ERR_get_error(3)|ERR_get_error(3)> manpage describes how to
+access error codes.
+
+Error codes contain information about where the error occurred, and
+what went wrong. L<ERR_GET_LIB(3)|ERR_GET_LIB(3)> describes how to
+extract this information. A method to obtain human-readable error
+messages is described in L<ERR_error_string(3)|ERR_error_string(3)>.
+
+L<ERR_clear_error(3)|ERR_clear_error(3)> can be used to clear the
+error queue.
+
+Note that L<ERR_remove_state(3)|ERR_remove_state(3)> should be used to
+avoid memory leaks when threads are terminated.
+
+=head1 ADDING NEW ERROR CODES TO OPENSSL
+
+See L<ERR_put_error(3)> if you want to record error codes in the
+OpenSSL error system from within your application.
+
+The remainder of this section is of interest only if you want to add
+new error codes to OpenSSL or add error codes from external libraries.
+
+=head2 Reporting errors
+
+Each sub-library has a specific macro XXXerr() that is used to report
+errors. Its first argument is a function code B<XXX_F_...>, the second
+argument is a reason code B<XXX_R_...>. Function codes are derived
+from the function names; reason codes consist of textual error
+descriptions. For example, the function ssl23_read() reports a
+"handshake failure" as follows:
+
+ SSLerr(SSL_F_SSL23_READ, SSL_R_SSL_HANDSHAKE_FAILURE);
+
+Function and reason codes should consist of upper case characters,
+numbers and underscores only. The error file generation script translates
+function codes into function names by looking in the header files
+for an appropriate function name, if none is found it just uses
+the capitalized form such as "SSL23_READ" in the above example.
+
+The trailing section of a reason code (after the "_R_") is translated
+into lower case and underscores changed to spaces.
+
+When you are using new function or reason codes, run B<make errors>.
+The necessary B<#define>s will then automatically be added to the
+sub-library's header file.
+
+Although a library will normally report errors using its own specific
+XXXerr macro, another library's macro can be used. This is normally
+only done when a library wants to include ASN1 code which must use
+the ASN1err() macro.
+
+=head2 Adding new libraries
+
+When adding a new sub-library to OpenSSL, assign it a library number
+B<ERR_LIB_XXX>, define a macro XXXerr() (both in B<err.h>), add its
+name to B<ERR_str_libraries[]> (in B<crypto/err/err.c>), and add
+C<ERR_load_XXX_strings()> to the ERR_load_crypto_strings() function
+(in B<crypto/err/err_all.c>). Finally, add an entry
+
+ L	XXX	xxx.h	xxx_err.c
+
+to B<crypto/err/openssl.ec>, and add B<xxx_err.c> to the Makefile.
+Running B<make errors> will then generate a file B<xxx_err.c>, and
+add all error codes used in the library to B<xxx.h>.
+
+Additionally the library include file must have a certain form.
+Typically it will initially look like this:
+
+ #ifndef HEADER_XXX_H
+ #define HEADER_XXX_H
+
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+
+ /* Include files */
+
+ #include <openssl/bio.h>
+ #include <openssl/x509.h>
+
+ /* Macros, structures and function prototypes */
+
+
+ /* BEGIN ERROR CODES */
+
+The B<BEGIN ERROR CODES> sequence is used by the error code
+generation script as the point to place new error codes, any text
+after this point will be overwritten when B<make errors> is run.
+The closing #endif etc will be automatically added by the script.
+
+The generated C error code file B<xxx_err.c> will load the header
+files B<stdio.h>, B<openssl/err.h> and B<openssl/xxx.h> so the
+header file must load any additional header files containing any
+definitions it uses.
+
+=head1 USING ERROR CODES IN EXTERNAL LIBRARIES
+
+It is also possible to use OpenSSL's error code scheme in external
+libraries. The library needs to load its own codes and call the OpenSSL
+error code insertion script B<mkerr.pl> explicitly to add codes to
+the header file and generate the C error code file. This will normally
+be done if the external library needs to generate new ASN1 structures
+but it can also be used to add more general purpose error code handling.
+
+TBA more details
+
+=head1 INTERNALS
+
+The error queues are stored in a hash table with one B<ERR_STATE>
+entry for each pid. ERR_get_state() returns the current thread's
+B<ERR_STATE>. An B<ERR_STATE> can hold up to B<ERR_NUM_ERRORS> error
+codes. When more error codes are added, the old ones are overwritten,
+on the assumption that the most recent errors are most important.
+
+Error strings are also stored in hash table. The hash tables can
+be obtained by calling ERR_get_err_state_table(void) and
+ERR_get_string_table(void) respectively.
+
+=head1 SEE ALSO
+
+L<CRYPTO_set_id_callback(3)|CRYPTO_set_id_callback(3)>,
+L<CRYPTO_set_locking_callback(3)|CRYPTO_set_locking_callback(3)>,
+L<ERR_get_error(3)|ERR_get_error(3)>,
+L<ERR_GET_LIB(3)|ERR_GET_LIB(3)>,
+L<ERR_clear_error(3)|ERR_clear_error(3)>,
+L<ERR_error_string(3)|ERR_error_string(3)>,
+L<ERR_print_errors(3)|ERR_print_errors(3)>,
+L<ERR_load_crypto_strings(3)|ERR_load_crypto_strings(3)>,
+L<ERR_remove_state(3)|ERR_remove_state(3)>,
+L<ERR_put_error(3)|ERR_put_error(3)>,
+L<ERR_load_strings(3)|ERR_load_strings(3)>,
+L<SSL_get_error(3)|SSL_get_error(3)>
+
+=cut
diff --git a/lib/libcrypto/doc/HMAC.pod b/lib/libcrypto/doc/HMAC.pod
new file mode 100644
index 00000000000..d92138d2731
--- /dev/null
+++ b/lib/libcrypto/doc/HMAC.pod
@@ -0,0 +1,106 @@
+=pod
+
+=head1 NAME
+
+HMAC, HMAC_Init, HMAC_Update, HMAC_Final, HMAC_cleanup - HMAC message
+authentication code
+
+=head1 SYNOPSIS
+
+ #include <openssl/hmac.h>
+
+ unsigned char *HMAC(const EVP_MD *evp_md, const void *key,
+               int key_len, const unsigned char *d, int n,
+               unsigned char *md, unsigned int *md_len);
+
+ void HMAC_CTX_init(HMAC_CTX *ctx);
+
+ int HMAC_Init(HMAC_CTX *ctx, const void *key, int key_len,
+               const EVP_MD *md);
+ int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int key_len,
+               	   const EVP_MD *md, ENGINE *impl);
+ int HMAC_Update(HMAC_CTX *ctx, const unsigned char *data, int len);
+ int HMAC_Final(HMAC_CTX *ctx, unsigned char *md, unsigned int *len);
+
+ void HMAC_CTX_cleanup(HMAC_CTX *ctx);
+ void HMAC_cleanup(HMAC_CTX *ctx);
+
+=head1 DESCRIPTION
+
+HMAC is a MAC (message authentication code), i.e. a keyed hash
+function used for message authentication, which is based on a hash
+function.
+
+HMAC() computes the message authentication code of the B<n> bytes at
+B<d> using the hash function B<evp_md> and the key B<key> which is
+B<key_len> bytes long.
+
+It places the result in B<md> (which must have space for the output of
+the hash function, which is no more than B<EVP_MAX_MD_SIZE> bytes).
+If B<md> is NULL, the digest is placed in a static array.  The size of
+the output is placed in B<md_len>, unless it is B<NULL>.
+
+B<evp_md> can be EVP_sha1(), EVP_ripemd160() etc.
+
+HMAC_CTX_init() initialises a B<HMAC_CTX> before first use. It must be
+called.
+
+HMAC_CTX_cleanup() erases the key and other data from the B<HMAC_CTX>
+and releases any associated resources. It must be called when an
+B<HMAC_CTX> is no longer required.
+
+HMAC_cleanup() is an alias for HMAC_CTX_cleanup() included for back
+compatibility with 0.9.6b, it is deprecated.
+
+The following functions may be used if the message is not completely
+stored in memory:
+
+HMAC_Init() initializes a B<HMAC_CTX> structure to use the hash
+function B<evp_md> and the key B<key> which is B<key_len> bytes
+long. It is deprecated and only included for backward compatibility
+with OpenSSL 0.9.6b.
+
+HMAC_Init_ex() initializes or reuses a B<HMAC_CTX> structure to use
+the function B<evp_md> and key B<key>. Either can be NULL, in which
+case the existing one will be reused. HMAC_CTX_init() must have been
+called before the first use of an B<HMAC_CTX> in this
+function. B<N.B. HMAC_Init() had this undocumented behaviour in
+previous versions of OpenSSL - failure to switch to HMAC_Init_ex() in
+programs that expect it will cause them to stop working>.
+
+HMAC_Update() can be called repeatedly with chunks of the message to
+be authenticated (B<len> bytes at B<data>).
+
+HMAC_Final() places the message authentication code in B<md>, which
+must have space for the hash function output.
+
+=head1 RETURN VALUES
+
+HMAC() returns a pointer to the message authentication code or NULL if
+an error occurred.
+
+HMAC_Init_ex(), HMAC_Update() and HMAC_Final() return 1 for success or 0 if
+an error occurred.
+
+HMAC_CTX_init() and HMAC_CTX_cleanup() do not return values.
+
+=head1 CONFORMING TO
+
+RFC 2104
+
+=head1 SEE ALSO
+
+L<sha(3)|sha(3)>, L<evp(3)|evp(3)>
+
+=head1 HISTORY
+
+HMAC(), HMAC_Init(), HMAC_Update(), HMAC_Final() and HMAC_cleanup()
+are available since SSLeay 0.9.0.
+
+HMAC_CTX_init(), HMAC_Init_ex() and HMAC_CTX_cleanup() are available
+since OpenSSL 0.9.7.
+
+HMAC_Init_ex(), HMAC_Update() and HMAC_Final() did not return values in
+versions of OpenSSL before 1.0.0.
+
+=cut
diff --git a/lib/libcrypto/doc/MD5.pod b/lib/libcrypto/doc/MD5.pod
new file mode 100644
index 00000000000..d11d5c32cbf
--- /dev/null
+++ b/lib/libcrypto/doc/MD5.pod
@@ -0,0 +1,101 @@
+=pod
+
+=head1 NAME
+
+MD2, MD4, MD5, MD2_Init, MD2_Update, MD2_Final, MD4_Init, MD4_Update,
+MD4_Final, MD5_Init, MD5_Update, MD5_Final - MD2, MD4, and MD5 hash functions
+
+=head1 SYNOPSIS
+
+ #include <openssl/md2.h>
+
+ unsigned char *MD2(const unsigned char *d, unsigned long n,
+                  unsigned char *md);
+
+ int MD2_Init(MD2_CTX *c);
+ int MD2_Update(MD2_CTX *c, const unsigned char *data,
+                  unsigned long len);
+ int MD2_Final(unsigned char *md, MD2_CTX *c);
+
+
+ #include <openssl/md4.h>
+
+ unsigned char *MD4(const unsigned char *d, unsigned long n,
+                  unsigned char *md);
+
+ int MD4_Init(MD4_CTX *c);
+ int MD4_Update(MD4_CTX *c, const void *data,
+                  unsigned long len);
+ int MD4_Final(unsigned char *md, MD4_CTX *c);
+
+
+ #include <openssl/md5.h>
+
+ unsigned char *MD5(const unsigned char *d, unsigned long n,
+                  unsigned char *md);
+
+ int MD5_Init(MD5_CTX *c);
+ int MD5_Update(MD5_CTX *c, const void *data,
+                  unsigned long len);
+ int MD5_Final(unsigned char *md, MD5_CTX *c);
+
+=head1 DESCRIPTION
+
+MD2, MD4, and MD5 are cryptographic hash functions with a 128 bit output.
+
+MD2(), MD4(), and MD5() compute the MD2, MD4, and MD5 message digest
+of the B<n> bytes at B<d> and place it in B<md> (which must have space
+for MD2_DIGEST_LENGTH == MD4_DIGEST_LENGTH == MD5_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:
+
+MD2_Init() initializes a B<MD2_CTX> structure.
+
+MD2_Update() can be called repeatedly with chunks of the message to
+be hashed (B<len> bytes at B<data>).
+
+MD2_Final() places the message digest in B<md>, which must have space
+for MD2_DIGEST_LENGTH == 16 bytes of output, and erases the B<MD2_CTX>.
+
+MD4_Init(), MD4_Update(), MD4_Final(), MD5_Init(), MD5_Update(), and
+MD5_Final() are analogous using an B<MD4_CTX> and B<MD5_CTX> structure.
+
+Applications should use the higher level functions
+L<EVP_DigestInit(3)|EVP_DigestInit(3)>
+etc. instead of calling the hash functions directly.
+
+=head1 NOTE
+
+MD2, MD4, and MD5 are recommended only for compatibility with existing
+applications. In new applications, SHA-1 or RIPEMD-160 should be
+preferred.
+
+=head1 RETURN VALUES
+
+MD2(), MD4(), and MD5() return pointers to the hash value. 
+
+MD2_Init(), MD2_Update(), MD2_Final(), MD4_Init(), MD4_Update(),
+MD4_Final(), MD5_Init(), MD5_Update(), and MD5_Final() return 1 for
+success, 0 otherwise.
+
+=head1 CONFORMING TO
+
+RFC 1319, RFC 1320, RFC 1321
+
+=head1 SEE ALSO
+
+L<sha(3)|sha(3)>, L<ripemd(3)|ripemd(3)>, L<EVP_DigestInit(3)|EVP_DigestInit(3)>
+
+=head1 HISTORY
+
+MD2(), MD2_Init(), MD2_Update() MD2_Final(), MD5(), MD5_Init(),
+MD5_Update() and MD5_Final() are available in all versions of SSLeay
+and OpenSSL.
+
+MD4(), MD4_Init(), and MD4_Update() are available in OpenSSL 0.9.6 and
+above.
+
+=cut
diff --git a/lib/libcrypto/doc/PEM_read_bio_PrivateKey.pod b/lib/libcrypto/doc/PEM_read_bio_PrivateKey.pod
new file mode 100644
index 00000000000..54414a3f6f3
--- /dev/null
+++ b/lib/libcrypto/doc/PEM_read_bio_PrivateKey.pod
@@ -0,0 +1,476 @@
+=pod
+
+=head1 NAME
+
+PEM, PEM_read_bio_PrivateKey, PEM_read_PrivateKey, PEM_write_bio_PrivateKey, PEM_write_PrivateKey, PEM_write_bio_PKCS8PrivateKey, PEM_write_PKCS8PrivateKey, PEM_write_bio_PKCS8PrivateKey_nid, PEM_write_PKCS8PrivateKey_nid, PEM_read_bio_PUBKEY, PEM_read_PUBKEY, PEM_write_bio_PUBKEY, PEM_write_PUBKEY, PEM_read_bio_RSAPrivateKey, PEM_read_RSAPrivateKey, PEM_write_bio_RSAPrivateKey, PEM_write_RSAPrivateKey, PEM_read_bio_RSAPublicKey, PEM_read_RSAPublicKey, PEM_write_bio_RSAPublicKey, PEM_write_RSAPublicKey, PEM_read_bio_RSA_PUBKEY, PEM_read_RSA_PUBKEY, PEM_write_bio_RSA_PUBKEY, PEM_write_RSA_PUBKEY, PEM_read_bio_DSAPrivateKey, PEM_read_DSAPrivateKey, PEM_write_bio_DSAPrivateKey, PEM_write_DSAPrivateKey, PEM_read_bio_DSA_PUBKEY, PEM_read_DSA_PUBKEY, PEM_write_bio_DSA_PUBKEY, PEM_write_DSA_PUBKEY, PEM_read_bio_DSAparams, PEM_read_DSAparams, PEM_write_bio_DSAparams, PEM_write_DSAparams, PEM_read_bio_DHparams, PEM_read_DHparams, PEM_write_bio_DHparams, PEM_write_DHparams, PEM_read_bio_X509, PEM_read_X509, PEM_write_bio_X509, PEM_write_X509, PEM_read_bio_X509_AUX, PEM_read_X509_AUX, PEM_write_bio_X509_AUX, PEM_write_X509_AUX, PEM_read_bio_X509_REQ, PEM_read_X509_REQ, PEM_write_bio_X509_REQ, PEM_write_X509_REQ, PEM_write_bio_X509_REQ_NEW, PEM_write_X509_REQ_NEW, PEM_read_bio_X509_CRL, PEM_read_X509_CRL, PEM_write_bio_X509_CRL, PEM_write_X509_CRL, PEM_read_bio_PKCS7, PEM_read_PKCS7, PEM_write_bio_PKCS7, PEM_write_PKCS7, PEM_read_bio_NETSCAPE_CERT_SEQUENCE, PEM_read_NETSCAPE_CERT_SEQUENCE, PEM_write_bio_NETSCAPE_CERT_SEQUENCE, PEM_write_NETSCAPE_CERT_SEQUENCE - PEM routines
+
+=head1 SYNOPSIS
+
+ #include <openssl/pem.h>
+
+ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp, EVP_PKEY **x,
+					pem_password_cb *cb, void *u);
+
+ EVP_PKEY *PEM_read_PrivateKey(FILE *fp, EVP_PKEY **x,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PrivateKey(BIO *bp, EVP_PKEY *x, const EVP_CIPHER *enc,
+					unsigned char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_PrivateKey(FILE *fp, EVP_PKEY *x, const EVP_CIPHER *enc,
+					unsigned char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PKCS8PrivateKey(BIO *bp, EVP_PKEY *x, const EVP_CIPHER *enc,
+					char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_PKCS8PrivateKey(FILE *fp, EVP_PKEY *x, const EVP_CIPHER *enc,
+					char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PKCS8PrivateKey_nid(BIO *bp, EVP_PKEY *x, int nid,
+					char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_PKCS8PrivateKey_nid(FILE *fp, EVP_PKEY *x, int nid,
+					char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ EVP_PKEY *PEM_read_bio_PUBKEY(BIO *bp, EVP_PKEY **x,
+					pem_password_cb *cb, void *u);
+
+ EVP_PKEY *PEM_read_PUBKEY(FILE *fp, EVP_PKEY **x,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PUBKEY(BIO *bp, EVP_PKEY *x);
+ int PEM_write_PUBKEY(FILE *fp, EVP_PKEY *x);
+
+ RSA *PEM_read_bio_RSAPrivateKey(BIO *bp, RSA **x,
+					pem_password_cb *cb, void *u);
+
+ RSA *PEM_read_RSAPrivateKey(FILE *fp, RSA **x,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_RSAPrivateKey(BIO *bp, RSA *x, const EVP_CIPHER *enc,
+					unsigned char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_RSAPrivateKey(FILE *fp, RSA *x, const EVP_CIPHER *enc,
+					unsigned char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ RSA *PEM_read_bio_RSAPublicKey(BIO *bp, RSA **x,
+					pem_password_cb *cb, void *u);
+
+ RSA *PEM_read_RSAPublicKey(FILE *fp, RSA **x,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_RSAPublicKey(BIO *bp, RSA *x);
+
+ int PEM_write_RSAPublicKey(FILE *fp, RSA *x);
+
+ RSA *PEM_read_bio_RSA_PUBKEY(BIO *bp, RSA **x,
+					pem_password_cb *cb, void *u);
+
+ RSA *PEM_read_RSA_PUBKEY(FILE *fp, RSA **x,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_RSA_PUBKEY(BIO *bp, RSA *x);
+
+ int PEM_write_RSA_PUBKEY(FILE *fp, RSA *x);
+
+ DSA *PEM_read_bio_DSAPrivateKey(BIO *bp, DSA **x,
+					pem_password_cb *cb, void *u);
+
+ DSA *PEM_read_DSAPrivateKey(FILE *fp, DSA **x,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_DSAPrivateKey(BIO *bp, DSA *x, const EVP_CIPHER *enc,
+					unsigned char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_DSAPrivateKey(FILE *fp, DSA *x, const EVP_CIPHER *enc,
+					unsigned char *kstr, int klen,
+					pem_password_cb *cb, void *u);
+
+ DSA *PEM_read_bio_DSA_PUBKEY(BIO *bp, DSA **x,
+					pem_password_cb *cb, void *u);
+
+ DSA *PEM_read_DSA_PUBKEY(FILE *fp, DSA **x,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_DSA_PUBKEY(BIO *bp, DSA *x);
+
+ int PEM_write_DSA_PUBKEY(FILE *fp, DSA *x);
+
+ DSA *PEM_read_bio_DSAparams(BIO *bp, DSA **x, pem_password_cb *cb, void *u);
+
+ DSA *PEM_read_DSAparams(FILE *fp, DSA **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_DSAparams(BIO *bp, DSA *x);
+
+ int PEM_write_DSAparams(FILE *fp, DSA *x);
+
+ DH *PEM_read_bio_DHparams(BIO *bp, DH **x, pem_password_cb *cb, void *u);
+
+ DH *PEM_read_DHparams(FILE *fp, DH **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_DHparams(BIO *bp, DH *x);
+
+ int PEM_write_DHparams(FILE *fp, DH *x);
+
+ X509 *PEM_read_bio_X509(BIO *bp, X509 **x, pem_password_cb *cb, void *u);
+
+ X509 *PEM_read_X509(FILE *fp, X509 **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_X509(BIO *bp, X509 *x);
+
+ int PEM_write_X509(FILE *fp, X509 *x);
+
+ X509 *PEM_read_bio_X509_AUX(BIO *bp, X509 **x, pem_password_cb *cb, void *u);
+
+ X509 *PEM_read_X509_AUX(FILE *fp, X509 **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_X509_AUX(BIO *bp, X509 *x);
+
+ int PEM_write_X509_AUX(FILE *fp, X509 *x);
+
+ X509_REQ *PEM_read_bio_X509_REQ(BIO *bp, X509_REQ **x,
+					pem_password_cb *cb, void *u);
+
+ X509_REQ *PEM_read_X509_REQ(FILE *fp, X509_REQ **x,
+					pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_X509_REQ(BIO *bp, X509_REQ *x);
+
+ int PEM_write_X509_REQ(FILE *fp, X509_REQ *x);
+
+ int PEM_write_bio_X509_REQ_NEW(BIO *bp, X509_REQ *x);
+
+ int PEM_write_X509_REQ_NEW(FILE *fp, X509_REQ *x);
+
+ X509_CRL *PEM_read_bio_X509_CRL(BIO *bp, X509_CRL **x,
+					pem_password_cb *cb, void *u);
+ X509_CRL *PEM_read_X509_CRL(FILE *fp, X509_CRL **x,
+					pem_password_cb *cb, void *u);
+ int PEM_write_bio_X509_CRL(BIO *bp, X509_CRL *x);
+ int PEM_write_X509_CRL(FILE *fp, X509_CRL *x);
+
+ PKCS7 *PEM_read_bio_PKCS7(BIO *bp, PKCS7 **x, pem_password_cb *cb, void *u);
+
+ PKCS7 *PEM_read_PKCS7(FILE *fp, PKCS7 **x, pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_PKCS7(BIO *bp, PKCS7 *x);
+
+ int PEM_write_PKCS7(FILE *fp, PKCS7 *x);
+
+ NETSCAPE_CERT_SEQUENCE *PEM_read_bio_NETSCAPE_CERT_SEQUENCE(BIO *bp,
+						NETSCAPE_CERT_SEQUENCE **x,
+						pem_password_cb *cb, void *u);
+
+ NETSCAPE_CERT_SEQUENCE *PEM_read_NETSCAPE_CERT_SEQUENCE(FILE *fp,
+						NETSCAPE_CERT_SEQUENCE **x,
+						pem_password_cb *cb, void *u);
+
+ int PEM_write_bio_NETSCAPE_CERT_SEQUENCE(BIO *bp, NETSCAPE_CERT_SEQUENCE *x);
+
+ int PEM_write_NETSCAPE_CERT_SEQUENCE(FILE *fp, NETSCAPE_CERT_SEQUENCE *x);
+
+=head1 DESCRIPTION
+
+The PEM functions read or write structures in PEM format. In
+this sense PEM format is simply base64 encoded data surrounded
+by header lines.
+
+For more details about the meaning of arguments see the
+B<PEM FUNCTION ARGUMENTS> section.
+
+Each operation has four functions associated with it. For
+clarity the term "B<foobar> functions" will be used to collectively
+refer to the PEM_read_bio_foobar(), PEM_read_foobar(),
+PEM_write_bio_foobar() and PEM_write_foobar() functions.
+
+The B<PrivateKey> functions read or write a private key in
+PEM format using an EVP_PKEY structure. The write routines use
+"traditional" private key format and can handle both RSA and DSA
+private keys. The read functions can additionally transparently
+handle PKCS#8 format encrypted and unencrypted keys too.
+
+PEM_write_bio_PKCS8PrivateKey() and PEM_write_PKCS8PrivateKey()
+write a private key in an EVP_PKEY structure in PKCS#8
+EncryptedPrivateKeyInfo format using PKCS#5 v2.0 password based encryption
+algorithms. The B<cipher> argument specifies the encryption algorithm to
+use: unlike all other PEM routines the encryption is applied at the
+PKCS#8 level and not in the PEM headers. If B<cipher> is NULL then no
+encryption is used and a PKCS#8 PrivateKeyInfo structure is used instead.
+
+PEM_write_bio_PKCS8PrivateKey_nid() and PEM_write_PKCS8PrivateKey_nid()
+also write out a private key as a PKCS#8 EncryptedPrivateKeyInfo however
+it uses PKCS#5 v1.5 or PKCS#12 encryption algorithms instead. The algorithm
+to use is specified in the B<nid> parameter and should be the NID of the
+corresponding OBJECT IDENTIFIER (see NOTES section).
+
+The B<PUBKEY> functions process a public key using an EVP_PKEY
+structure. The public key is encoded as a SubjectPublicKeyInfo
+structure.
+
+The B<RSAPrivateKey> functions process an RSA private key using an
+RSA structure. It handles the same formats as the B<PrivateKey>
+functions but an error occurs if the private key is not RSA.
+
+The B<RSAPublicKey> functions process an RSA public key using an
+RSA structure. The public key is encoded using a PKCS#1 RSAPublicKey
+structure.
+
+The B<RSA_PUBKEY> functions also process an RSA public key using
+an RSA structure. However the public key is encoded using a
+SubjectPublicKeyInfo structure and an error occurs if the public
+key is not RSA.
+
+The B<DSAPrivateKey> functions process a DSA private key using a
+DSA structure. It handles the same formats as the B<PrivateKey>
+functions but an error occurs if the private key is not DSA.
+
+The B<DSA_PUBKEY> functions process a DSA public key using
+a DSA structure. The public key is encoded using a
+SubjectPublicKeyInfo structure and an error occurs if the public
+key is not DSA.
+
+The B<DSAparams> functions process DSA parameters using a DSA
+structure. The parameters are encoded using a foobar structure.
+
+The B<DHparams> functions process DH parameters using a DH
+structure. The parameters are encoded using a PKCS#3 DHparameter
+structure.
+
+The B<X509> functions process an X509 certificate using an X509
+structure. They will also process a trusted X509 certificate but
+any trust settings are discarded.
+
+The B<X509_AUX> functions process a trusted X509 certificate using
+an X509 structure. 
+
+The B<X509_REQ> and B<X509_REQ_NEW> functions process a PKCS#10
+certificate request using an X509_REQ structure. The B<X509_REQ>
+write functions use B<CERTIFICATE REQUEST> in the header whereas
+the B<X509_REQ_NEW> functions use B<NEW CERTIFICATE REQUEST>
+(as required by some CAs). The B<X509_REQ> read functions will
+handle either form so there are no B<X509_REQ_NEW> read functions.
+
+The B<X509_CRL> functions process an X509 CRL using an X509_CRL
+structure.
+
+The B<PKCS7> functions process a PKCS#7 ContentInfo using a PKCS7
+structure.
+
+The B<NETSCAPE_CERT_SEQUENCE> functions process a Netscape Certificate
+Sequence using a NETSCAPE_CERT_SEQUENCE structure.
+
+=head1 PEM FUNCTION ARGUMENTS
+
+The PEM functions have many common arguments.
+
+The B<bp> BIO parameter (if present) specifies the BIO to read from
+or write to.
+
+The B<fp> FILE parameter (if present) specifies the FILE pointer to
+read from or write to.
+
+The PEM read functions all take an argument B<TYPE **x> and return
+a B<TYPE *> pointer. Where B<TYPE> is whatever structure the function
+uses. If B<x> is NULL then the parameter is ignored. If B<x> is not
+NULL but B<*x> is NULL then the structure returned will be written
+to B<*x>. If neither B<x> nor B<*x> is NULL then an attempt is made
+to reuse the structure at B<*x> (but see BUGS and EXAMPLES sections).
+Irrespective of the value of B<x> a pointer to the structure is always
+returned (or NULL if an error occurred).
+
+The PEM functions which write private keys take an B<enc> parameter
+which specifies the encryption algorithm to use, encryption is done
+at the PEM level. If this parameter is set to NULL then the private
+key is written in unencrypted form.
+
+The B<cb> argument is the callback to use when querying for the pass
+phrase used for encrypted PEM structures (normally only private keys).
+
+For the PEM write routines if the B<kstr> parameter is not NULL then
+B<klen> bytes at B<kstr> are used as the passphrase and B<cb> is
+ignored.
+
+If the B<cb> parameters is set to NULL and the B<u> parameter is not
+NULL then the B<u> parameter is interpreted as a null terminated string
+to use as the passphrase. If both B<cb> and B<u> are NULL then the
+default callback routine is used which will typically prompt for the
+passphrase on the current terminal with echoing turned off.
+
+The default passphrase callback is sometimes inappropriate (for example
+in a GUI application) so an alternative can be supplied. The callback
+routine has the following form:
+
+ int cb(char *buf, int size, int rwflag, void *u);
+
+B<buf> is the buffer to write the passphrase to. B<size> is the maximum
+length of the passphrase (i.e. the size of buf). B<rwflag> is a flag
+which is set to 0 when reading and 1 when writing. A typical routine
+will ask the user to verify the passphrase (for example by prompting
+for it twice) if B<rwflag> is 1. The B<u> parameter has the same
+value as the B<u> parameter passed to the PEM routine. It allows
+arbitrary data to be passed to the callback by the application
+(for example a window handle in a GUI application). The callback
+B<must> return the number of characters in the passphrase or 0 if
+an error occurred.
+
+=head1 EXAMPLES
+
+Although the PEM routines take several arguments in almost all applications
+most of them are set to 0 or NULL.
+
+Read a certificate in PEM format from a BIO:
+
+ X509 *x;
+ x = PEM_read_bio_X509(bp, NULL, 0, NULL);
+ if (x == NULL)
+	{
+	/* Error */
+	}
+
+Alternative method:
+
+ X509 *x = NULL;
+ if (!PEM_read_bio_X509(bp, &x, 0, NULL))
+	{
+	/* Error */
+	}
+
+Write a certificate to a BIO:
+
+ if (!PEM_write_bio_X509(bp, x))
+	{
+	/* Error */
+	}
+
+Write an unencrypted private key to a FILE pointer:
+
+ if (!PEM_write_PrivateKey(fp, key, NULL, NULL, 0, 0, NULL))
+	{
+	/* Error */
+	}
+
+Write a private key (using traditional format) to a BIO using
+triple DES encryption, the pass phrase is prompted for:
+
+ if (!PEM_write_bio_PrivateKey(bp, key, EVP_des_ede3_cbc(), NULL, 0, 0, NULL))
+	{
+	/* Error */
+	}
+
+Write a private key (using PKCS#8 format) to a BIO using triple
+DES encryption, using the pass phrase "hello":
+
+ if (!PEM_write_bio_PKCS8PrivateKey(bp, key, EVP_des_ede3_cbc(), NULL, 0, 0, "hello"))
+	{
+	/* Error */
+	}
+
+Read a private key from a BIO using the pass phrase "hello":
+
+ key = PEM_read_bio_PrivateKey(bp, NULL, 0, "hello");
+ if (key == NULL)
+	{
+	/* Error */
+	}
+
+Read a private key from a BIO using a pass phrase callback:
+
+ key = PEM_read_bio_PrivateKey(bp, NULL, pass_cb, "My Private Key");
+ if (key == NULL)
+	{
+	/* Error */
+	}
+
+Skeleton pass phrase callback:
+
+ int pass_cb(char *buf, int size, int rwflag, void *u);
+	{
+	int len;
+	char *tmp;
+	/* We'd probably do something else if 'rwflag' is 1 */
+	printf("Enter pass phrase for \"%s\"\n", u);
+
+	/* get pass phrase, length 'len' into 'tmp' */
+	tmp = "hello";
+	len = strlen(tmp);
+
+	if (len <= 0) return 0;
+	/* if too long, truncate */
+	if (len > size) len = size;
+	memcpy(buf, tmp, len);
+	return len;
+	}
+
+=head1 NOTES
+
+The old B<PrivateKey> write routines are retained for compatibility.
+New applications should write private keys using the
+PEM_write_bio_PKCS8PrivateKey() or PEM_write_PKCS8PrivateKey() routines
+because they are more secure (they use an iteration count of 2048 whereas
+the traditional routines use a count of 1) unless compatibility with older
+versions of OpenSSL is important.
+
+The B<PrivateKey> read routines can be used in all applications because
+they handle all formats transparently.
+
+A frequent cause of problems is attempting to use the PEM routines like
+this:
+
+ X509 *x;
+ PEM_read_bio_X509(bp, &x, 0, NULL);
+
+this is a bug because an attempt will be made to reuse the data at B<x>
+which is an uninitialised pointer.
+
+=head1 PEM ENCRYPTION FORMAT
+
+This old B<PrivateKey> routines use a non standard technique for encryption.
+
+The private key (or other data) takes the following form: 
+
+ -----BEGIN RSA PRIVATE KEY-----
+ Proc-Type: 4,ENCRYPTED
+ DEK-Info: DES-EDE3-CBC,3F17F5316E2BAC89
+
+ ...base64 encoded data...
+ -----END RSA PRIVATE KEY-----
+
+The line beginning DEK-Info contains two comma separated pieces of information:
+the encryption algorithm name as used by EVP_get_cipherbyname() and an 8
+byte B<salt> encoded as a set of hexadecimal digits.
+
+After this is the base64 encoded encrypted data.
+
+The encryption key is determined using EVP_bytestokey(), using B<salt> and an
+iteration count of 1. The IV used is the value of B<salt> and *not* the IV
+returned by EVP_bytestokey().
+
+=head1 BUGS
+
+The PEM read routines in some versions of OpenSSL will not correctly reuse
+an existing structure. Therefore the following:
+
+ PEM_read_bio_X509(bp, &x, 0, NULL);
+
+where B<x> already contains a valid certificate, may not work, whereas: 
+
+ X509_free(x);
+ x = PEM_read_bio_X509(bp, NULL, 0, NULL);
+
+is guaranteed to work.
+
+=head1 RETURN CODES
+
+The read routines return either a pointer to the structure read or NULL
+if an error occurred.
+
+The write routines return 1 for success or 0 for failure.
diff --git a/lib/libcrypto/doc/RAND.pod b/lib/libcrypto/doc/RAND.pod
new file mode 100644
index 00000000000..e987414477d
--- /dev/null
+++ b/lib/libcrypto/doc/RAND.pod
@@ -0,0 +1,74 @@
+=pod
+
+=head1 NAME
+
+rand - pseudo-random number generator
+
+=head1 SYNOPSIS
+
+ #include <openssl/rand.h>
+
+ int  RAND_set_rand_engine(ENGINE *engine);
+
+ int  RAND_bytes(unsigned char *buf, int num);
+ int  RAND_pseudo_bytes(unsigned char *buf, int num);
+
+ void RAND_seed(const void *buf, int num);
+ void RAND_add(const void *buf, int num, int entropy);
+ int  RAND_status(void);
+
+ int  RAND_load_file(const char *file, long max_bytes);
+ int  RAND_write_file(const char *file);
+ const char *RAND_file_name(char *file, size_t num);
+
+ int  RAND_egd(const char *path);
+
+ void RAND_set_rand_method(const RAND_METHOD *meth);
+ const RAND_METHOD *RAND_get_rand_method(void);
+ RAND_METHOD *RAND_SSLeay(void);
+
+ void RAND_cleanup(void);
+
+=head1 DESCRIPTION
+
+Since the introduction of the ENGINE API, the recommended way of controlling
+default implementations is by using the ENGINE API functions. The default
+B<RAND_METHOD>, as set by RAND_set_rand_method() and returned by
+RAND_get_rand_method(), is only used if no ENGINE has been set as the default
+"rand" implementation. Hence, these two functions are no longer the recommened
+way to control defaults.
+
+If an alternative B<RAND_METHOD> implementation is being used (either set
+directly or as provided by an ENGINE module), then it is entirely responsible
+for the generation and management of a cryptographically secure PRNG stream. The
+mechanisms described below relate solely to the software PRNG implementation
+built in to OpenSSL and used by default.
+
+These functions implement a cryptographically secure pseudo-random
+number generator (PRNG). It is used by other library functions for
+example to generate random keys, and applications can use it when they
+need randomness.
+
+A cryptographic PRNG must be seeded with unpredictable data such as
+mouse movements or keys pressed at random by the user. This is
+described in L<RAND_add(3)|RAND_add(3)>. Its state can be saved in a seed file
+(see L<RAND_load_file(3)|RAND_load_file(3)>) to avoid having to go through the
+seeding process whenever the application is started.
+
+L<RAND_bytes(3)|RAND_bytes(3)> describes how to obtain random data from the
+PRNG. 
+
+=head1 INTERNALS
+
+The RAND_SSLeay() method implements a PRNG based on the systems'
+L<arc4random_buf(3)> random number generator.
+
+=head1 SEE ALSO
+
+L<BN_rand(3)|BN_rand(3)>, L<RAND_add(3)|RAND_add(3)>,
+L<RAND_load_file(3)|RAND_load_file(3)>, L<RAND_egd(3)|RAND_egd(3)>,
+L<RAND_bytes(3)|RAND_bytes(3)>,
+L<RAND_set_rand_method(3)|RAND_set_rand_method(3)>,
+L<RAND_cleanup(3)|RAND_cleanup(3)> 
+
+=cut
diff --git a/lib/libcrypto/doc/RC4.pod b/lib/libcrypto/doc/RC4.pod
new file mode 100644
index 00000000000..b6d3a4342ca
--- /dev/null
+++ b/lib/libcrypto/doc/RC4.pod
@@ -0,0 +1,62 @@
+=pod
+
+=head1 NAME
+
+RC4_set_key, RC4 - RC4 encryption
+
+=head1 SYNOPSIS
+
+ #include <openssl/rc4.h>
+
+ void RC4_set_key(RC4_KEY *key, int len, const unsigned char *data);
+
+ void RC4(RC4_KEY *key, unsigned long len, const unsigned char *indata,
+          unsigned char *outdata);
+
+=head1 DESCRIPTION
+
+This library implements the Alleged RC4 cipher, which is described for
+example in I<Applied Cryptography>.  It is believed to be compatible
+with RC4[TM], a proprietary cipher of RSA Security Inc.
+
+RC4 is a stream cipher with variable key length.  Typically, 128 bit
+(16 byte) keys are used for strong encryption, but shorter insecure
+key sizes have been widely used due to export restrictions.
+
+RC4 consists of a key setup phase and the actual encryption or
+decryption phase.
+
+RC4_set_key() sets up the B<RC4_KEY> B<key> using the B<len> bytes long
+key at B<data>.
+
+RC4() encrypts or decrypts the B<len> bytes of data at B<indata> using
+B<key> and places the result at B<outdata>.  Repeated RC4() calls with
+the same B<key> yield a continuous key stream.
+
+Since RC4 is a stream cipher (the input is XORed with a pseudo-random
+key stream to produce the output), decryption uses the same function
+calls as encryption.
+
+Applications should use the higher level functions
+L<EVP_EncryptInit(3)|EVP_EncryptInit(3)>
+etc. instead of calling the RC4 functions directly.
+
+=head1 RETURN VALUES
+
+RC4_set_key() and RC4() do not return values.
+
+=head1 NOTE
+
+Certain conditions have to be observed to securely use stream ciphers.
+It is not permissible to perform multiple encryptions using the same
+key stream.
+
+=head1 SEE ALSO
+
+L<blowfish(3)|blowfish(3)>, L<des(3)|des(3)>, L<rc2(3)|rc2(3)>
+
+=head1 HISTORY
+
+RC4_set_key() and RC4() are available in all versions of SSLeay and OpenSSL.
+
+=cut
diff --git a/lib/libcrypto/doc/RIPEMD160.pod b/lib/libcrypto/doc/RIPEMD160.pod
new file mode 100644
index 00000000000..264bb99ae79
--- /dev/null
+++ b/lib/libcrypto/doc/RIPEMD160.pod
@@ -0,0 +1,66 @@
+=pod
+
+=head1 NAME
+
+RIPEMD160, RIPEMD160_Init, RIPEMD160_Update, RIPEMD160_Final -
+RIPEMD-160 hash function
+
+=head1 SYNOPSIS
+
+ #include <openssl/ripemd.h>
+
+ unsigned char *RIPEMD160(const unsigned char *d, unsigned long n,
+                  unsigned char *md);
+
+ int RIPEMD160_Init(RIPEMD160_CTX *c);
+ int RIPEMD160_Update(RIPEMD_CTX *c, const void *data,
+                  unsigned long len);
+ int RIPEMD160_Final(unsigned char *md, RIPEMD160_CTX *c);
+
+=head1 DESCRIPTION
+
+RIPEMD-160 is a cryptographic hash function with a
+160 bit output.
+
+RIPEMD160() computes the RIPEMD-160 message digest of the B<n>
+bytes at B<d> and places it in B<md> (which must have space for
+RIPEMD160_DIGEST_LENGTH == 20 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:
+
+RIPEMD160_Init() initializes a B<RIPEMD160_CTX> structure.
+
+RIPEMD160_Update() can be called repeatedly with chunks of the message to
+be hashed (B<len> bytes at B<data>).
+
+RIPEMD160_Final() places the message digest in B<md>, which must have
+space for RIPEMD160_DIGEST_LENGTH == 20 bytes of output, and erases
+the B<RIPEMD160_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
+
+RIPEMD160() returns a pointer to the hash value. 
+
+RIPEMD160_Init(), RIPEMD160_Update() and RIPEMD160_Final() return 1 for
+success, 0 otherwise.
+
+=head1 CONFORMING TO
+
+ISO/IEC 10118-3 (draft) (??)
+
+=head1 SEE ALSO
+
+L<sha(3)|sha(3)>, L<hmac(3)|hmac(3)>, L<EVP_DigestInit(3)|EVP_DigestInit(3)>
+
+=head1 HISTORY
+
+RIPEMD160(), RIPEMD160_Init(), RIPEMD160_Update() and
+RIPEMD160_Final() are available since SSLeay 0.9.0.
+
+=cut
diff --git a/lib/libcrypto/doc/SHA1.pod b/lib/libcrypto/doc/SHA1.pod
new file mode 100644
index 00000000000..94ab7bc7241
--- /dev/null
+++ b/lib/libcrypto/doc/SHA1.pod
@@ -0,0 +1,70 @@
+=pod
+
+=head1 NAME
+
+SHA1, SHA1_Init, SHA1_Update, SHA1_Final - Secure Hash Algorithm
+
+=head1 SYNOPSIS
+
+ #include <openssl/sha.h>
+
+ unsigned char *SHA1(const unsigned char *d, unsigned long n,
+                  unsigned char *md);
+
+ int SHA1_Init(SHA_CTX *c);
+ int SHA1_Update(SHA_CTX *c, const void *data,
+                  unsigned long len);
+ int SHA1_Final(unsigned char *md, SHA_CTX *c);
+
+=head1 DESCRIPTION
+
+SHA-1 (Secure Hash Algorithm) is a cryptographic hash function with a
+160 bit output.
+
+SHA1() computes the SHA-1 message digest of the B<n>
+bytes at B<d> and places it in B<md> (which must have space for
+SHA_DIGEST_LENGTH == 20 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:
+
+SHA1_Init() initializes a B<SHA_CTX> structure.
+
+SHA1_Update() can be called repeatedly with chunks of the message to
+be hashed (B<len> bytes at B<data>).
+
+SHA1_Final() places the message digest in B<md>, which must have space
+for SHA_DIGEST_LENGTH == 20 bytes of output, and erases the B<SHA_CTX>.
+
+Applications should use the higher level functions
+L<EVP_DigestInit(3)|EVP_DigestInit(3)>
+etc. instead of calling the hash functions directly.
+
+The predecessor of SHA-1, SHA, is also implemented, but it should be
+used only when backward compatibility is required.
+
+=head1 RETURN VALUES
+
+SHA1() returns a pointer to the hash value. 
+
+SHA1_Init(), SHA1_Update() and SHA1_Final() return 1 for success, 0 otherwise.
+
+=head1 CONFORMING TO
+
+SHA: US Federal Information Processing Standard FIPS PUB 180 (Secure Hash
+Standard),
+SHA-1: US Federal Information Processing Standard FIPS PUB 180-1 (Secure Hash
+Standard),
+ANSI X9.30
+
+=head1 SEE ALSO
+
+L<ripemd(3)|ripemd(3)>, L<hmac(3)|hmac(3)>, L<EVP_DigestInit(3)|EVP_DigestInit(3)>
+
+=head1 HISTORY
+
+SHA1(), SHA1_Init(), SHA1_Update() and SHA1_Final() are available in all
+versions of SSLeay and OpenSSL.
+
+=cut