ispell.

15 files changed, 42 insertions, 42 deletions

diff --git a/doc/crypto/EVP_DigestInit.pod b/doc/crypto/EVP_DigestInit.pod
index f87377945b..b8a231c642 100644
--- a/doc/crypto/EVP_DigestInit.pod
+++ b/doc/crypto/EVP_DigestInit.pod
@@ -50,12 +50,12 @@ EVP digest routines
 
 The EVP digest routines are a high level interface to message digests.
 
-EVP_DigestInit() initialises a digest context B<ctx> to use a digest
+EVP_DigestInit() initializes a digest context B<ctx> to use a digest
 B<type>: this will typically be supplied by a function such as
 EVP_sha1().
 
 EVP_DigestUpdate() hashes B<cnt> bytes of data at B<d> into the
-digest context B<ctx>. This funtion can be called several times on the
+digest context B<ctx>. This function can be called several times on the
 same B<ctx> to hash additional data.
 
 EVP_DigestFinal() retrieves the digest value from B<ctx> and places
@@ -63,7 +63,7 @@ it in B<md>. If the B<s> parameter is not NULL then the number of
 bytes of data written (i.e. the length of the digest) will be written
 to the integer at B<s>, at most B<EVP_MAX_MD_SIZE> bytes will be written.
 After calling EVP_DigestFinal() no additional calls to EVP_DigestUpdate()
-can be made, but EVP_DigestInit() can be called to initialiase a new
+can be made, but EVP_DigestInit() can be called to initialize a new
 digest operation.
 
 EVP_MD_CTX_copy() can be used to copy the message digest state from
@@ -102,7 +102,7 @@ returns is of zero length.
 
 EVP_get_digestbyname(), EVP_get_digestbynid() and EVP_get_digestbyobj()
 return an B<EVP_MD> structure when passed a digest name, a digest NID or
-an ASN1_OBJECT structure respectively. The digest table must be initialised
+an ASN1_OBJECT structure respectively. The digest table must be initialized
 using, for example, OpenSSL_add_all_digests() for these functions to work.
 
 =head1 RETURN VALUES
diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod
index 447e7f1a92..9afe2396e2 100644
--- a/doc/crypto/EVP_EncryptInit.pod
+++ b/doc/crypto/EVP_EncryptInit.pod
@@ -74,7 +74,7 @@ EVP_CIPHER_asn1_to_param - EVP cipher routines
 The EVP cipher routines are a high level interface to certain
 symmetric ciphers.
 
-EVP_EncryptInit() initialises a cipher context B<ctx> for encryption
+EVP_EncryptInit() initializes a cipher context B<ctx> for encryption
 with cipher B<type>. B<type> is normally supplied by a function such
 as EVP_des_cbc() . B<key> is the symmetric key to use and B<iv> is the
 IV to use (if necessary), the actual number of bytes used for the
@@ -255,7 +255,7 @@ and the EVP_CIPHER_CTX_set_key_length() function.
 
 =item EVP_idea_cbc() EVP_idea_ecb(void), EVP_idea_cfb(void), EVP_idea_ofb(void), EVP_idea_cbc(void)
 
-IDES encryption algorothm in CBC, ECB, CFB and OFB modes respectively.
+IDEA encryption algorithm in CBC, ECB, CFB and OFB modes respectively.
 
 =item EVP_rc2_cbc(void), EVP_rc2_ecb(void), EVP_rc2_cfb(void), EVP_rc2_ofb(void)
 
@@ -325,7 +325,7 @@ default key lengths. If custom ciphers exceed these values the results are
 unpredictable. This is because it has become standard practice to define a 
 generic key as a fixed unsigned char array containing EVP_MAX_KEY_LENGTH bytes.
 
-The ASN1 code is incomplete (and sometimes innacurate) it has only been tested
+The ASN1 code is incomplete (and sometimes inaccurate) it has only been tested
 for certain common S/MIME ciphers (RC2, DES, triple DES) in CBC mode.
 
 =head1 EXAMPLES
diff --git a/doc/crypto/EVP_OpenInit.pod b/doc/crypto/EVP_OpenInit.pod
index c0e5163e8c..1a3f2e410d 100644
--- a/doc/crypto/EVP_OpenInit.pod
+++ b/doc/crypto/EVP_OpenInit.pod
@@ -21,7 +21,7 @@ The EVP envelope routines are a high level interface to envelope
 decryption. They decrypt a public key encrypted symmetric key and
 then decrypt data using it.
 
-EVP_OpenInit() initialises a cipher context B<ctx> for decryption
+EVP_OpenInit() initializes a cipher context B<ctx> for decryption
 with cipher B<type>. It decrypts the encrypted symmetric key of length
 B<ekl> bytes passed in the B<ek> parameter using the private key B<priv>.
 The IV is supplied in the B<iv> parameter.
@@ -35,7 +35,7 @@ page.
 
 It is possible to call EVP_OpenInit() twice in the same way as
 EVP_DecryptInit(). The first call should have B<priv> set to NULL
-and (after setting any cipher paramaters) it should be called again
+and (after setting any cipher parameters) it should be called again
 with B<type> set to NULL.
 
 If the cipher passed in the B<type> parameter is a variable length
diff --git a/doc/crypto/EVP_SealInit.pod b/doc/crypto/EVP_SealInit.pod
index 9579e91d2e..f7f7613965 100644
--- a/doc/crypto/EVP_SealInit.pod
+++ b/doc/crypto/EVP_SealInit.pod
@@ -22,7 +22,7 @@ encryption. They generate a random key and then "envelope" it by
 using public key encryption. Data can then be encrypted using this
 key.
 
-EVP_SealInit() initialises a cipher context B<ctx> for encryption
+EVP_SealInit() initializes a cipher context B<ctx> for encryption
 with cipher B<type> using a random secret key and IV supplied in
 the B<iv> parameter. B<type> is normally supplied by a function such
 as EVP_des_cbc(). The secret key is encrypted using one or more public
@@ -62,7 +62,7 @@ using public key encryption.
 
 It is possible to call EVP_SealInit() twice in the same way as
 EVP_EncryptInit(). The first call should have B<npubk> set to 0
-and (after setting any cipher paramaters) it should be called again
+and (after setting any cipher parameters) it should be called again
 with B<type> set to NULL.
 
 =head1 SEE ALSO
diff --git a/doc/crypto/EVP_SignInit.pod b/doc/crypto/EVP_SignInit.pod
index bbc9203c9c..7f9265d0a6 100644
--- a/doc/crypto/EVP_SignInit.pod
+++ b/doc/crypto/EVP_SignInit.pod
@@ -19,12 +19,12 @@ EVP_SignInit, EVP_SignUpdate, EVP_SignFinal - EVP signing functions
 The EVP signature routines are a high level interface to digital
 signatures.
 
-EVP_SignInit() initialises a signing context B<ctx> to using digest
+EVP_SignInit() initializes a signing context B<ctx> to using digest
 B<type>: this will typically be supplied by a function such as
 EVP_sha1().
 
 EVP_SignUpdate() hashes B<cnt> bytes of data at B<d> into the
-signature context B<ctx>. This funtion can be called several times on the
+signature context B<ctx>. This function can be called several times on the
 same B<ctx> to include additional data.
 
 EVP_SignFinal() signs the data in B<ctx> using the private key B<pkey>
@@ -32,7 +32,7 @@ and places the signature in B<sig>. If the B<s> parameter is not NULL
 then the number of bytes of data written (i.e. the length of the signature)
 will be written to the integer at B<s>, at most EVP_PKEY_size(pkey) bytes
 will be written.  After calling EVP_SignFinal() no additional calls to
-EVP_SignUpdate() can be made, but EVP_SignInit() can be called to initialiase
+EVP_SignUpdate() can be made, but EVP_SignInit() can be called to initialize
 a new signature operation.
 
 EVP_PKEY_size() returns the maximum size of a signature in bytes. The actual
diff --git a/doc/crypto/EVP_VerifyInit.pod b/doc/crypto/EVP_VerifyInit.pod
index 3b5e07f4ad..76d893b53b 100644
--- a/doc/crypto/EVP_VerifyInit.pod
+++ b/doc/crypto/EVP_VerifyInit.pod
@@ -17,17 +17,17 @@ EVP_VerifyInit, EVP_VerifyUpdate, EVP_VerifyFinal - EVP signature verification f
 The EVP signature verification routines are a high level interface to digital
 signatures.
 
-EVP_VerifyInit() initialises a verification context B<ctx> to using digest
+EVP_VerifyInit() initializes a verification context B<ctx> to using digest
 B<type>: this will typically be supplied by a function such as EVP_sha1().
 
 EVP_VerifyUpdate() hashes B<cnt> bytes of data at B<d> into the
-verification context B<ctx>. This funtion can be called several times on the
+verification context B<ctx>. This function can be called several times on the
 same B<ctx> to include additional data.
 
 EVP_VerifyFinal() verifies the data in B<ctx> using the public key B<pkey>
 and against the B<siglen> bytes at B<sigbuf>. After calling EVP_VerifyFinal()
 no additional calls to EVP_VerifyUpdate() can be made, but EVP_VerifyInit()
-can be called to initialiase a new verification operation.
+can be called to initialize a new verification operation.
 
 =head1 RETURN VALUES
 
diff --git a/doc/crypto/OPENSSL_VERSION_NUMBER.pod b/doc/crypto/OPENSSL_VERSION_NUMBER.pod
index e333b30723..68ea723259 100644
--- a/doc/crypto/OPENSSL_VERSION_NUMBER.pod
+++ b/doc/crypto/OPENSSL_VERSION_NUMBER.pod
@@ -39,7 +39,7 @@ for example
  0x000904100 == 0.9.4 release
  0x000905000 == 0.9.5 dev
 
-Version 0.9.5a had an interrim interpretation that is like the current one,
+Version 0.9.5a had an interim interpretation that is like the current one,
 except the patch level got the highest bit set, to keep continuity.  The
 number was therefore 0x0090581f.
 
diff --git a/doc/crypto/OpenSSL_add_all_algorithms.pod b/doc/crypto/OpenSSL_add_all_algorithms.pod
index 3f89068001..486c903430 100644
--- a/doc/crypto/OpenSSL_add_all_algorithms.pod
+++ b/doc/crypto/OpenSSL_add_all_algorithms.pod
@@ -44,7 +44,7 @@ by EVP_sha1(). It just needs to add them if it (or any of the functions it calls
 needs to lookup algorithms.
 
 The cipher and digest lookup functions are used in many parts of the library. If
-the table is not initialised several functions will misbehave and complain they
+the table is not initialized several functions will misbehave and complain they
 cannot find algorithms. This includes the PEM, PKCS#12, SSL and S/MIME libraries.
 This is a common query in the OpenSSL mailing lists.
 
diff --git a/doc/crypto/blowfish.pod b/doc/crypto/blowfish.pod
index fef5f2a079..ba6cc368e8 100644
--- a/doc/crypto/blowfish.pod
+++ b/doc/crypto/blowfish.pod
@@ -51,35 +51,35 @@ B<in> and B<out> must be 64 bits in length, no less.  If they are larger,
 everything after the first 64 bits is ignored.
 
 The mode functions BF_cbc_encrypt(), BF_cfb64_encrypt() and BF_ofb64_encrypt()
-all operate on variable length data.  They all take an initialisation vector
+all operate on variable length data.  They all take an initialization vector
 B<ivec> which needs to be passed along into the next call of the same function 
-for the same message.  B<ivec> may be initialised with anything, but the
-recipient needs to know what it was initialised with, or it won't be able
+for the same message.  B<ivec> may be initialized with anything, but the
+recipient needs to know what it was initialized with, or it won't be able
 to decrypt.  Some programs and protocols simplify this, like SSH, where
-B<ivec> is simply initialised to zero.
+B<ivec> is simply initialized to zero.
 BF_cbc_encrypt() operates of data that is a multiple of 8 bytes long, while
 BF_cfb64_encrypt() and BF_ofb64_encrypt() are used to encrypt an variable
 number of bytes (the amount does not have to be an exact multiple of 8).  The
 purpose of the latter two is to simulate stream ciphers, and therefore, they
 need the parameter B<num>, which is a pointer to an integer where the current
-offset in B<ivec> is stored between calls.  This integer must be initialised
-to zero when B<ivec> is initialised.
+offset in B<ivec> is stored between calls.  This integer must be initialized
+to zero when B<ivec> is initialized.
 
 BF_cbc_encrypt() is the Cipher Block Chaining function for Blowfish.  It
 encrypts or decrypts the 64 bits chunks of B<in> using the key B<schedule>,
 putting the result in B<out>.  B<enc> decides if encryption (BF_ENCRYPT) or
 decryption (BF_DECRYPT) shall be performed.  B<ivec> must point at an 8 byte
-long initialisation vector.
+long initialization vector.
 
 BF_cfb64_encrypt() is the CFB mode for Blowfish with 64 bit feedback.
 It encrypts or decrypts the bytes in B<in> using the key B<schedule>,
 putting the result in B<out>.  B<enc> decides if encryption (B<BF_ENCRYPT>)
 or decryption (B<BF_DECRYPT>) shall be performed.  B<ivec> must point at an
-8 byte long initialisation vector. B<num> must point at an integer which must
+8 byte long initialization vector. B<num> must point at an integer which must
 be initially zero.
 
 BF_ofb64_encrypt() is the OFB mode for Blowfish with 64 bit feedback.
-It uses the same parameters as BF_cfb64_encrypt(), which must be initialised
+It uses the same parameters as BF_cfb64_encrypt(), which must be initialized
 the same way.
 
 BF_encrypt() and BF_decrypt() are the lowest level functions for Blowfish
diff --git a/doc/crypto/bn_internal.pod b/doc/crypto/bn_internal.pod
index 5af0c791c8..8da244aed4 100644
--- a/doc/crypto/bn_internal.pod
+++ b/doc/crypto/bn_internal.pod
@@ -149,7 +149,7 @@ word array B<a>, the B<nb> word array B<b> and the B<na>+B<nb> word
 array B<r>.  It computes B<a>*B<b> and places the result in B<r>.
 
 bn_mul_low_normal(B<r>, B<a>, B<b>, B<n>) operates on the B<n> word
-arrays B<r>, B<a> und B<b>.  It computes the B<n> low words of
+arrays B<r>, B<a> and B<b>.  It computes the B<n> low words of
 B<a>*B<b> and places the result in B<r>.
 
 bn_mul_recursive(B<r>, B<a>, B<b>, B<n2>, B<t>) operates on the B<n2>
diff --git a/doc/crypto/buffer.pod b/doc/crypto/buffer.pod
index 7088f51bc4..1a02f9754f 100644
--- a/doc/crypto/buffer.pod
+++ b/doc/crypto/buffer.pod
@@ -68,6 +68,6 @@ L<bio(3)|bio(3)>
 =head1 HISTORY
 
 BUF_MEM_new(), BUF_MEM_free() and BUF_MEM_grow() are available in all
-versions of SSLeay and OpenSSL. BUF_strdup() was addded in SSLeay 0.8.
+versions of SSLeay and OpenSSL. BUF_strdup() was added in SSLeay 0.8.
 
 =cut
diff --git a/doc/crypto/des.pod b/doc/crypto/des.pod
index c553210ef2..ab3e26e9ec 100644
--- a/doc/crypto/des.pod
+++ b/doc/crypto/des.pod
@@ -130,7 +130,7 @@ earlier versions of the library, des_random_key() did not generate
 secure keys.
 
 Before a DES key can be used, it must be converted into the
-architecture dependant I<des_key_schedule> via 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
@@ -200,7 +200,7 @@ 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
-chaing mode used by Kerberos v4. Its parameters are the same as
+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
@@ -241,7 +241,7 @@ compatibility with the MIT Kerberos library. des_read_pw_string()
 is also available under the name EVP_read_pw_string().
 
 des_read_pw_string() writes the string specified by I<prompt> to
-standarf output, turns echo off and reads in input string from the
+standard output, turns echo off and reads in input string from the
 terminal.  The string is returned in I<buf>, which must have space for
 at least I<length> bytes.  If I<verify> is set, the user is asked for
 the password twice and unless the two copies match, an error is
@@ -268,9 +268,9 @@ 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 tranformations:
+The following are DES-based transformations:
 
-des_fcrypt() is a fast version of the unix crypt(3) function.  This
+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
diff --git a/doc/crypto/des_modes.pod b/doc/crypto/des_modes.pod
index 1aa3ac763b..36b77c454d 100644
--- a/doc/crypto/des_modes.pod
+++ b/doc/crypto/des_modes.pod
@@ -6,7 +6,7 @@ Modes of DES - the variants of DES and other crypto algorithms of OpenSSL
 
 =head1 DESCRIPTION
 
-Several crypto algorithms fo OpenSSL can be used in a number of modes.  Those
+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.
 
@@ -165,13 +165,13 @@ only one bit to be in error in the deciphered plaintext.
 
 =item *
 
-OFB mode is not self-synchronising.  If the two operation of
+OFB mode is not self-synchronizing.  If the two operation of
 encipherment and decipherment get out of synchronism, the system needs
-to be re-initialised.
+to be re-initialized.
 
 =item *
 
-Each re-initialisation should use a value of the start variable
+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
diff --git a/doc/crypto/err.pod b/doc/crypto/err.pod
index b824c92b57..264e30103d 100644
--- a/doc/crypto/err.pod
+++ b/doc/crypto/err.pod
@@ -143,7 +143,7 @@ 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 containg any
+header file must load any additional header files containing any
 definitions it uses.
 
 =head1 USING ERROR CODES IN EXTERNAL LIBRARIES
diff --git a/doc/crypto/threads.pod b/doc/crypto/threads.pod
index 7fa18aa443..bc7ff9b705 100644
--- a/doc/crypto/threads.pod
+++ b/doc/crypto/threads.pod
@@ -53,7 +53,7 @@ OpenSSL can safely be used in multi-threaded applications provided
 that at least two callback functions are set.
 
 locking_function(int mode, int n, const char *file, int line) is
-needed to perform locking on shared data stuctures. Multi-threaded
+needed to perform locking on shared data structures. Multi-threaded
 applications will crash at random if it is not set.
 
 locking_function() must be able to handle up to CRYPTO_num_locks()
@@ -89,7 +89,7 @@ dyn_create_function(const char *file, int line) is needed to create a
 lock.  Multi-threaded applications might crash at random if it is not set.
 
 dyn_lock_function(int mode, CRYPTO_dynlock *l, const char *file, int line)
-is needed to perform locking off dynamic lock nunmbered n. Multi-threaded
+is needed to perform locking off dynamic lock numbered n. Multi-threaded
 applications might crash at random if it is not set.
 
 dyn_destroy_function(CRYPTO_dynlock *l, const char *file, int line) is