[openssl.org #1638] OpenSSL doc on EVP_*Final() inaccurate; should mention EVP_CIPHER_CTX_cleanup()
Currently the manual page http://www.openssl.org/docs/crypto/EVP_EncryptInit.html paragraph for EVP_DecryptFinal() says: EVP_EncryptFinal(), EVP_DecryptFinal() and EVP_CipherFinal() behave in a similar way to EVP_EncryptFinal_ex(), EVP_DecryptFinal_ex() and EVP_CipherFinal_ex() except ctx is automatically cleaned up after the call. In the paragraphs for those three *_ex() functions, there's nothing explicit about cleanup, though right afterwards there is a seemingly unrelated paragraph: EVP_CIPHER_CTX_cleanup() clears all information from a cipher context and free up any allocated memory associate with it. It should be called after all operations using a cipher are complete so sensitive information does not remain in memory. It wasn't until Rational Purify pointed me at a recurring 244-byte memory leak: MLK: 244 bytes leaked at 0x40130c10 * This memory was allocated from: malloc [rtlib.o] default_malloc_ex [libcrypto.sl.0.9.8] CRYPTO_malloc [libcrypto.sl.0.9.8] EVP_CipherInit_ex [libcrypto.sl.0.9.8] EVP_DecryptInit [libcrypto.sl.0.9.8] ...that I realized there was a problem. Reading the code and then googling led me to the Changelog paragraph section from Dec 2002: *) Remove most calls to EVP_CIPHER_CTX_cleanup() in evp_enc.c, this allows existing EVP_CIPHER_CTX structures to be reused after calling EVP_*Final(). This behaviour is used by encryption BIOs and some applications. This has the side effect that applications must explicitly clean up cipher contexts with EVP_CIPHER_CTX_cleanup() or they will leak memory. [Steve Henson] I think that, as documentation goes, this is sufficiently obscure that it merits a change to the man page section. Based on the 0.9.8a source, here's what I would suggest as an improved form of that first paragraph I quoted: EVP_EncryptFinal(), EVP_DecryptFinal() and EVP_CipherFinal() are identical to EVP_EncryptFinal_ex(), EVP_DecryptFinal_ex() and EVP_CipherFinal_ex() and as with those functions, EVP_CIPHER_CTX_cleanup() should be called after each call to release memory allocated in the EVP_CIPHER_CTX structure. Note that this is no longer automatically done, so as to allow that structure to be reused for a performance gain, behavior which is used by encryption BIOs and some applications. Many thanks in advance, Larry West Intuit San Diego 858-215-9552 Currently the manual page http://www.openssl.org/docs/crypto/EVP_EncryptInit.htmlparagraph for EVP_DecryptFinal() says: EVP_EncryptFinal(), EVP_DecryptFinal() and EVP_CipherFinal() behave in a similar way to EVP_EncryptFinal_ex(), EVP_DecryptFinal_ex() and EVP_CipherFinal_ex() except ctx is automatically cleaned up after the call. Inthe paragraphs for those three *_ex() functions, there's nothing explicit about cleanup, though right afterwards there is a seemingly unrelated paragraph: EVP_CIPHER_CTX_cleanup() clears all information from a cipher context and free up any allocated memory associate with it. It should be called after all operations using a cipher are complete so sensitive information does not remain in memory. It wasn't until Rational Purify pointed me at a recurring 244-byte memory leak: MLK: 244 bytes leaked at 0x40130c10 * This memory was allocated from: malloc [rtlib.o] default_malloc_ex [libcrypto.sl.0.9.8]CRYPTO_malloc [libcrypto.sl.0.9.8] EVP_CipherInit_ex [libcrypto.sl.0.9.8] EVP_DecryptInit [libcrypto.sl.0.9.8] ...that I realized there was a problem. Reading the code and then googling led me to the Changelog paragraph section from Dec 2002: *) Remove most calls to EVP_CIPHER_CTX_cleanup() in evp_enc.c, this allows existing EVP_CIPHER_CTX structures to be reused after calling EVP_*Final(). This behaviour is used by encryption BIOs and some applications. This has the side effect that applications must explicitly clean up cipher contexts with EVP_CIPHER_CTX_cleanup() or they will leak memory. [Steve Henson] I think that, as documentation goes, this is sufficiently obscure that it merits a change to the man page section. Based on the 0.9.8a source, here's what I would suggest as an improved form of that first paragraph I quoted: EVP_EncryptFinal(), EVP_DecryptFinal() and EVP_CipherFinal() are identical to EVP_EncryptFinal_ex(), EVP_DecryptFinal_ex() and EVP_CipherFinal_ex() and as with those functions, EVP_CIPHER_CTX_cleanup() should be called aftereach call to release memory allocated in theEVP_CIPHER_CTX structure. Note that this is no longer automatically done, so as to allow that structure to be reused for a performance gain, behavior which is used by encryption BIOs and some applications. Many thanks in advance, Larry West IntuitSan Diego 858-215-9552
[openssl.org #1639] BUG in BN_mod_inverse
Hello!
BN_mod_inverse has a lines such as:
if (sign 0)
{
if (!BN_sub(Y,n,Y)) goto err;
}
This is incorrect call of BN_sub(BIGNUM *r, const BIGNUM *a, const
BIGNUM *b), because BN_sub change first parameter r during arithmetic
operations and suppose r and b are different objects.
I think those lines of code must be look like this:
if (sign 0)
{
if (!BN_sub(R,n,Y)) goto err;
if (BN_copy(Y,R) == NULL) goto err;
}
--
Eugene.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Minor bug in verify manpage
Richard Hartmann wrote: Hi all, 3 X509_V_ERR_UNABLE_TO_GET_CRL unable to get certificate CRL should read 3 X509_V_ERR_UNABLE_TO_GET_CRL: unable to get certificate CRL i.e. there is a colon missing. If there is any interest, I can create a patch but it is probably faster for both sides if someone with commit access just fixes this him- or herself. Applied. Thanks, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Proposed patch to check a CRL when a CA is renewed
Hello, OpenSSL doesn't cleanly verify revocation status when a CA is renewed (with a key change). Attached is a proposed patch to handle this case. This patch has been done against the current CVS version (I mirror it every night). For a description of the problem, please consider the following situation: * a CA (name it CN=My Trusted CA for example) is created, delivers certificates, revokes some, and periodically generates CRLs * this CA will expire in 1 year, so for service continuity (end-users certificates have a 1-year validity period), it has to be renewed * a new keypair is generated, a new certificate for this CA is produced (we *MUST* keep the same name to make it be the same CA) * this new CA certificate is deployed across the end-users base, and now this new generation CA does the job: certificate generation, revocation, CRL signing, etc), and the end-user certificates previously revoked by the old generation CA will be present in the CRL produced by this new generation CA So the only CRL to have is the new one (the old generation CA doesn't sign anything anymore). OpenSSL can't verify old end-user certificates against the CRL, because it checks the verification of the CRL against the public key of the certificate that signed the end-user certificate. That's not conformant to the X.509 standard. -- Erwann ABALEA [EMAIL PROTECTED] openssl099-crl-renewedca.diff.gz Description: Binary data
Re: Proposed patch to check a CRL when a CA is renewed
Hi Erwann: On Thursday 31 January 2008 11:23:57 Erwann ABALEA wrote: Hello, OpenSSL doesn't cleanly verify revocation status when a CA is renewed (with a key change). Attached is a proposed patch to handle this case. This patch has been done against the current CVS version (I mirror it every night). For a description of the problem, please consider the following situation: * a CA (name it CN=My Trusted CA for example) is created, delivers certificates, revokes some, and periodically generates CRLs * this CA will expire in 1 year, so for service continuity (end-users certificates have a 1-year validity period), it has to be renewed * a new keypair is generated, a new certificate for this CA is produced (we *MUST* keep the same name to make it be the same CA) * this new CA certificate is deployed across the end-users base, and now this new generation CA does the job: certificate generation, revocation, CRL signing, etc), and the end-user certificates previously revoked by the old generation CA will be present in the CRL produced by this new generation CA So the only CRL to have is the new one (the old generation CA doesn't sign anything anymore). I disagree with this idea, in principle, and what you are suggesting is CA rekey, and not renewal. Renewal is when you issue a new certificate, but keep the same keys. In this case, the CRL validation in OpenSSL works fine, since the keys are the same, and the only difference in the cert is a new validity and serial number. In the case where a CA rekeys (new Private key) (which is hopefully not that often - since in any sort of production environment, this requires a full key ceremony, auditors, etc.) then your patch is applicable, but needs too be examined in light of the other issues around certificate rekey... One has to be very carefull when dealing with another CA that has the same name but different keys, or else it would be possible for an attacker to impersonate a CA. That is why, most of the time, CA keys are long life - I normally see 20 years as usual lifetimes. In my experience key roll-over is usually managed by some form of overlap - where the new Issuance CA is brought up at a time that is the same as the validity period for currently issued certs before the current CA end of lifes, and starts issuing certs then, so that when the old CA finally goes out of validity, there are no valid certs left around to issue CRLs for. OpenSSL can't verify old end-user certificates against the CRL, because it checks the verification of the CRL against the public key of the certificate that signed the end-user certificate. That's not conformant to the X.509 standard. I definitely disagree with the last statement - according to RFC3280 (which is the relevant X.509 standard in this case, I believe) if you want to validate a CRL against a key other than that used to sign the certificate, you are supposed to use the cRLIssuer field of the cRLDistributionPoint in the certificate. Allowing any other form of validation of a CRL signature leaves you wide open to a denial of service attack. Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Multithreaded AES-CTR implementation
Howdy all, As part of some work that my colleague (Ben Bennett) and I have been doing on increasing performance of OpenSSH we've developed a multi-threaded implementation of CTR mode for AES. Its built against the OpenSSH implementation of CTR mode but we were thinking that there might be some interest amoung the OpenSSL crowd as well. This isn't presented as a patch against OpenSSL but simply to inform the community what we've been working on. The announcement we made to the OpenSSH list is attached below. We welcome any comments or thoughts you might happen to have. Chris Rapier Pittsburgh Supercomputing Center - On multiple core systems OpenSSH is limited to using a single core for all operations. On these systems this can result in a transfer being processor bound even though additional CPU resources exist. In order to open up this bottleneck we've developed a multi-threaded version of the AES-CTR cipher. Unlike CBC mode, since there is no dependency between cipher blocks in CTR mode we parallelize cipher block operations among multiple threads. Furthermore, since the AES_encrypt operations do not depend on the data to be ciphered we pre-generate the effective keystream. The main thread still handles the packetization, MAC computation, and associated I/O but the computationally expensive AES_encrypt operations are offloaded to one or more additional cores. In our tests this resulted in a performance improvement of up to 125% on systems that were previously CPU bound. In fact, utilizing less than four cores we were able to achieve near line rate on a GigE LAN connection with 128, 192, and 256-bit AES. More details on the implementation can be found at http://www.internet2.edu/presentations/jt2008jan/20080122-rapier-bennett.htm starting at slide 30. Results can be found on slide 46. As the resulting cipher stream is indistinguishable from the original single-threaded implementation of AES-CTR there are no known issues with backward compatibility. This patch should be thought of as experimental at this point. While it has performed well in test environments it is not yet, to our knowledge, deployed in critical production environments and the threading can impose a performance penalty on single core systems (but only when using AES-CTR). We're still exploring methods to have single-threaded and multi-threaded implementations of CTR mode exist side by side. The patch itself can be found at http://www.psc.edu/networking/projects/hpn-ssh/ or more specifically http://www.psc.edu/networking/projects/hpn-ssh/openssh4.7-CTR-threading.diff Additionally, this patch will apply on top of the HPN-SSH12v20 patch. It will, within a week or so, be incorporated into the HPN suite of patches as HPN13. If you have any problems applying the patch please let us know. Any comments, suggestions, or critiques you may have are welcome and appreciated. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-dev] Re: Proposed patch to check a CRL when a CA is renewed
Hi Patrick, Hodie pr. Kal. Feb. MMVIII est, Patrick Patterson scripsit: Hi Erwann: On Thursday 31 January 2008 11:23:57 Erwann ABALEA wrote: Hello, OpenSSL doesn't cleanly verify revocation status when a CA is renewed (with a key change). Attached is a proposed patch to handle this case. This patch has been done against the current CVS version (I mirror it every night). For a description of the problem, please consider the following situation: * a CA (name it CN=My Trusted CA for example) is created, delivers certificates, revokes some, and periodically generates CRLs * this CA will expire in 1 year, so for service continuity (end-users certificates have a 1-year validity period), it has to be renewed * a new keypair is generated, a new certificate for this CA is produced (we *MUST* keep the same name to make it be the same CA) * this new CA certificate is deployed across the end-users base, and now this new generation CA does the job: certificate generation, revocation, CRL signing, etc), and the end-user certificates previously revoked by the old generation CA will be present in the CRL produced by this new generation CA So the only CRL to have is the new one (the old generation CA doesn't sign anything anymore). I disagree with this idea, in principle, and what you are suggesting is CA rekey, and not renewal. Renewal is when you issue a new certificate, but keep the same keys. In this case, the CRL validation in OpenSSL works fine, since the keys are the same, and the only difference in the cert is a new validity and serial number. OK. Let's call it rekey if you want, that's not a problem. We're a PKI operator, and we don't renew CAs, we only rekey them, then. Such differenciation is found nowhere in the X.509 standard, or the RFC3280 document (or its successor, still in draft). In the case where a CA rekeys (new Private key) (which is hopefully not that often - since in any sort of production environment, this requires a full key ceremony, auditors, etc.) It has been done it this way with SET for years, every single CA had its private keys changed every year, and the corresponding certificates also. Even the root. And yes, it required a full key ceremony. And even now, for a big customer we have in common (I won't give its name here), such practice (renew of a CA certificate without changing the private key) is strictly forbidden by its certification policy. The fact that it requires a full key ceremony is of no influence here, as you also need to perform the key ceremony in the same conditions if you renew a CA certificate. then your patch is applicable, but needs too be examined in light of the other issues around certificate rekey... Sure, that's why this patch is only proposed, not imposed. One has to be very carefull when dealing with another CA that has the same name but different keys, or else it would be possible for an attacker to impersonate a CA. That's not possible. If it has the same name, then it's the same exact CA. Period. We're dealing here with CA certificates, with off-band verification to perform trust, etc. So CA impersonification is not a problem here. That is why, most of the time, CA keys are long life - I normally see 20 years as usual lifetimes. In my experience key roll-over is usually managed by some form of overlap - where the new Issuance CA is brought up at a time that is the same as the validity period for currently issued certs before the current CA end of lifes, and starts issuing certs then, so that when the old CA finally goes out of validity, there are no valid certs left around to issue CRLs for. In what I wrote, which word wasn't clear? That's what we do, we generate a new CA certificate at a time that is the same as the validity period for currently issued certs before the current CA end of lifes, and it starts issuing certs then. Here, we just happen to generate a new private key for this CA. The problem here is between this exact moment and the end-of-life of the previous CA cert, some end-user certificates exist, are still valid, and must be checked against a CRL signed by a different key (but the same CA). OpenSSL can't verify old end-user certificates against the CRL, because it checks the verification of the CRL against the public key of the certificate that signed the end-user certificate. That's not conformant to the X.509 standard. I definitely disagree with the last statement - according to RFC3280 (which is the relevant X.509 standard in this case, I believe) if you want to validate a CRL against a key other than that used to sign the certificate, you are supposed to use the cRLIssuer field of the cRLDistributionPoint in the certificate. Allowing any other form of validation of a CRL signature leaves you wide open to a denial of service attack. No. Neither the RFC3280 (which is only an X.509 profile, and
Re: [openssl-dev] Re: Proposed patch to check a CRL when a CA is renewed
Hi Erwann; On Thursday 31 January 2008 13:07:32 Erwann ABALEA wrote: Renewal is when you issue a new certificate, but keep the same keys. In this case, the CRL validation in OpenSSL works fine, since the keys are the same, and the only difference in the cert is a new validity and serial number. OK. Let's call it rekey if you want, that's not a problem. We're a PKI operator, and we don't renew CAs, we only rekey them, then. Such differenciation is found nowhere in the X.509 standard, or the RFC3280 document (or its successor, still in draft). No, since this is a policy decision, the relevant document is RFC3647, which makes a clear distinction between renewal and rekey. snip One has to be very carefull when dealing with another CA that has the same name but different keys, or else it would be possible for an attacker to impersonate a CA. That's not possible. If it has the same name, then it's the same exact CA. Period. We're dealing here with CA certificates, with off-band verification to perform trust, etc. So CA impersonification is not a problem here. Please see this thread: http://www.imc.org/ietf-pkix/old-archive-04/msg01204.html Essentially, my take on what Santosh is saying is that CRLs need to be signed by both CAs during the transition, because either a CA is active (and can be used to validate the signature on the certificate itself) or it isn't. If it is active it should sign it's own CRLs (and he doesn't preclude someone else signing a CRL as well for that certificate, but if you do do this, then the algorithm that he proposes in the thread should be followed, which Stephan had a problem with, since there is a possible disambiguation problem that could be exploited by a malicious attacker.). The relevant quote is as follows: Each of the two keys should be used to sign the full CRL for the scope of all certificates issued by that CA under all keys. Furthermore, the same revoked certificate list (empty or not) should be signed with all active keys. Active keys are defined as those CA private keys whose companion public keys can still be used to verify signatures on the certificates So you can't just stop using a particular CA's keys... until it either expires or is revoked, it should keep issuing CRL's for the keys it has issued. And if it keeps issuing CRL's, the situation for which you have created the patch should never happen :). This is a rather murky subject, and the merits of the two approaches are probably best discussed on the PKIX list, rather than here, as the approach has little to do with the technical implementation of what you propose :) Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1365] [openssl.org #1361] PATCH: Adding IPv6 support to s_client and s_server
Hi, Has this patch been applied to s_client and s_server in 0.9.8g? Thanks, --Hyong __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: memory corruption after usin BN_mod_inverse
Hi, Yair Elharrar! For me it looks bad. :-/ Because, BN_sub doesn't handle this situation (r = b): 1) BN_sub call BN_uadd(r,a,b), but r = b, then 2) BN_sub change r-neg, but r = b, then 3) BN_sub call BN_expand(r), then 4) BN_sub call BN_ucmp(a,b), but b here is not that b that was at the begin of BN_sub, then 5) BN_sub call BN_usub(r,a,b) or BN_usub(r,b,a), but ... May be I've used wrong words, but my thought was that calling BN_sub(Y,n,Y) from BN_mod_inverse leads to unpredictable behavior. And this is not subject of standard of C rather using it. AFAICS, the code never does all 4 of these steps. It either does 1 and 2 then returns or it does 3 and 4 and also sets r-neg before returning. I think you'll need to post a repeatable test case, with the values of the args to BN_mod_inverse that fail, preferably what is returned by BN_num_bytes and bytes from BN_bn2bin for each one. __Martin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
