ispell.
This commit is contained in:
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
||||
|
@@ -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.
|
||||
|
||||
|
@@ -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.
|
||||
|
||||
|
@@ -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
|
||||
|
@@ -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>
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -27,8 +27,8 @@ SSL_library_init() must be called before any other action takes place.
|
||||
=head1 IMPORTANT
|
||||
|
||||
SSL_library_init() only registers ciphers. Another important initialization
|
||||
is the seeding of the PRNG (Pseude Random Number Generator), which has to
|
||||
be performed seperately.
|
||||
is the seeding of the PRNG (Pseudo Random Number Generator), which has to
|
||||
be performed separately.
|
||||
|
||||
=head1 EXAMPLES
|
||||
|
||||
|
Reference in New Issue
Block a user