summaryrefslogtreecommitdiff
path: root/src/lib/libssl/src/doc/crypto/EVP_SealInit.pod
diff options
context:
space:
mode:
Diffstat (limited to 'src/lib/libssl/src/doc/crypto/EVP_SealInit.pod')
-rw-r--r--src/lib/libssl/src/doc/crypto/EVP_SealInit.pod26
1 files changed, 16 insertions, 10 deletions
diff --git a/src/lib/libssl/src/doc/crypto/EVP_SealInit.pod b/src/lib/libssl/src/doc/crypto/EVP_SealInit.pod
index 25ef07f7c7..b5e477e294 100644
--- a/src/lib/libssl/src/doc/crypto/EVP_SealInit.pod
+++ b/src/lib/libssl/src/doc/crypto/EVP_SealInit.pod
@@ -18,22 +18,28 @@ EVP_SealInit, EVP_SealUpdate, EVP_SealFinal - EVP envelope encryption
18=head1 DESCRIPTION 18=head1 DESCRIPTION
19 19
20The EVP envelope routines are a high level interface to envelope 20The EVP envelope routines are a high level interface to envelope
21encryption. They generate a random key and then "envelope" it by 21encryption. They generate a random key and IV (if required) then
22using public key encryption. Data can then be encrypted using this 22"envelope" it by using public key encryption. Data can then be
23key. 23encrypted using this key.
24 24
25EVP_SealInit() initializes a cipher context B<ctx> for encryption 25EVP_SealInit() initializes a cipher context B<ctx> for encryption
26with cipher B<type> using a random secret key and IV supplied in 26with cipher B<type> using a random secret key and IV. B<type> is normally
27the B<iv> parameter. B<type> is normally supplied by a function such 27supplied by a function such as EVP_des_cbc(). The secret key is encrypted
28as EVP_des_cbc(). The secret key is encrypted using one or more public 28using one or more public keys, this allows the same encrypted data to be
29keys, this allows the same encrypted data to be decrypted using any 29decrypted using any of the corresponding private keys. B<ek> is an array of
30of the corresponding private keys. B<ek> is an array of buffers where 30buffers where the public key encrypted secret key will be written, each buffer
31the public key encrypted secret key will be written, each buffer must 31must contain enough room for the corresponding encrypted key: that is
32contain enough room for the corresponding encrypted key: that is
33B<ek[i]> must have room for B<EVP_PKEY_size(pubk[i])> bytes. The actual 32B<ek[i]> must have room for B<EVP_PKEY_size(pubk[i])> bytes. The actual
34size of each encrypted secret key is written to the array B<ekl>. B<pubk> is 33size of each encrypted secret key is written to the array B<ekl>. B<pubk> is
35an array of B<npubk> public keys. 34an array of B<npubk> public keys.
36 35
36The B<iv> parameter is a buffer where the generated IV is written to. It must
37contain enough room for the corresponding cipher's IV, as determined by (for
38example) EVP_CIPHER_iv_length(type).
39
40If the cipher does not require an IV then the B<iv> parameter is ignored
41and can be B<NULL>.
42
37EVP_SealUpdate() and EVP_SealFinal() have exactly the same properties 43EVP_SealUpdate() and EVP_SealFinal() have exactly the same properties
38as the EVP_EncryptUpdate() and EVP_EncryptFinal() routines, as 44as the EVP_EncryptUpdate() and EVP_EncryptFinal() routines, as
39documented on the L<EVP_EncryptInit(3)|EVP_EncryptInit(3)> manual 45documented on the L<EVP_EncryptInit(3)|EVP_EncryptInit(3)> manual