ASN1_TIME_print() returns 1 if the time is successfully printed out and 0 if
an error occurred (I/O error or invalid time format).
-ASN1_TIME_diff() returns 1 for sucess and 0 for failure. It can fail if the
+ASN1_TIME_diff() returns 1 for success and 0 for failure. It can fail if the
pass ASN1_TIME structure has invalid syntax for example.
=cut
ASN1_TYPE_set() does not return a value.
-ASN1_TYPE_set1() returns 1 for sucess and 0 for failure.
+ASN1_TYPE_set1() returns 1 for success and 0 for failure.
ASN1_TYPE_cmp() returns 0 if the types are identical and non-zero otherwise.
B<str> contains the string to encode B<nconf> or B<cnf> contains
the optional configuration information where additional strings
will be read from. B<nconf> will typically come from a config
-file wherease B<cnf> is obtained from an B<X509V3_CTX> structure
+file whereas B<cnf> is obtained from an B<X509V3_CTX> structure
which will typically be used by X509 v3 certificate extension
functions. B<cnf> or B<nconf> can be set to B<NULL> if no additional
configuration will be used.
FORMAT:BITLIST,BITSTRING:1,5
A more complex example using a config file to produce a
-SEQUENCE consiting of a BOOL an OID and a UTF8String:
+SEQUENCE consisting of a BOOL an OID and a UTF8String:
asn1 = SEQUENCE:seq_section
through the BIO. If it is not then the final block will fail a subsequent
decrypt.
-When decrypting an error on the final block is signalled by a zero
+When decrypting an error on the final block is signaled by a zero
return value from the read operation. A successful decrypt followed
by EOF will also return zero for the final read. BIO_get_cipher_status()
should be called to determine if the decrypt was successful.
flush the write buffer and/or fill the read buffer.
Use the BIO_ctrl_pending(), to find out whether data is buffered in the BIO
-and must be transfered to the network. Use BIO_ctrl_get_read_request() to
+and must be transferred to the network. Use BIO_ctrl_get_read_request() to
find out, how many bytes must be written into the buffer before the
SSL_operation() can successfully be continued.
BIO_set_conn_port() sets the port to B<port>. B<port> can be the
numerical form or a string such as "http". A string will be looked
up first using getservbyname() on the host platform but if that
-fails a standard table of port names will be used. Currently the
-list is http, telnet, socks, https, ssl, ftp, gopher and wais.
+fails a standard table of port names will be used. This internal
+list is http, telnet, socks, https, ssl, ftp, and gopher.
BIO_set_conn_ip() sets the IP address to B<ip> using binary form,
that is four bytes specifying the IP address in big-endian form.
B<filename> and application name B<appname>. If B<filename> is NULL
the standard OpenSSL configuration file is used. If B<appname> is
NULL the standard OpenSSL application name B<openssl_conf> is used.
-The behaviour can be cutomized using B<flags>.
+The behaviour can be customized using B<flags>.
-CONF_modules_load() is idential to CONF_modules_load_file() except it
+CONF_modules_load() is identical to CONF_modules_load_file() except it
reads configuration information from B<cnf>.
=head1 NOTES
EC_GROUP_set_generator sets curve paramaters that must be agreed by all participants using the curve. These
paramaters include the B<generator>, the B<order> and the B<cofactor>. The B<generator> is a well defined point on the
curve chosen for cryptographic operations. Integers used for point multiplications will be between 0 and
-n-1 where n is the B<order>. The B<order> multipied by the B<cofactor> gives the number of points on the curve.
+n-1 where n is the B<order>. The B<order> multiplied by the B<cofactor> gives the number of points on the curve.
EC_GROUP_get0_generator returns the generator for the identified B<group>.
applications would have to explicitly set the named curve form) in OpenSSL
1.1.0 and later the named curve form is the default.
-The point_coversion_form for a curve controls how EC_POINT data is encoded as ASN1 as defined in X9.62 (ECDSA).
+The point_conversion_form for a curve controls how EC_POINT data is encoded as ASN1 as defined in X9.62 (ECDSA).
point_conversion_form_t is an enum defined as follows:
typedef enum {
f(x) = x^m + x^k3 + x^k2 + x^k1 + 1 with m > k3 > k2 > k1 >= 1
The function EC_GROUP_get_basis_type returns a NID identifying whether a trinomial or pentanomial is in use for the field. The
-function EC_GROUP_get_trinomial_basis must only be called where f(x) is of the trinomial form, and returns the value of B<k>. Similary
+function EC_GROUP_get_trinomial_basis must only be called where f(x) is of the trinomial form, and returns the value of B<k>. Similarly
the function EC_GROUP_get_pentanomial_basis must only be called where f(x) is of the pentanomial form, and returns the values of B<k1>,
B<k2> and B<k3> respectively.
A new curve can be constructed by calling EC_GROUP_new, using the implementation provided by B<meth> (see
L<EC_GFp_simple_method(3)|EC_GFp_simple_method(3)>). It is then necessary to call either EC_GROUP_set_curve_GFp or
-EC_GROUP_set_curve_GF2m as appropriate to create a curve defined over Fp or over F2^m respectively.
+EC_GROUP_set_curve_GF2m as appropriate to create a curve defined over Fp or over F2^m respectively.
EC_GROUP_set_curve_GFp sets the curve parameters B<p>, B<a> and B<b> for a curve over Fp stored in B<group>.
EC_group_get_curve_GFp obtains the previously set curve parameters.
EC_GROUP_set_curve_GF2m sets the equivalent curve parameters for a curve over F2^m. In this case B<p> represents
-the irreducible polybnomial - each bit represents a term in the polynomial. Therefore there will either be three
-or five bits set dependant on whether the polynomial is a trinomial or a pentanomial.
+the irreducible polynomial - each bit represents a term in the polynomial. Therefore there will either be three
+or five bits set dependent on whether the polynomial is a trinomial or a pentanomial.
EC_group_get_curve_GF2m obtains the previously set curve parameters.
The functions EC_GROUP_new_curve_GFp and EC_GROUP_new_curve_GF2m are shortcuts for calling EC_GROUP_new and the
=head1 DESCRIPTION
-An EC_KEY represents a public key and (optionaly) an associated private key. A new EC_KEY (with no associated curve) can be constructed by calling EC_KEY_new.
+An EC_KEY represents a public key and (optionally) an associated private key. A new EC_KEY (with no associated curve) can be constructed by calling EC_KEY_new.
The reference count for the newly created EC_KEY is initially set to 1. A curve can be associated with the EC_KEY by calling
EC_KEY_set_group.
The functions EC_KEY_get_conv_form and EC_KEY_set_conv_form get and set the point_conversion_form for the B<key>. For a description
of point_conversion_forms please refer to L<EC_POINT_new(3)|EC_POINT_new(3)>.
-EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitary additional data specific to the
+EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitrary additional data specific to the
elliptic curve scheme being used with the EC_KEY object. This data is treated as a "black box" by the ec library. The data to be stored by EC_KEY_insert_key_method_data is provided in the B<data> parameter, which must have have associated functions for duplicating, freeing and "clear_freeing" the data item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions for duplicating, freeing and "clear_freeing" the data item must be provided again, and they must be the same as they were when the data item was inserted.
EC_KEY_set_flags sets the flags in the B<flags> parameter on the EC_KEY object. Any flags that are already set are left set. The currently defined standard flags are EC_FLAG_NON_FIPS_ALLOW and EC_FLAG_FIPS_CHECKED. In addition there is the flag EC_FLAG_COFACTOR_ECDH which is specific to ECDH and is defined in ecdh.h. EC_KEY_get_flags returns the current flags that are set for this EC_KEY. EC_KEY_clear_flags clears the flags indicated by the B<flags> parameter. All other flags are left in their existing state.
encryption algorithm from a password in the B<data> parameter.
Increasing the B<count> parameter slows down the algorithm which makes it
-harder for an attacker to peform a brute force attack using a large number
+harder for an attacker to perform a brute force attack using a large number
of candidate passwords.
If the total key and IV length is less than the digest length and
D_i = HASH^count(D_(i-1) || data || salt)
-where || denotes concatentaion, D_0 is empty, HASH is the digest
+where || denotes concatenation, D_0 is empty, HASH is the digest
algorithm in use, HASH^1(data) is simply HASH(data), HASH^2(data)
is HASH(HASH(data)) and so on.
EVP_DigestInit_ex() sets up digest context B<ctx> to use a digest
B<type> from ENGINE B<impl>. B<ctx> must be initialized before calling this
-function. B<type> will typically be supplied by a functionsuch as EVP_sha1().
+function. B<type> will typically be supplied by a function such as EVP_sha1().
If B<impl> is NULL then the default implementation of digest B<type> is used.
EVP_DigestUpdate() hashes B<cnt> bytes of data at B<d> into the
EVP_DigestSignUpdate() hashes B<cnt> bytes of data at B<d> into the
signature context B<ctx>. This function can be called several times on the
same B<ctx> to include additional data. This function is currently implemented
-usig a macro.
+using a macro.
EVP_DigestSignFinal() signs the data in B<ctx> places the signature in B<sig>.
If B<sig> is B<NULL> then the maximum size of the output buffer is written to
is used by default.
The EVP_PKEY_CTX_set_rsa_rsa_keygen_bits() macro sets the RSA key length for
-RSA key genration to B<bits>. If not specified 1024 bits is used.
+RSA key generation to B<bits>. If not specified 1024 bits is used.
The EVP_PKEY_CTX_set_rsa_keygen_pubexp() macro sets the public exponent value
for RSA key generation to B<pubexp> currently it should be an odd integer. The
The EVP_PKEY_CTX_new_id() function allocates public key algorithm context
using the algorithm specified by B<id> and ENGINE B<e>. It is normally used
when no B<EVP_PKEY> structure is associated with the operations, for example
-during parameter generation of key genration for some algorithms.
+during parameter generation of key generation for some algorithms.
EVP_PKEY_CTX_dup() duplicates the context B<ctx>.
=head1 DESCRIPTION
The EVP_PKEY_keygen_init() function initializes a public key algorithm
-context using key B<pkey> for a key genration operation.
+context using key B<pkey> for a key generation operation.
The EVP_PKEY_keygen() function performs a key generation operation, the
generated key is written to B<ppkey>.
that parameter. EVP_PKEY_CTX_gen_keygen_info() with a non-negative value for
B<idx> should only be called within the generation callback.
-If the callback returns 0 then the key genration operation is aborted and an
+If the callback returns 0 then the key generation operation is aborted and an
error occurs. This might occur during a time consuming operation where
a user clicks on a "cancel" button.
parameters.
The meaning of the parameters passed to the callback will depend on the
-algorithm and the specifiic implementation of the algorithm. Some might not
+algorithm and the specific implementation of the algorithm. Some might not
give any useful information at all during key or parameter generation. Others
might not even call the callback.
or NID_undef if an error occurred.
OBJ_txt2nid() returns NID corresponding to text string <s>. B<s> can be
-a long name, a short name or the numerical respresentation of an object.
+a long name, a short name or the numerical representation of an object.
OBJ_txt2obj() converts the text string B<s> into an ASN1_OBJECT structure.
If B<no_name> is 0 then long names and short names will be interpreted
the functions OBJ_txt2obj() and OBJ_obj2txt() can process the numerical
form of an OID.
-Some objects are used to reprsent algorithms which do not have a
+Some objects are used to represent algorithms which do not have a
corresponding ASN.1 OBJECT IDENTIFIER encoding (for example no OID currently
exists for a particular algorithm). As a result they B<cannot> be encoded or
decoded as part of ASN.1 structures. Applications can determine if there
PKCS12_create() creates a PKCS#12 structure.
B<pass> is the passphrase to use. B<name> is the B<friendlyName> to use for
-the supplied certific
tate and key. B<pkey> is the private key to include in
+the supplied certificate and key. B<pkey> is the private key to include in
the structure and B<cert> its corresponding certificates. B<ca>, if not B<NULL>
is an optional set of certificates to also include in the structure.
PKCS12 structure.
Either B<pkey>, B<cert> or both can be B<NULL> to indicate that no key or
-certficate is required. In previous versions both had to be present or
+certificate is required. In previous versions both had to be present or
a fatal error is returned.
B<nid_key> or B<nid_cert> can be set to -1 indicating that no encryption
and an iteration count.
Increasing the B<iter> parameter slows down the algorithm which makes it
-harder for an attacker to peform a brute force attack using a large number
+harder for an attacker to perform a brute force attack using a large number
of candidate passwords.
=head1 RETURN VALUES
=head1 DESCRIPTION
PKCS7_sign() creates and returns a PKCS#7 signedData structure. B<signcert> is
-the certificate to sign with, B<pkey> is the corresponsding private key.
+the certificate to sign with, B<pkey> is the corresponding private key.
B<certs> is an optional additional set of certificates to include in the PKCS#7
structure (for example any intermediate CAs in the chain).
parameter.
If B<PKCS7_REUSE_DIGEST> is set then an attempt is made to copy the content
-digest value from the PKCS7 struture: to add a signer to an existing structure.
+digest value from the PKCS7 structure: to add a signer to an existing structure.
An error occurs if a matching digest value cannot be found to copy. The
returned PKCS7 structure will be valid and finalized when this flag is set.
PKCS7_verify() verifies a PKCS#7 signedData structure. B<p7> is the PKCS7
structure to verify. B<certs> is a set of certificates in which to search for
-the signer's certificate. B<store> is a trusted certficate store (used for
+the signer's certificate. B<store> is a trusted certificate store (used for
chain verification). B<indata> is the signed data if the content is not
present in B<p7> (that is it is detached). The content is written to B<out>
if it is not NULL.
and once to output the S/MIME message.
If streaming is performed the content is output in BER format using indefinite
-length constructuted encoding except in the case of signed data with detached
+length constructed encoding except in the case of signed data with detached
content where the content is absent and DER format is used.
=head1 BUGS
legacy functions which have various limitations which make them
of minimal use in practice. They can only find the first matching
entry and will copy the contents of the field verbatim: this can
-be highly confusing if the target is a muticharacter string type
+be highly confusing if the target is a multicharacter string type
like a BMPString or a UTF8String.
For a more general solution X509_NAME_get_index_by_NID() or
X509_STORE_CTX_get_error_depth() returns a non-negative error depth.
-X509_STORE_CTX_get_current_cert() returns the cerificate which caused the
+X509_STORE_CTX_get_current_cert() returns the certificate which caused the
error or B<NULL> if no certificate is relevant to the error.
X509_verify_cert_error_string() returns a human readable error string for
to B<sk>. This is an alternative way of specifying trusted certificates
instead of using an B<X509_STORE>.
-X509_STORE_CTX_set_cert() sets the certificate to be vertified in B<ctx> to
+X509_STORE_CTX_set_cert() sets the certificate to be verified in B<ctx> to
B<x>.
X509_STORE_CTX_set_chain() sets the additional certificate chain used by B<ctx>
used where additional "useful" CRLs are supplied as part of a protocol,
for example in a PKCS#7 structure.
-X509_VERIFY_PARAM *X509_STORE_CTX_get0_param() retrieves an intenal pointer
+X509_VERIFY_PARAM *X509_STORE_CTX_get0_param() retrieves an internal pointer
to the verification parameters associated with B<ctx>.
-X509_STORE_CTX_set0_param() sets the intenal verification parameter pointer
+X509_STORE_CTX_set0_param() sets the internal verification parameter pointer
to B<param>. After this call B<param> should not be used.
X509_STORE_CTX_set_default() looks up and sets the default verification
be suppressed as appropriate when DANE support is added to OpenSSL.
X509_VERIFY_PARAM_add1_host() adds B<name> as an additional reference
-identifer that can match the peer's certificate. Any previous names
+identifier that can match the peer's certificate. Any previous names
set via X509_VERIFY_PARAM_set1_host() or X509_VERIFY_PARAM_add1_host()
are retained, no change is made if B<name> is NULL or empty. When
multiple names are configured, the peer is considered verified when
purposes can be a security risk. Finer control over which extensions are
supported can be performed in the verification callback.
-THe B<X509_V_FLAG_X509_STRICT> flag disables workarounds for some broken
+The B<X509_V_FLAG_X509_STRICT> flag disables workarounds for some broken
certificates and makes the verification strictly apply B<X509> rules.
B<X509_V_FLAG_ALLOW_PROXY_CERTS> enables proxy certificate verification.
B<X509_V_FLAG_POLICY_CHECK> enables certificate policy checking, by default
-no policy checking is peformed. Additional information is sent to the
+no policy checking is performed. Additional information is sent to the
verification callback relating to policy checking.
B<X509_V_FLAG_EXPLICIT_POLICY>, B<X509_V_FLAG_INHIBIT_ANY> and
different keys are disabled. If B<X509_V_FLAG_EXTENDED_CRL_SUPPORT> is set
they are enabled.
-If B<X509_V_FLAG_USE_DELTAS> ise set delta CRLs (if present) are used to
+If B<X509_V_FLAG_USE_DELTAS> is set delta CRLs (if present) are used to
determine certificate status. If not set deltas are ignored.
B<X509_V_FLAG_CHECK_SS_SIGNATURE> enables checking of the root CA self signed
-cerificate signature. By default this check is disabled because it doesn't
+certificate signature. By default this check is disabled because it doesn't
add any additional security but in some cases applications might want to
check the signature anyway. A side effect of not checking the root CA
signature is that disabled or unsupported message digests on the root CA
If set, B<X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS> suppresses support
for "*" as wildcard pattern in labels that have a prefix or suffix,
-such as: "www*" or "*www"; this only aplies to B<X509_check_host>.
+such as: "www*" or "*www"; this only applies to B<X509_check_host>.
If set, B<X509_CHECK_FLAG_MULTI_LABEL_WILDCARDS> allows a "*" that
constitutes the complete label of a DNS name (e.g. "*.example.com")
=head1 NAME
-X509_verify_cert - discover and verify X509 certificte chain
+X509_verify_cert - discover and verify X509 certificate chain
=head1 SYNOPSIS
These functions decode and encode an ASN1 OBJECT IDENTIFIER.
-Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise these behave in a similar way to d2i_X509() and i2d_X509()
described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
=head1 SEE ALSO
These functions decode and encode PKCS#3 DH parameters using the
DHparameter structure described in PKCS#3.
-Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise these behave in a similar way to d2i_X509() and i2d_X509()
described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
=head1 SEE ALSO
B<INTEGER>. If B<write_params> is 1 then a B<SEQUENCE> consisting of the
B<p>, B<q>, B<g> and B<pub_key> respectively fields are encoded.
-The B<DSAPrivateKey> functions also use a non standard structure consiting
+The B<DSAPrivateKey> functions also use a non standard structure consisting
consisting of a SEQUENCE containing the B<p>, B<q>, B<g> and B<pub_key> and
B<priv_key> fields respectively.
These functions decode and encode an B<X509_ALGOR> structure which is
equivalent to the B<AlgorithmIdentifier> structure.
-Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise these behave in a similar way to d2i_X509() and i2d_X509()
described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
=head1 SEE ALSO
These functions decode and encode an X509 CRL (certificate revocation
list).
-Othewise the functions behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise the functions behave in a similar way to d2i_X509() and i2d_X509()
described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
=head1 SEE ALSO
the same as the B<Name> type defined in RFC2459 (and elsewhere) and used
for example in certificate subject and issuer names.
-Othewise the functions behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise the functions behave in a similar way to d2i_X509() and i2d_X509()
described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
=head1 SEE ALSO
These functions decode and encode a PKCS#10 certificate request.
-Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise these behave in a similar way to d2i_X509() and i2d_X509()
described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
=head1 SEE ALSO
These functions decode and encode an X509_SIG structure which is
equivalent to the B<DigestInfo> structure defined in PKCS#1 and PKCS#7.
-Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise these behave in a similar way to d2i_X509() and i2d_X509()
described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
=head1 SEE ALSO
manipulating B<EC_GROUP> objects are described in L<EC_GROUP_copy(3)|EC_GROUP_copy(3)>.
Functions for creating, destroying and manipulating B<EC_POINT> objects are explained in L<EC_POINT_new(3)|EC_POINT_new(3)>,
-whilst functions for performing mathematical operations and tests on B<EC_POINTs> are coverd in L<EC_POINT_add(3)|EC_POINT_add(3)>.
+whilst functions for performing mathematical operations and tests on B<EC_POINTs> are covered in L<EC_POINT_add(3)|EC_POINT_add(3)>.
For working with private and public keys refer to L<EC_KEY_new(3)|EC_KEY_new(3)>. Implementations are covered in
L<EC_GFp_simple_method(3)|EC_GFp_simple_method(3)>.
by applications, administrations, users, etc. These can support arbitrary
operations via ENGINE_ctrl(), including passing to and/or from the control
commands data of any arbitrary type. These commands are supported in the
-discovery mechanisms simply to allow applications determinie if an ENGINE
+discovery mechanisms simply to allow applications to determine if an ENGINE
supports certain specific commands it might want to use (eg. application "foo"
might query various ENGINEs to see if they implement "FOO_GET_VENDOR_LOGO_GIF" -
and ENGINE could therefore decide whether or not to support this "foo"-specific
=head1 DESCRIPTION
-When a call to the OpenSSL library fails, this is usually signalled
+When a call to the OpenSSL library fails, this is usually signaled
by the return value, and an error code is stored in an error queue
associated with the current thread. The B<err> library provides
functions to obtain these error codes and textual error messages.
-Fingerprints for Signing Relases
+Fingerprints for Signing Releases
OpenSSL releases are signed with PGP/GnuPG keys. This file contains
the fingerprints of team members who are "authorized" to sign the
projects / openssl.git / commitdiff