aboutsummaryrefslogtreecommitdiffstats
path: root/doc/crypto
diff options
context:
space:
mode:
Diffstat (limited to 'doc/crypto')
-rw-r--r--doc/crypto/BIO_read.pod6
-rw-r--r--doc/crypto/BN_rand.pod4
-rw-r--r--doc/crypto/DSA_generate_parameters.pod2
-rw-r--r--doc/crypto/EC_GROUP_copy.pod2
-rw-r--r--doc/crypto/EC_KEY_new.pod4
-rw-r--r--doc/crypto/EVP_DigestVerifyInit.pod9
-rw-r--r--doc/crypto/EVP_EncryptInit.pod2
-rw-r--r--doc/crypto/EVP_SealInit.pod2
-rw-r--r--doc/crypto/EVP_SignInit.pod3
-rw-r--r--doc/crypto/X509_check_host.pod2
-rw-r--r--doc/crypto/buffer.pod49
-rw-r--r--doc/crypto/d2i_X509_NAME.pod2
-rw-r--r--doc/crypto/engine.pod10
13 files changed, 51 insertions, 46 deletions
diff --git a/doc/crypto/BIO_read.pod b/doc/crypto/BIO_read.pod
index b34528104ddf..2c177f0b6d86 100644
--- a/doc/crypto/BIO_read.pod
+++ b/doc/crypto/BIO_read.pod
@@ -9,9 +9,9 @@ BIO_read, BIO_write, BIO_gets, BIO_puts - BIO I/O functions
#include <openssl/bio.h>
int BIO_read(BIO *b, void *buf, int len);
- int BIO_gets(BIO *b,char *buf, int size);
+ int BIO_gets(BIO *b, char *buf, int size);
int BIO_write(BIO *b, const void *buf, int len);
- int BIO_puts(BIO *b,const char *buf);
+ int BIO_puts(BIO *b, const char *buf);
=head1 DESCRIPTION
@@ -26,7 +26,7 @@ return the digest and other BIOs may not support BIO_gets() at all.
BIO_write() attempts to write B<len> bytes from B<buf> to BIO B<b>.
-BIO_puts() attempts to write a null terminated string B<buf> to BIO B<b>
+BIO_puts() attempts to write a null terminated string B<buf> to BIO B<b>.
=head1 RETURN VALUES
diff --git a/doc/crypto/BN_rand.pod b/doc/crypto/BN_rand.pod
index bd6bc8632394..e8cbf658b47d 100644
--- a/doc/crypto/BN_rand.pod
+++ b/doc/crypto/BN_rand.pod
@@ -19,7 +19,7 @@ BN_rand, BN_pseudo_rand, BN_rand_range, BN_pseudo_rand_range - generate pseudo-r
=head1 DESCRIPTION
BN_rand() generates a cryptographically strong pseudo-random number of
-B<bits> bits in length and stores it in B<rnd>. If B<top> is -1, the
+B<bits> in length and stores it in B<rnd>. If B<top> is -1, the
most significant bit of the random number can be zero. If B<top> is 0,
it is set to 1, and if B<top> is 1, the two most significant bits of
the number will be set to 1, so that the product of two such random
@@ -33,7 +33,7 @@ non-cryptographic purposes and for certain purposes in cryptographic
protocols, but usually not for key generation etc.
BN_rand_range() generates a cryptographically strong pseudo-random
-number B<rnd> in the range 0 <lt>= B<rnd> E<lt> B<range>.
+number B<rnd> in the range 0 E<lt>= B<rnd> E<lt> B<range>.
BN_pseudo_rand_range() does the same, but is based on BN_pseudo_rand(),
and hence numbers generated by it are not necessarily unpredictable.
diff --git a/doc/crypto/DSA_generate_parameters.pod b/doc/crypto/DSA_generate_parameters.pod
index 16a67f22b0c4..b1a4d201b75c 100644
--- a/doc/crypto/DSA_generate_parameters.pod
+++ b/doc/crypto/DSA_generate_parameters.pod
@@ -29,7 +29,7 @@ maximum of 1024 bits.
If B<seed> is B<NULL> or B<seed_len> E<lt> 20, the primes will be
generated at random. Otherwise, the seed is used to generate
them. If the given seed does not yield a prime q, a new random
-seed is chosen and placed at B<seed>.
+seed is chosen.
DSA_generate_parameters_ex() places the iteration count in
*B<counter_ret> and a counter used for finding a generator in
diff --git a/doc/crypto/EC_GROUP_copy.pod b/doc/crypto/EC_GROUP_copy.pod
index 954af469d5aa..49dc01ced147 100644
--- a/doc/crypto/EC_GROUP_copy.pod
+++ b/doc/crypto/EC_GROUP_copy.pod
@@ -158,7 +158,7 @@ EC_GROUP_get0_seed returns a pointer to the seed that was used to generate the p
specified. EC_GROUP_get_seed_len returns the length of the seed or 0 if the seed is not specified.
EC_GROUP_set_seed returns the length of the seed that has been set. If the supplied seed is NULL, or the supplied seed length is
-0, the the return value will be 1. On error 0 is returned.
+0, the return value will be 1. On error 0 is returned.
EC_GROUP_cmp returns 0 if the curves are equal, 1 if they are not equal, or -1 on error.
diff --git a/doc/crypto/EC_KEY_new.pod b/doc/crypto/EC_KEY_new.pod
index e859689bcb50..0fa2de1721b7 100644
--- a/doc/crypto/EC_KEY_new.pod
+++ b/doc/crypto/EC_KEY_new.pod
@@ -70,8 +70,8 @@ The functions EC_KEY_get0_group, EC_KEY_set_group, EC_KEY_get0_private_key, EC_K
The functions EC_KEY_get_conv_form and EC_KEY_set_conv_form get and set the point_conversion_form for the B<key>. For a description
of point_conversion_forms please refer to L<EC_POINT_new(3)|EC_POINT_new(3)>.
-EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitary additional data specific to the
-elliptic curve scheme being used with the EC_KEY object. This data is treated as a "black box" by the ec library. The data to be stored by EC_KEY_insert_key_method_data is provided in the B<data> parameter, which must have have associated functions for duplicating, freeing and "clear_freeing" the data item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions for duplicating, freeing and "clear_freeing" the data item must be provided again, and they must be the same as they were when the data item was inserted.
+EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitrary additional data specific to the
+elliptic curve scheme being used with the EC_KEY object. This data is treated as a "black box" by the ec library. The data to be stored by EC_KEY_insert_key_method_data is provided in the B<data> parameter, which must have associated functions for duplicating, freeing and "clear_freeing" the data item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions for duplicating, freeing and "clear_freeing" the data item must be provided again, and they must be the same as they were when the data item was inserted.
EC_KEY_set_flags sets the flags in the B<flags> parameter on the EC_KEY object. Any flags that are already set are left set. The currently defined standard flags are EC_FLAG_NON_FIPS_ALLOW and EC_FLAG_FIPS_CHECKED. In addition there is the flag EC_FLAG_COFACTOR_ECDH which is specific to ECDH and is defined in ecdh.h. EC_KEY_get_flags returns the current flags that are set for this EC_KEY. EC_KEY_clear_flags clears the flags indicated by the B<flags> parameter. All other flags are left in their existing state.
diff --git a/doc/crypto/EVP_DigestVerifyInit.pod b/doc/crypto/EVP_DigestVerifyInit.pod
index e0217e40cba8..0ead2d2f8aa1 100644
--- a/doc/crypto/EVP_DigestVerifyInit.pod
+++ b/doc/crypto/EVP_DigestVerifyInit.pod
@@ -37,10 +37,11 @@ EVP_DigestVerifyInit() and EVP_DigestVerifyUpdate() return 1 for success and 0
or a negative value for failure. In particular a return value of -2 indicates
the operation is not supported by the public key algorithm.
-Unlike other functions the return value 0 from EVP_DigestVerifyFinal() only
-indicates that the signature did not verify successfully (that is tbs did
-not match the original data or the signature was of invalid form) it is not an
-indication of a more serious error.
+EVP_DigestVerifyFinal() returns 1 for success; any other value indicates
+failure. A return value of zero indicates that the signature did not verify
+successfully (that is, tbs did not match the original data or the signature had
+an invalid form), while other values indicate a more serious error (and
+sometimes also indicate an invalid signature form).
The error codes can be obtained from L<ERR_get_error(3)|ERR_get_error(3)>.
diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod
index fb6036f959ba..c69e6a6d700e 100644
--- a/doc/crypto/EVP_EncryptInit.pod
+++ b/doc/crypto/EVP_EncryptInit.pod
@@ -111,7 +111,7 @@ EVP_CIPHER_CTX_init() initializes cipher contex B<ctx>.
EVP_EncryptInit_ex() sets up cipher context B<ctx> for encryption
with cipher B<type> from ENGINE B<impl>. B<ctx> must be initialized
before calling this function. B<type> is normally supplied
-by a function such as EVP_des_cbc(). If B<impl> is NULL then the
+by a function such as EVP_aes_256_cbc(). If B<impl> is NULL then the
default implementation is used. 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 key and IV depends on the cipher. It is possible to set
diff --git a/doc/crypto/EVP_SealInit.pod b/doc/crypto/EVP_SealInit.pod
index 7d793e19ef7a..19112a542d89 100644
--- a/doc/crypto/EVP_SealInit.pod
+++ b/doc/crypto/EVP_SealInit.pod
@@ -25,7 +25,7 @@ encrypted using this key.
EVP_SealInit() initializes a cipher context B<ctx> for encryption
with cipher B<type> using a random secret key and IV. B<type> is normally
-supplied by a function such as EVP_des_cbc(). The secret key is encrypted
+supplied by a function such as EVP_aes_256_cbc(). The secret key is encrypted
using one or more public keys, this allows the same encrypted data to be
decrypted using any of the corresponding private keys. B<ek> is an array of
buffers where the public key encrypted secret key will be written, each buffer
diff --git a/doc/crypto/EVP_SignInit.pod b/doc/crypto/EVP_SignInit.pod
index 14ecc775af6a..c63d6b339318 100644
--- a/doc/crypto/EVP_SignInit.pod
+++ b/doc/crypto/EVP_SignInit.pod
@@ -2,7 +2,8 @@
=head1 NAME
-EVP_SignInit, EVP_SignUpdate, EVP_SignFinal - EVP signing functions
+EVP_SignInit, EVP_SignInit_ex, EVP_SignUpdate, EVP_SignFinal - EVP signing
+functions
=head1 SYNOPSIS
diff --git a/doc/crypto/X509_check_host.pod b/doc/crypto/X509_check_host.pod
index 0def17aac1c5..521b9f535c7b 100644
--- a/doc/crypto/X509_check_host.pod
+++ b/doc/crypto/X509_check_host.pod
@@ -135,6 +135,6 @@ L<X509_VERIFY_PARAM_set1_ipasc(3)|X509_VERIFY_PARAM_set1_ipasc(3)>
=head1 HISTORY
-These functions were added in OpenSSL 1.1.0.
+These functions were added in OpenSSL 1.0.2.
=cut
diff --git a/doc/crypto/buffer.pod b/doc/crypto/buffer.pod
index 781f5b11ee54..52c5c841eb03 100644
--- a/doc/crypto/buffer.pod
+++ b/doc/crypto/buffer.pod
@@ -2,8 +2,11 @@
=head1 NAME
-BUF_MEM_new, BUF_MEM_free, BUF_MEM_grow, BUF_strdup - simple
-character arrays structure
+BUF_MEM_new, BUF_MEM_new_ex, BUF_MEM_free, BUF_MEM_grow - simple
+character array structure
+
+BUF_strdup, BUF_strndup, BUF_memdup, BUF_strlcpy, BUF_strlcat -
+standard C library equivalents
=head1 SYNOPSIS
@@ -15,25 +18,22 @@ character arrays structure
int BUF_MEM_grow(BUF_MEM *str, int len);
- char * BUF_strdup(const char *str);
+ char *BUF_strdup(const char *str);
-=head1 DESCRIPTION
+ char *BUF_strndup(const char *str, size_t siz);
-The buffer library handles simple character arrays. Buffers are used for
-various purposes in the library, most notably memory BIOs.
+ void *BUF_memdup(const void *data, size_t siz);
+
+ size_t BUF_strlcpy(char *dst, const char *src, size_t size);
-The library uses the BUF_MEM structure defined in buffer.h:
+ size_t BUF_strlcat(char *dst, const char *src, size_t size);
- typedef struct buf_mem_st
- {
- int length; /* current number of bytes */
- char *data;
- int max; /* size of buffer */
- } BUF_MEM;
+ size_t BUF_strnlen(const char *str, size_t maxlen);
-B<length> is the current size of the buffer in bytes, B<max> is the amount of
-memory allocated to the buffer. There are three functions which handle these
-and one "miscellaneous" function.
+=head1 DESCRIPTION
+
+The buffer library handles simple character arrays. Buffers are used for
+various purposes in the library, most notably memory BIOs.
BUF_MEM_new() allocates a new buffer of zero size.
@@ -44,14 +44,17 @@ BUF_MEM_grow() changes the size of an already existing buffer to
B<len>. Any data already in the buffer is preserved if it increases in
size.
-BUF_strdup() copies a null terminated string into a block of allocated
-memory and returns a pointer to the allocated block.
-Unlike the standard C library strdup() this function uses OPENSSL_malloc() and so
-should be used in preference to the standard library strdup() because it can
-be used for memory leak checking or replacing the malloc() function.
+BUF_strdup(), BUF_strndup(), BUF_memdup(), BUF_strlcpy(),
+BUF_strlcat() and BUF_strnlen are equivalents of the standard C
+library functions. The dup() functions use OPENSSL_malloc() underneath
+and so should be used in preference to the standard library for memory
+leak checking or replacing the malloc() function.
+
+Memory allocated from these functions should be freed up using the
+OPENSSL_free() function.
-The memory allocated from BUF_strdup() should be freed up using the OPENSSL_free()
-function.
+BUF_strndup makes the explicit guarantee that it will never read past
+the first B<siz> bytes of B<str>.
=head1 RETURN VALUES
diff --git a/doc/crypto/d2i_X509_NAME.pod b/doc/crypto/d2i_X509_NAME.pod
index 343ffe151914..b025de7b2ff6 100644
--- a/doc/crypto/d2i_X509_NAME.pod
+++ b/doc/crypto/d2i_X509_NAME.pod
@@ -14,7 +14,7 @@ d2i_X509_NAME, i2d_X509_NAME - X509_NAME encoding functions
=head1 DESCRIPTION
These functions decode and encode an B<X509_NAME> structure which is the
-the same as the B<Name> type defined in RFC2459 (and elsewhere) and used
+same as the B<Name> type defined in RFC2459 (and elsewhere) and used
for example in certificate subject and issuer names.
Othewise the functions behave in a similar way to d2i_X509() and i2d_X509()
diff --git a/doc/crypto/engine.pod b/doc/crypto/engine.pod
index f5ab1c3e50fd..48741ee30629 100644
--- a/doc/crypto/engine.pod
+++ b/doc/crypto/engine.pod
@@ -192,7 +192,7 @@ to use the pointer value at all, as this kind of reference is a guarantee
that the structure can not be deallocated until the reference is released.
However, a structural reference provides no guarantee that the ENGINE is
-initiliased and able to use any of its cryptographic
+initialised and able to use any of its cryptographic
implementations. Indeed it's quite possible that most ENGINEs will not
initialise at all in typical environments, as ENGINEs are typically used to
support specialised hardware. To use an ENGINE's functionality, you need a
@@ -201,8 +201,8 @@ specialised form of structural reference, because each functional reference
implicitly contains a structural reference as well - however to avoid
difficult-to-find programming bugs, it is recommended to treat the two
kinds of reference independently. If you have a functional reference to an
-ENGINE, you have a guarantee that the ENGINE has been initialised ready to
-perform cryptographic operations and will remain uninitialised
+ENGINE, you have a guarantee that the ENGINE has been initialised and
+is ready to perform cryptographic operations, and will remain initialised
until after you have released your reference.
I<Structural references>
@@ -370,7 +370,7 @@ I<Using a specific ENGINE implementation>
Here we'll assume an application has been configured by its user or admin
to want to use the "ACME" ENGINE if it is available in the version of
OpenSSL the application was compiled with. If it is available, it should be
-used by default for all RSA, DSA, and symmetric cipher operation, otherwise
+used by default for all RSA, DSA, and symmetric cipher operations, otherwise
OpenSSL should use its builtin software as per usual. The following code
illustrates how to approach this;
@@ -401,7 +401,7 @@ I<Automatically using builtin ENGINE implementations>
Here we'll assume we want to load and register all ENGINE implementations
bundled with OpenSSL, such that for any cryptographic algorithm required by
-OpenSSL - if there is an ENGINE that implements it and can be initialise,
+OpenSSL - if there is an ENGINE that implements it and can be initialised,
it should be used. The following code illustrates how this can work;
/* Load all bundled ENGINEs into memory and make them visible */