diff options
Diffstat (limited to 'doc/man7')
| -rw-r--r-- | doc/man7/EVP_KDF-KRB5KDF.pod | 2 | ||||
| -rw-r--r-- | doc/man7/EVP_PKEY-DH.pod | 2 | ||||
| -rw-r--r-- | doc/man7/EVP_PKEY-X25519.pod | 2 | ||||
| -rw-r--r-- | doc/man7/evp.pod | 12 | ||||
| -rw-r--r-- | doc/man7/provider-base.pod | 4 |
5 files changed, 11 insertions, 11 deletions
diff --git a/doc/man7/EVP_KDF-KRB5KDF.pod b/doc/man7/EVP_KDF-KRB5KDF.pod index 192ca3f34b..29a8c0f7b8 100644 --- a/doc/man7/EVP_KDF-KRB5KDF.pod +++ b/doc/man7/EVP_KDF-KRB5KDF.pod @@ -48,7 +48,7 @@ A context for KRB5KDF can be obtained by calling: The output length of the KRB5KDF derivation is specified via the I<keylen> parameter to the L<EVP_KDF_derive(3)> function, and MUST match the key -length for the chosen cipher or an error is returned. Moreover the +length for the chosen cipher or an error is returned. Moreover, the constant's length must not exceed the block size of the cipher. Since the KRB5KDF output length depends on the chosen cipher, calling L<EVP_KDF_size(3)> to obtain the requisite length returns the correct length diff --git a/doc/man7/EVP_PKEY-DH.pod b/doc/man7/EVP_PKEY-DH.pod index f640753bfe..45d7c6ed5f 100644 --- a/doc/man7/EVP_PKEY-DH.pod +++ b/doc/man7/EVP_PKEY-DH.pod @@ -105,7 +105,7 @@ For "group" this can be any one of 2048, 3072, 4096, 6144 or 8192. =item "priv_len" (B<OSSL_PKEY_PARAM_DH_PRIV_LEN>) <integer> An optional value to set the maximum length of the generated private key. -The default valure used if this is not set is the maximum value of +The default value used if this is not set is the maximum value of BN_num_bits(I<q>)). The minimum value that this can be set to is 2 * s. Where s is the security strength of the key which has values of 112, 128, 152, 176 and 200 for key sizes of 2048, 3072, 4096, 6144 and 8192. diff --git a/doc/man7/EVP_PKEY-X25519.pod b/doc/man7/EVP_PKEY-X25519.pod index 2937f247f5..63760389c9 100644 --- a/doc/man7/EVP_PKEY-X25519.pod +++ b/doc/man7/EVP_PKEY-X25519.pod @@ -29,7 +29,7 @@ support the following. =item "group" (B<OSSL_PKEY_PARAM_GROUP_NAME>) <UTF8 string> This is only supported by X25519 and X448. The group name must be "x25519" or -"x448" repsectively for those algorithms. This is only present for consistency +"x448" respectively for those algorithms. This is only present for consistency with other key exchange algorithms and is typically not needed. =item "pub" (B<OSSL_PKEY_PARAM_PUB_KEY>) <octet string> diff --git a/doc/man7/evp.pod b/doc/man7/evp.pod index 3e810f3d3f..2a3a1a91dc 100644 --- a/doc/man7/evp.pod +++ b/doc/man7/evp.pod @@ -25,7 +25,7 @@ functions. Symmetric encryption is available with the L<B<EVP_Encrypt>I<XXX>|EVP_EncryptInit(3)> functions. The L<B<EVP_Digest>I<XXX>|EVP_DigestInit(3)> functions provide message digests. -The B<EVP_PKEY>I<XXX> functions provide a high level interface to +The B<EVP_PKEY>I<XXX> functions provide a high-level interface to asymmetric algorithms. To create a new EVP_PKEY see L<EVP_PKEY_new(3)>. EVP_PKEYs can be associated with a private key of a particular algorithm by using the functions @@ -43,7 +43,7 @@ The EVP_PKEY functions support the full range of asymmetric algorithm operations =item For signing and verifying see L<EVP_PKEY_sign(3)>, L<EVP_PKEY_verify(3)> and L<EVP_PKEY_verify_recover(3)>. However, note that -these functions do not perform a digest of the data to be signed. Therefore +these functions do not perform a digest of the data to be signed. Therefore, normally you would use the L<EVP_DigestSignInit(3)> functions for this purpose. @@ -72,12 +72,12 @@ as defaults, then the various EVP functions will automatically use those implementations automatically in preference to built in software implementations. For more information, consult the engine(3) man page. -Although low level algorithm specific functions exist for many algorithms +Although low-level algorithm specific functions exist for many algorithms their use is discouraged. They cannot be used with an ENGINE and ENGINE -versions of new algorithms cannot be accessed using the low level functions. +versions of new algorithms cannot be accessed using the low-level functions. Also makes code harder to adapt to new algorithms and some options are not -cleanly supported at the low level and some operations are more efficient -using the high level interface. +cleanly supported at the low-level and some operations are more efficient +using the high-level interface. =head1 SEE ALSO diff --git a/doc/man7/provider-base.pod b/doc/man7/provider-base.pod index 35e9f6f614..d61645f961 100644 --- a/doc/man7/provider-base.pod +++ b/doc/man7/provider-base.pod @@ -237,7 +237,7 @@ it a set of B<OSSL_PARAM>s and the caller supplied argument I<arg>. The B<OSSL_PARAM>s should provide details about the capability with the name given in the I<capability> argument relevant for the provider context I<provctx>. If a provider supports multiple capabilities with the given name then it may call the -callback multipe times (one for each capability). Capabilities can be useful for +callback multiple times (one for each capability). Capabilities can be useful for describing the services that a provider can offer. For further details see the L</CAPABILITIES> section below. It should return 1 on success or 0 on error. @@ -346,7 +346,7 @@ L<OSSL_PARAM_int(3)>. =head1 CAPABILITIES -Capabilties describe some of the services that a provider can offer. +Capabilities describe some of the services that a provider can offer. Applications can query the capabilities to discover those services. =head3 "TLS-GROUP" Capability |