summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDr. Stephen Henson <steve@openssl.org>2003-01-26 13:38:56 +0000
committerDr. Stephen Henson <steve@openssl.org>2003-01-26 13:38:56 +0000
commitda45180de49b60be97ae0d5e574864417d7ddebd (patch)
tree2c3a13f4822769945a6ddd1f5e28f405695236cf
parent82516e3baf2870cc9f4cece522dd6487bc96de38 (diff)
Correct EVP_SealInit() documentation, iv is an output
parameter.
-rw-r--r--doc/crypto/EVP_SealInit.pod26
1 files changed, 16 insertions, 10 deletions
diff --git a/doc/crypto/EVP_SealInit.pod b/doc/crypto/EVP_SealInit.pod
index 25ef07f7c7..b5e477e294 100644
--- a/doc/crypto/EVP_SealInit.pod
+++ b/doc/crypto/EVP_SealInit.pod
@@ -18,22 +18,28 @@ EVP_SealInit, EVP_SealUpdate, EVP_SealFinal - EVP envelope encryption
=head1 DESCRIPTION
The EVP envelope routines are a high level interface to envelope
-encryption. They generate a random key and then "envelope" it by
-using public key encryption. Data can then be encrypted using this
-key.
+encryption. They generate a random key and IV (if required) then
+"envelope" it by using public key encryption. Data can then be
+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 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
-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 must
-contain enough room for the corresponding encrypted key: that is
+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
+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
+must contain enough room for the corresponding encrypted key: that is
B<ek[i]> must have room for B<EVP_PKEY_size(pubk[i])> bytes. The actual
size of each encrypted secret key is written to the array B<ekl>. B<pubk> is
an array of B<npubk> public keys.
+The B<iv> parameter is a buffer where the generated IV is written to. It must
+contain enough room for the corresponding cipher's IV, as determined by (for
+example) EVP_CIPHER_iv_length(type).
+
+If the cipher does not require an IV then the B<iv> parameter is ignored
+and can be B<NULL>.
+
EVP_SealUpdate() and EVP_SealFinal() have exactly the same properties
as the EVP_EncryptUpdate() and EVP_EncryptFinal() routines, as
documented on the L<EVP_EncryptInit(3)|EVP_EncryptInit(3)> manual