summaryrefslogtreecommitdiff
path: root/doc/crypto/EVP_PKEY_verify_recover.pod
diff options
context:
space:
mode:
Diffstat (limited to 'doc/crypto/EVP_PKEY_verify_recover.pod')
-rw-r--r--doc/crypto/EVP_PKEY_verify_recover.pod6
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/crypto/EVP_PKEY_verify_recover.pod b/doc/crypto/EVP_PKEY_verify_recover.pod
index 399120e..23a28a9 100644
--- a/doc/crypto/EVP_PKEY_verify_recover.pod
+++ b/doc/crypto/EVP_PKEY_verify_recover.pod
@@ -29,7 +29,7 @@ B<rout> and the amount of data written to B<routlen>.
=head1 NOTES
Normally an application is only interested in whether a signature verification
-operation is successful in those cases the EVP_verify() function should be
+operation is successful in those cases the EVP_verify() function should be
used.
Sometimes however it is useful to obtain the data originally signed using a
@@ -58,7 +58,7 @@ Recover digest originally signed using PKCS#1 and SHA256 digest:
EVP_PKEY_CTX *ctx;
unsigned char *rout, *sig;
- size_t routlen, siglen;
+ size_t routlen, siglen;
EVP_PKEY *verify_key;
/* NB: assumes verify_key, sig and siglen are already set up
* and that verify_key is an RSA public key
@@ -94,7 +94,7 @@ L<EVP_PKEY_encrypt(3)|EVP_PKEY_encrypt(3)>,
L<EVP_PKEY_decrypt(3)|EVP_PKEY_decrypt(3)>,
L<EVP_PKEY_sign(3)|EVP_PKEY_sign(3)>,
L<EVP_PKEY_verify(3)|EVP_PKEY_verify(3)>,
-L<EVP_PKEY_derive(3)|EVP_PKEY_derive(3)>
+L<EVP_PKEY_derive(3)|EVP_PKEY_derive(3)>
=head1 HISTORY