diff options
author | Rich Salz <rsalz@openssl.org> | 2015-07-31 12:34:24 -0400 |
---|---|---|
committer | Rich Salz <rsalz@openssl.org> | 2015-07-31 12:34:24 -0400 |
commit | b68fa4d19ee68640f18d8eea4249eb0191a07694 (patch) | |
tree | fe6579d29f5c283453bf2aae0f69afecded9af08 /doc/crypto | |
parent | 602af7d01da82dc6c45946572f531bcbe9ebbf47 (diff) |
Various doc fixes from GH pull requests
Thanks, folks!
348 Benjamin Kaduk
317 Christian Brueffer
254 Erik Tews
253 Erik Tews
219 Carl Mehner
155 (ghost)
95 mancha
51 DominikNeubauer
(Manually picked from 59c554b36e39256ac2cfc34dca052453e10c6d9c)
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Diffstat (limited to 'doc/crypto')
-rw-r--r-- | doc/crypto/EVP_EncryptInit.pod | 2 | ||||
-rw-r--r-- | doc/crypto/EVP_SealInit.pod | 2 | ||||
-rw-r--r-- | doc/crypto/engine.pod | 10 |
3 files changed, 7 insertions, 7 deletions
diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod index fb6036f959..c69e6a6d70 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 7d793e19ef..19112a542d 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/engine.pod b/doc/crypto/engine.pod index f5ab1c3e50..48741ee306 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 */ |