From a14858a22f164b5accc4bd192a5d3de21d88e3d1 Mon Sep 17 00:00:00 2001 From: marha Date: Sun, 19 Oct 2014 11:31:33 +0200 Subject: Update to openssl-1.0.1j --- openssl/doc/apps/c_rehash.pod | 81 +++++++++++++++++++ openssl/doc/apps/dgst.pod | 68 ++++++++++++---- openssl/doc/crypto/BIO_s_accept.pod | 4 +- openssl/doc/crypto/CMS_add1_signer.pod | 101 ++++++++++++++++++++++++ openssl/doc/crypto/CMS_sign_add1_signer.pod | 101 ------------------------ openssl/doc/crypto/EVP_DigestInit.pod | 30 ++++--- openssl/doc/crypto/EVP_DigestVerifyInit.pod | 4 +- openssl/doc/crypto/EVP_EncryptInit.pod | 56 ++++++------- openssl/doc/crypto/EVP_PKEY_set1_RSA.pod | 8 +- openssl/doc/crypto/EVP_PKEY_sign.pod | 20 +++-- openssl/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod | 15 ++-- 11 files changed, 307 insertions(+), 181 deletions(-) create mode 100644 openssl/doc/apps/c_rehash.pod create mode 100644 openssl/doc/crypto/CMS_add1_signer.pod delete mode 100644 openssl/doc/crypto/CMS_sign_add1_signer.pod (limited to 'openssl/doc') diff --git a/openssl/doc/apps/c_rehash.pod b/openssl/doc/apps/c_rehash.pod new file mode 100644 index 000000000..c564e8631 --- /dev/null +++ b/openssl/doc/apps/c_rehash.pod @@ -0,0 +1,81 @@ +=pod + +=for comment +Original text by James Westby, contributed under the OpenSSL license. + +=head1 NAME + +c_rehash - Create symbolic links to files named by the hash values + +=head1 SYNOPSIS + +B +[ I...] + +=head1 DESCRIPTION + +B scans directories and calculates a hash value of each C<.pem> +file in the specified directory list and creates symbolic links +for each file, where the name of the link is the hash value. +This utility is useful as many programs that use OpenSSL require +directories to be set up like this in order to find certificates. + +If any directories are named on the command line, then those are +processed in turn. If not, then the B environment variable +is consulted; this shold be a colon-separated list of directories, +like the Unix B variable. +If that is not set then the default directory (installation-specific +but often B) is processed. + +In order for a directory to be processed, the user must have write +permissions on that directory, otherwise it will be skipped. +The links created are of the form C, where each B +is a hexadecimal character and B is a single decimal digit. +When processing a directory, B will first remove all links +that have a name in that syntax. If you have links in that format +used for other purposes, they will be removed. +Hashes for CRL's look similar except the letter B appears after +the period, like this: C. + +Multiple objects may have the same hash; they will be indicated by +incrementing the B value. Duplicates are found by comparing the +full SHA-1 fingerprint. A warning will be displayed if a duplicate +is found. + +A warning will also be displayed if there are B<.pem> files that +cannot be parsed as either a certificate or a CRL. + +The program uses the B program to compute the hashes and +fingerprints. If not found in the user's B, then set the +B environment variable to the full pathname. +Any program can be used, it will be invoked as follows for either +a certificate or CRL: + + $OPENSSL x509 -hash -fingerprint -noout -in FFFFFF + $OPENSSL crl -hash -fingerprint -noout -in FFFFFF + +where B is the filename. It must output the hash of the +file on the first line, and the fingerprint on the second, +optionally prefixed with some text and an equals sign. + +=head1 ENVIRONMENT + +=over + +=item B + +The path to an executable to use to generate hashes and +fingerprints (see above). + +=item B + +Colon separated list of directories to operate on. +Ignored if directories are listed on the command line. + +=back + +=head1 SEE ALSO + +L, +L. +L. diff --git a/openssl/doc/apps/dgst.pod b/openssl/doc/apps/dgst.pod index b035edf08..2414c5337 100644 --- a/openssl/doc/apps/dgst.pod +++ b/openssl/doc/apps/dgst.pod @@ -2,16 +2,17 @@ =head1 NAME -dgst, md5, md4, md2, sha1, sha, mdc2, ripemd160 - message digests +dgst, sha, sha1, mdc2, ripemd160, sha224, sha256, sha384, sha512, md2, md4, md5, dss1 - message digests =head1 SYNOPSIS B B -[B<-md5|-md4|-md2|-sha1|-sha|-mdc2|-ripemd160|-dss1>] +[B<-sha|-sha1|-mdc2|-ripemd160|-sha224|-sha256|-sha384|-sha512|-md2|-md4|-md5|-dss1>] [B<-c>] [B<-d>] [B<-hex>] [B<-binary>] +[B<-r>] [B<-out filename>] [B<-sign filename>] [B<-keyform arg>] @@ -20,17 +21,19 @@ B B [B<-prverify filename>] [B<-signature filename>] [B<-hmac key>] +[B<-non-fips-allow>] +[B<-fips-fingerprint>] [B] -[B] -[B<-c>] -[B<-d>] -[B] +B +[I] +[B<...>] =head1 DESCRIPTION The digest functions output the message digest of a supplied file or files -in hexadecimal form. They can also be used for digital signing and verification. +in hexadecimal. The digest functions also generate and verify digital +signatures using message digests. =head1 OPTIONS @@ -48,12 +51,17 @@ print out BIO debugging information. =item B<-hex> digest is to be output as a hex dump. This is the default case for a "normal" -digest as opposed to a digital signature. +digest as opposed to a digital signature. See NOTES below for digital +signatures using B<-hex>. =item B<-binary> output the digest or signature in binary form. +=item B<-r> + +output the digest in the "coreutils" format used by programs like B. + =item B<-out filename> filename to output to, or standard output by default. @@ -64,8 +72,8 @@ digitally sign the digest using the private key in "filename". =item B<-keyform arg> -Specifies the key format to sign digest with. Only PEM and ENGINE -formats are supported by the B command. +Specifies the key format to sign digest with. The DER, PEM, P12, +and ENGINE formats are supported. =item B<-engine id> @@ -117,7 +125,7 @@ Following options are supported by both by B and B: =over 8 =item B - + Specifies MAC key as alphnumeric string (use if key contain printable characters only). String length must conform to any restrictions of the MAC algorithm for example exactly 32 chars for gost-mac. @@ -138,6 +146,15 @@ Multiple files can be specified separated by a OS-dependent character. The separator is B<;> for MS-Windows, B<,> for OpenVMS, and B<:> for all others. +=item B<-non-fips-allow> + +enable use of non-FIPS algorithms such as MD5 even in FIPS mode. + +=item B<-fips-fingerprint> + +compute HMAC using a specific key +for certain OpenSSL-FIPS operations. + =item B file or files to digest. If no files are specified then standard input is @@ -145,18 +162,41 @@ used. =back + +=head1 EXAMPLES + +To create a hex-encoded message digest of a file: + openssl dgst -md5 -hex file.txt + +To sign a file using SHA-256 with binary file output: + openssl dgst -sha256 -sign privatekey.pem -out signature.sign file.txt + +To verify a signature: + openssl dgst -sha256 -verify publickey.pem \ + -signature signature.sign \ + file.txt + + =head1 NOTES The digest of choice for all new applications is SHA1. Other digests are however still widely used. -If you wish to sign or verify data using the DSA algorithm then the dss1 -digest must be used. +When signing a file, B will automatically determine the algorithm +(RSA, ECC, etc) to use for signing based on the private key's ASN.1 info. +When verifying signatures, it only handles the RSA, DSA, or ECDSA signature +itself, not the related data to identify the signer and algorithm used in +formats such as x.509, CMS, and S/MIME. A source of random numbers is required for certain signing algorithms, in -particular DSA. +particular ECDSA and DSA. The signing and verify options should only be used if a single file is being signed or verified. +Hex signatures cannot be verified using B. Instead, use "xxd -r" +or similar program to transform the hex signature into a binary signature +prior to verification. + + =cut diff --git a/openssl/doc/crypto/BIO_s_accept.pod b/openssl/doc/crypto/BIO_s_accept.pod index 7b63e4621..b80b6ae48 100644 --- a/openssl/doc/crypto/BIO_s_accept.pod +++ b/openssl/doc/crypto/BIO_s_accept.pod @@ -59,8 +59,8 @@ the accept socket. See L BIO_set_accept_port() uses the string B to set the accept port. The port is represented as a string of the form "host:port", where "host" is the interface to use and "port" is the port. -Either or both values can be "*" which is interpreted as meaning -any interface or port respectively. "port" has the same syntax +The host can be can be "*" which is interpreted as meaning +any interface; "port" has the same syntax as the port specified in BIO_set_conn_port() for connect BIOs, that is it can be a numerical port string or a string to lookup using getservbyname() and a string table. diff --git a/openssl/doc/crypto/CMS_add1_signer.pod b/openssl/doc/crypto/CMS_add1_signer.pod new file mode 100644 index 000000000..a055b8269 --- /dev/null +++ b/openssl/doc/crypto/CMS_add1_signer.pod @@ -0,0 +1,101 @@ +=pod + +=head1 NAME + + CMS_add1_signer, CMS_SignerInfo_sign - add a signer to a CMS_ContentInfo signed data structure. + +=head1 SYNOPSIS + + #include + + CMS_SignerInfo *CMS_add1_signer(CMS_ContentInfo *cms, X509 *signcert, EVP_PKEY *pkey, const EVP_MD *md, unsigned int flags); + + int CMS_SignerInfo_sign(CMS_SignerInfo *si); + + +=head1 DESCRIPTION + +CMS_add1_signer() adds a signer with certificate B and private +key B using message digest B to CMS_ContentInfo SignedData +structure B. + +The CMS_ContentInfo structure should be obtained from an initial call to +CMS_sign() with the flag B set or in the case or re-signing a +valid CMS_ContentInfo SignedData structure. + +If the B parameter is B then the default digest for the public +key algorithm will be used. + +Unless the B flag is set the returned CMS_ContentInfo +structure is not complete and must be finalized either by streaming (if +applicable) or a call to CMS_final(). + +The CMS_SignerInfo_sign() function will explicitly sign a CMS_SignerInfo +structure, its main use is when B and B flags +are both set. + +=head1 NOTES + +The main purpose of CMS_add1_signer() is to provide finer control +over a CMS signed data structure where the simpler CMS_sign() function defaults +are not appropriate. For example if multiple signers or non default digest +algorithms are needed. New attributes can also be added using the returned +CMS_SignerInfo structure and the CMS attribute utility functions or the +CMS signed receipt request functions. + +Any of the following flags (ored together) can be passed in the B +parameter. + +If B is set then an attempt is made to copy the content +digest value from the CMS_ContentInfo structure: to add a signer to an existing +structure. An error occurs if a matching digest value cannot be found to copy. +The returned CMS_ContentInfo structure will be valid and finalized when this +flag is set. + +If B is set in addition to B then the +CMS_SignerInfo structure will not be finalized so additional attributes +can be added. In this case an explicit call to CMS_SignerInfo_sign() is +needed to finalize it. + +If B is set the signer's certificate will not be included in the +CMS_ContentInfo structure, the signer's certificate must still be supplied in +the B parameter though. This can reduce the size of the signature if +the signers certificate can be obtained by other means: for example a +previously signed message. + +The SignedData structure includes several CMS signedAttributes including the +signing time, the CMS content type and the supported list of ciphers in an +SMIMECapabilities attribute. If B is set then no signedAttributes +will be used. If B is set then just the SMIMECapabilities are +omitted. + +OpenSSL will by default identify signing certificates using issuer name +and serial number. If B is set it will use the subject key +identifier value instead. An error occurs if the signing certificate does not +have a subject key identifier extension. + +If present the SMIMECapabilities attribute indicates support for the following +algorithms in preference order: 256 bit AES, Gost R3411-94, Gost 28147-89, 192 +bit AES, 128 bit AES, triple DES, 128 bit RC2, 64 bit RC2, DES and 40 bit RC2. +If any of these algorithms is not available then it will not be included: for example the GOST algorithms will not be included if the GOST ENGINE is +not loaded. + +CMS_add1_signer() returns an internal pointer to the CMS_SignerInfo +structure just added, this can be used to set additional attributes +before it is finalized. + +=head1 RETURN VALUES + +CMS_add1_signer() returns an internal pointer to the CMS_SignerInfo +structure just added or NULL if an error occurs. + +=head1 SEE ALSO + +L, L, +L, + +=head1 HISTORY + +CMS_add1_signer() was added to OpenSSL 0.9.8 + +=cut diff --git a/openssl/doc/crypto/CMS_sign_add1_signer.pod b/openssl/doc/crypto/CMS_sign_add1_signer.pod deleted file mode 100644 index bda3ca2ad..000000000 --- a/openssl/doc/crypto/CMS_sign_add1_signer.pod +++ /dev/null @@ -1,101 +0,0 @@ -=pod - -=head1 NAME - - CMS_sign_add1_signer, CMS_SignerInfo_sign - add a signer to a CMS_ContentInfo signed data structure. - -=head1 SYNOPSIS - - #include - - CMS_SignerInfo *CMS_sign_add1_signer(CMS_ContentInfo *cms, X509 *signcert, EVP_PKEY *pkey, const EVP_MD *md, unsigned int flags); - - int CMS_SignerInfo_sign(CMS_SignerInfo *si); - - -=head1 DESCRIPTION - -CMS_sign_add1_signer() adds a signer with certificate B and private -key B using message digest B to CMS_ContentInfo SignedData -structure B. - -The CMS_ContentInfo structure should be obtained from an initial call to -CMS_sign() with the flag B set or in the case or re-signing a -valid CMS_ContentInfo SignedData structure. - -If the B parameter is B then the default digest for the public -key algorithm will be used. - -Unless the B flag is set the returned CMS_ContentInfo -structure is not complete and must be finalized either by streaming (if -applicable) or a call to CMS_final(). - -The CMS_SignerInfo_sign() function will explicitly sign a CMS_SignerInfo -structure, its main use is when B and B flags -are both set. - -=head1 NOTES - -The main purpose of CMS_sign_add1_signer() is to provide finer control -over a CMS signed data structure where the simpler CMS_sign() function defaults -are not appropriate. For example if multiple signers or non default digest -algorithms are needed. New attributes can also be added using the returned -CMS_SignerInfo structure and the CMS attribute utility functions or the -CMS signed receipt request functions. - -Any of the following flags (ored together) can be passed in the B -parameter. - -If B is set then an attempt is made to copy the content -digest value from the CMS_ContentInfo structure: to add a signer to an existing -structure. An error occurs if a matching digest value cannot be found to copy. -The returned CMS_ContentInfo structure will be valid and finalized when this -flag is set. - -If B is set in addition to B then the -CMS_SignerInfo structure will not be finalized so additional attributes -can be added. In this case an explicit call to CMS_SignerInfo_sign() is -needed to finalize it. - -If B is set the signer's certificate will not be included in the -CMS_ContentInfo structure, the signer's certificate must still be supplied in -the B parameter though. This can reduce the size of the signature if -the signers certificate can be obtained by other means: for example a -previously signed message. - -The SignedData structure includes several CMS signedAttributes including the -signing time, the CMS content type and the supported list of ciphers in an -SMIMECapabilities attribute. If B is set then no signedAttributes -will be used. If B is set then just the SMIMECapabilities are -omitted. - -OpenSSL will by default identify signing certificates using issuer name -and serial number. If B is set it will use the subject key -identifier value instead. An error occurs if the signing certificate does not -have a subject key identifier extension. - -If present the SMIMECapabilities attribute indicates support for the following -algorithms in preference order: 256 bit AES, Gost R3411-94, Gost 28147-89, 192 -bit AES, 128 bit AES, triple DES, 128 bit RC2, 64 bit RC2, DES and 40 bit RC2. -If any of these algorithms is not available then it will not be included: for example the GOST algorithms will not be included if the GOST ENGINE is -not loaded. - -CMS_sign_add1_signer() returns an internal pointer to the CMS_SignerInfo -structure just added, this can be used to set additional attributes -before it is finalized. - -=head1 RETURN VALUES - -CMS_sign1_add_signers() returns an internal pointer to the CMS_SignerInfo -structure just added or NULL if an error occurs. - -=head1 SEE ALSO - -L, L, -L, - -=head1 HISTORY - -CMS_sign_add1_signer() was added to OpenSSL 0.9.8 - -=cut diff --git a/openssl/doc/crypto/EVP_DigestInit.pod b/openssl/doc/crypto/EVP_DigestInit.pod index 310c65eb3..ac526bb6d 100644 --- a/openssl/doc/crypto/EVP_DigestInit.pod +++ b/openssl/doc/crypto/EVP_DigestInit.pod @@ -26,13 +26,13 @@ EVP digest routines int EVP_MD_CTX_cleanup(EVP_MD_CTX *ctx); void EVP_MD_CTX_destroy(EVP_MD_CTX *ctx); - int EVP_MD_CTX_copy_ex(EVP_MD_CTX *out,const EVP_MD_CTX *in); + int EVP_MD_CTX_copy_ex(EVP_MD_CTX *out,const EVP_MD_CTX *in); int EVP_DigestInit(EVP_MD_CTX *ctx, const EVP_MD *type); int EVP_DigestFinal(EVP_MD_CTX *ctx, unsigned char *md, unsigned int *s); - int EVP_MD_CTX_copy(EVP_MD_CTX *out,EVP_MD_CTX *in); + int EVP_MD_CTX_copy(EVP_MD_CTX *out,EVP_MD_CTX *in); #define EVP_MAX_MD_SIZE 64 /* SHA512 */ @@ -136,10 +136,10 @@ reasons. EVP_md2(), EVP_md5(), EVP_sha(), EVP_sha1(), EVP_sha224(), EVP_sha256(), EVP_sha384(), EVP_sha512(), EVP_mdc2() and EVP_ripemd160() return B structures for the MD2, MD5, SHA, SHA1, SHA224, SHA256, SHA384, SHA512, MDC2 -and RIPEMD160 digest algorithms respectively. +and RIPEMD160 digest algorithms respectively. EVP_dss() and EVP_dss1() return B structures for SHA and SHA1 digest -algorithms but using DSS (DSA) for the signature algorithm. Note: there is +algorithms but using DSS (DSA) for the signature algorithm. Note: there is no need to use these pseudo-digests in OpenSSL 1.0.0 and later, they are however retained for compatibility. @@ -177,21 +177,21 @@ The B interface to message digests should almost always be used in preference to the low level interfaces. This is because the code then becomes transparent to the digest used and much more flexible. -New applications should use the SHA2 digest algorithms such as SHA256. +New applications should use the SHA2 digest algorithms such as SHA256. The other digest algorithms are still in common use. For most applications the B parameter to EVP_DigestInit_ex() will be set to NULL to use the default digest implementation. -The functions EVP_DigestInit(), EVP_DigestFinal() and EVP_MD_CTX_copy() are +The functions EVP_DigestInit(), EVP_DigestFinal() and EVP_MD_CTX_copy() are obsolete but are retained to maintain compatibility with existing code. New -applications should use EVP_DigestInit_ex(), EVP_DigestFinal_ex() and +applications should use EVP_DigestInit_ex(), EVP_DigestFinal_ex() and EVP_MD_CTX_copy_ex() because they can efficiently reuse a digest context instead of initializing and cleaning it up on each call and allow non default implementations of digests to be specified. In OpenSSL 0.9.7 and later if digest contexts are not cleaned up after use -memory leaks will occur. +memory leaks will occur. Stack allocation of EVP_MD_CTX structures is common, for example: @@ -245,15 +245,19 @@ digest name passed on the command line. EVP_MD_CTX_destroy(mdctx); printf("Digest is: "); - for(i = 0; i < md_len; i++) printf("%02x", md_value[i]); + for(i = 0; i < md_len; i++) + printf("%02x", md_value[i]); printf("\n"); + + /* Call this once before exit. */ + EVP_cleanup(); + exit(0); } =head1 SEE ALSO -L, L, L, -L, L, L, -L, L +L, +L =head1 HISTORY @@ -269,7 +273,7 @@ EVP_dss(), EVP_dss1(), EVP_mdc2() and EVP_ripemd160() were changed to return truely const EVP_MD * in OpenSSL 0.9.7. The link between digests and signing algorithms was fixed in OpenSSL 1.0 and -later, so now EVP_sha1() can be used with RSA and DSA, there is no need to +later, so now EVP_sha1() can be used with RSA and DSA; there is no need to use EVP_dss1() any more. OpenSSL 1.0 and later does not include the MD2 digest algorithm in the diff --git a/openssl/doc/crypto/EVP_DigestVerifyInit.pod b/openssl/doc/crypto/EVP_DigestVerifyInit.pod index f22448897..cfeccd96e 100644 --- a/openssl/doc/crypto/EVP_DigestVerifyInit.pod +++ b/openssl/doc/crypto/EVP_DigestVerifyInit.pod @@ -38,7 +38,7 @@ or a negative value for failure. In particular a return value of -2 indicates the operation is not supported by the public key algorithm. Unlike other functions the return value 0 from EVP_DigestVerifyFinal() only -indicates that the signature did not not verify successfully (that is tbs did +indicates that the signature did not verify successfully (that is tbs did not match the original data or the signature was of invalid form) it is not an indication of a more serious error. @@ -59,7 +59,7 @@ For some key types and parameters the random number generator must be seeded or the operation will fail. The call to EVP_DigestVerifyFinal() internally finalizes a copy of the digest -context. This means that calls to EVP_VerifyUpdate() and EVP_VerifyFinal() can +context. This means that EVP_VerifyUpdate() and EVP_VerifyFinal() can be called later to digest and verify additional data. Since only a copy of the digest context is ever finalized the context must diff --git a/openssl/doc/crypto/EVP_EncryptInit.pod b/openssl/doc/crypto/EVP_EncryptInit.pod index d11e054e4..4e22edcd6 100644 --- a/openssl/doc/crypto/EVP_EncryptInit.pod +++ b/openssl/doc/crypto/EVP_EncryptInit.pod @@ -387,27 +387,7 @@ for certain common S/MIME ciphers (RC2, DES, triple DES) in CBC mode. =head1 EXAMPLES -Get the number of rounds used in RC5: - - int nrounds; - EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GET_RC5_ROUNDS, 0, &nrounds); - -Get the RC2 effective key length: - - int key_bits; - EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GET_RC2_KEY_BITS, 0, &key_bits); - -Set the number of rounds used in RC5: - - int nrounds; - EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_SET_RC5_ROUNDS, nrounds, NULL); - -Set the effective key length used in RC2: - - int key_bits; - EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_SET_RC2_KEY_BITS, key_bits, NULL); - -Encrypt a string using blowfish: +Encrypt a string using IDEA: int do_crypt(char *outfile) { @@ -421,8 +401,9 @@ Encrypt a string using blowfish: char intext[] = "Some Crypto Text"; EVP_CIPHER_CTX ctx; FILE *out; + EVP_CIPHER_CTX_init(&ctx); - EVP_EncryptInit_ex(&ctx, EVP_bf_cbc(), NULL, key, iv); + EVP_EncryptInit_ex(&ctx, EVP_idea_cbc(), NULL, key, iv); if(!EVP_EncryptUpdate(&ctx, outbuf, &outlen, intext, strlen(intext))) { @@ -451,28 +432,34 @@ Encrypt a string using blowfish: } The ciphertext from the above example can be decrypted using the B -utility with the command line: +utility with the command line (shown on two lines for clarity): - S + openssl idea -d or B if the key is not of the correct type. -EVP_PKEY_assign_RSA() EVP_PKEY_assign_DSA(), EVP_PKEY_assign_DH() +EVP_PKEY_assign_RSA(), EVP_PKEY_assign_DSA(), EVP_PKEY_assign_DH() and EVP_PKEY_assign_EC_KEY() also set the referenced key to B however these use the supplied B internally and so B will be freed when the parent B is freed. @@ -54,8 +54,8 @@ In accordance with the OpenSSL naming convention the key obtained from or assigned to the B using the B<1> functions must be freed as well as B. -EVP_PKEY_assign_RSA() EVP_PKEY_assign_DSA(), EVP_PKEY_assign_DH() -EVP_PKEY_assign_EC_KEY() are implemented as macros. +EVP_PKEY_assign_RSA(), EVP_PKEY_assign_DSA(), EVP_PKEY_assign_DH() +and EVP_PKEY_assign_EC_KEY() are implemented as macros. =head1 RETURN VALUES @@ -66,7 +66,7 @@ EVP_PKEY_get1_RSA(), EVP_PKEY_get1_DSA(), EVP_PKEY_get1_DH() and EVP_PKEY_get1_EC_KEY() return the referenced key or B if an error occurred. -EVP_PKEY_assign_RSA() EVP_PKEY_assign_DSA(), EVP_PKEY_assign_DH() +EVP_PKEY_assign_RSA(), EVP_PKEY_assign_DSA(), EVP_PKEY_assign_DH() and EVP_PKEY_assign_EC_KEY() return 1 for success and 0 for failure. =head1 SEE ALSO diff --git a/openssl/doc/crypto/EVP_PKEY_sign.pod b/openssl/doc/crypto/EVP_PKEY_sign.pod index a044f2c13..21974b4b1 100644 --- a/openssl/doc/crypto/EVP_PKEY_sign.pod +++ b/openssl/doc/crypto/EVP_PKEY_sign.pod @@ -28,9 +28,14 @@ B and the amount of data written to B. =head1 NOTES +EVP_PKEY_sign() does not hash the data to be signed, and therefore is +normally used to sign digests. For signing arbitrary messages, see the +L and +L signing interfaces instead. + After the call to EVP_PKEY_sign_init() algorithm specific control operations can be performed to set any appropriate parameters for the -operation. +operation (see L). The function EVP_PKEY_sign() can be called more than once on the same context if several operations are performed using the same parameters. @@ -49,13 +54,17 @@ Sign data using RSA with PKCS#1 padding and SHA256 digest: #include EVP_PKEY_CTX *ctx; + /* md is a SHA-256 digest in this example. */ unsigned char *md, *sig; - size_t mdlen, siglen; + size_t mdlen = 32, siglen; EVP_PKEY *signing_key; - /* NB: assumes signing_key, md and mdlen are already set up - * and that signing_key is an RSA private key + + /* + * NB: assumes signing_key and md are set up before the next + * step. signing_key must be an RSA private key and md must + * point to the SHA-256 digest to be signed. */ - ctx = EVP_PKEY_CTX_new(signing_key); + ctx = EVP_PKEY_CTX_new(signing_key, NULL /* no engine */); if (!ctx) /* Error occurred */ if (EVP_PKEY_sign_init(ctx) <= 0) @@ -83,6 +92,7 @@ Sign data using RSA with PKCS#1 padding and SHA256 digest: =head1 SEE ALSO L, +L, L, L, L, diff --git a/openssl/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod b/openssl/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod index b34c68aba..7a27eef50 100644 --- a/openssl/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod +++ b/openssl/doc/ssl/SSL_CTX_set_tmp_dh_callback.pod @@ -48,12 +48,13 @@ even if he gets hold of the normal (certified) key, as this key was only used for signing. In order to perform a DH key exchange the server must use a DH group -(DH parameters) and generate a DH key. The server will always generate a new -DH key during the negotiation, when the DH parameters are supplied via -callback and/or when the SSL_OP_SINGLE_DH_USE option of -L is set. It will -immediately create a DH key, when DH parameters are supplied via -SSL_CTX_set_tmp_dh() and SSL_OP_SINGLE_DH_USE is not set. In this case, +(DH parameters) and generate a DH key. +The server will always generate a new DH key during the negotiation +if either the DH parameters are supplied via callback or the +SSL_OP_SINGLE_DH_USE option of SSL_CTX_set_options(3) is set (or both). +It will immediately create a DH key if DH parameters are supplied via +SSL_CTX_set_tmp_dh() and SSL_OP_SINGLE_DH_USE is not set. +In this case, it may happen that a key is generated on initialization without later being needed, while on the other hand the computer time during the negotiation is being saved. @@ -139,7 +140,7 @@ partly left out.) dh_tmp = dh_512; break; case 1024: - if (!dh_1024) + if (!dh_1024) dh_1024 = get_dh1024(); dh_tmp = dh_1024; break; -- cgit v1.2.3