Re: Timestamp reply validation
Hi, Sorry, I forgot the -cert option during the query. Nicolas. Le 13/06/2013 11:34, Nicolas ROCHE a écrit : Hello, I'm beginning with TSA and I'm wondering if it is possible to validate a timestamp request against a unique (self signed) certificate. Now I can do : $ openssl ts -verify -queryfile file.tsq -in file.tsr -CAfile demoCA/cacert.pem -untrusted demoCA/tsacert.pem I add the 'cacert.pem' certificate to the trusted diretory (hash simlink) but it didn't help : $ openssl ts -verify -queryfile file.tsq -in file.tsr -CAfile demoCA/cacert.pem signer certificate not found Please, may someone tell me what I'm missing ? Nicolas. Here is my testing envirenoment (on debian wheezy) : #!/bin/bash # Configuration cp /etc/ssl/openssl.cnf . sed -i -e 's/\# extendedKeyUsage/extendedKeyUsage/' openssl.cnf mkdir demoCA mkdir demoCA/private mkdir demoCA/newcerts touch demoCA/index.txt echo 0001 demoCA/serial echo 0001 demoCA/tsaserial export OPENSSL_CONF=$PWD/openssl.cnf # CA Cert (no password for the script usage!) openssl genrsa 1024 demoCA/private/cakey.pem openssl req -new -x509 -days 365 -key demoCA/private/cakey.pem demoCA/newcerts/cacert.pem EOF FR France Ulis Me RD CA-Me nro...@me.fr EOF cp demoCA/newcerts/cacert.pem demoCA # TSA Cert openssl genrsa 1024 demoCA/private/tsakey.pem openssl req -new -key demoCA/private/tsakey.pem tsacert.csr EOF FR France Ulis Me RD CA-Me nro...@me.fr EOF openssl ca -in tsacert.csr demoCA/newcerts/tsacert.pem EOF y y EOF cp demoCA/newcerts/tsacert.pem demoCA # Token query cowsay yé file.txt openssl ts -query -data file.txt -policy tsa_policy1 file.tsq openssl ts -query -in file.tsq -text # Token reply openssl ts -reply -queryfile file.tsq -inkey demoCA/private/tsakey.pem -signer demoCA/tsacert.pem file.tsr openssl ts -reply -in file.tsr -text # Token validation openssl ts -verify -queryfile file.tsq -in file.tsr -CAfile demoCA/cacert.pem -untrusted demoCA/tsacert.pem openssl ts -verify -data file.txt -in file.tsr -CAfile demoCA/cacert.pem -untrusted demoCA/tsacert.pem __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Proplem with RSA_private_encrypt and OAEP
Hi
I try to use RSA_private_encrypt and OAEP and always get the error at the call
of RSA_private_encrypt :
Error code: 4066076 in .\crypto\rsa\rsa_eay.c line 6029358.
Samplecode:
void SimpleTest()
{
RSA * rsa;
RSA * rsapub;
RSA * rsapri;
unsigned char src[1000] = 1234567;
unsigned char enc[1000] = {0};
unsigned char dec[1000] = {0};
int result;
int pubKeyLen, priKeyLen;
const byte *pubKey;
const byte *priKey;
byte *dummy;
OpenSSL_add_all_algorithms();
if (!(rsa = RSA_generate_key(1024, 0x10001, NULL, NULL)))
return;
pubKeyLen = i2d_RSAPublicKey(rsa, NULL);
pubKey = dummy =(byte *) malloc (pubKeyLen);
i2d_RSAPublicKey(rsa, dummy);
rsapub = d2i_RSAPublicKey(NULL, pubKey, pubKeyLen);
priKeyLen = i2d_RSAPrivateKey(rsa, NULL);
priKey = dummy = (byte *) malloc (priKeyLen);
i2d_RSAPrivateKey(rsa, dummy);
rsapri = d2i_RSAPrivateKey(NULL, priKey, priKeyLen);
if ((result = RSA_private_encrypt(strlen((char*)src), src, enc, rsapri,
RSA_PKCS1_OAEP_PADDING)) 0)
{
LogCryptError();
return;
}
if ((result = RSA_public_decrypt(result, enc, dec, rsapub,
RSA_PKCS1_OAEP_PADDING)) 0)
{
LogCryptError();
return;
}
RSA_free(rsa);
RSA_free(rsapub);
RSA_free(rsapri);
return;
}
Where is my fault? Please help.
Robert
RE: PBKDF2 implementation
Hi Michel, I could not find the p5_crpt2.c under \crypto\evp after I unzipped the openssl-fips-ecp-2.0.4.tar, could you please provide the correct installation script needed for WinXP. Thanks and Regards, Rengith M. From: Michel [mailto:msa...@paybox.com] Sent: Friday, June 14, 2013 2:18 PM To: openssl-users@openssl.org Cc: Rengith M. Subject: Re: PBKDF2 implementation PKCS5_PBKDF2_HMAC implementation : [openssl-src-dir]\crypto\evp\p5_crpt2.c in [openssl-src-dir]\crypto\evp\evp.h : PKCS5_SALT_LEN is defined as 8 Le 13/06/2013 08:39, Rengith M. a écrit : Hi, This is to know further about implementation of PBKDF2, PKCS5_PBKDF2_HMAC. 1. Would like to know the maximum salt length allowed. 2. Usage of hash function SHA256 with above function. 3. Which source code file implements the above function. 4. Please provide references to documentation on these, examples. 5. How to build on VC++ 6.0 for windows XP, SP3. i.e., I would like to check the PBKDF2, with key hashed with SHA256 and salt length equal to or greater than 8bytes * Confidentiality Statement/Disclaimer * This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt. The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.
Re: PBKDF2 implementation
PKCS5_PBKDF2_HMAC implementation : [openssl-src-dir]\crypto\evp\p5_crpt2.c in [openssl-src-dir]\crypto\evp\evp.h : PKCS5_SALT_LEN is defined as 8 Le 13/06/2013 08:39, Rengith M. a écrit : Hi, This is to know further about implementation of PBKDF2, PKCS5_PBKDF2_HMAC. 1.Would like to know the maximum salt length allowed. 2.Usage of hash function SHA256 with above function. 3.Which source code file implements the above function. 4.Please provide references to documentation on these, examples. 5.How to build on VC++ 6.0 for windows XP, SP3. i.e., I would like to check the PBKDF2, with key hashed with SHA256 and salt length equal to or greater than 8bytes
Re: PBKDF2 implementation
Hi Rengith, Sorry but I was referring to 1.0.1e source distribution. I am not able to answer about FIPS ones. Le 14/06/2013 11:06, Rengith M. a écrit : Hi Michel, I could not find the p5_crpt2.c under \crypto\evp after I unzipped the openssl-fips-ecp-2.0.4.tar, could you please provide the correct installation script needed for WinXP. Thanks and Regards, Rengith M.
Re: PBKDF2 implementation
On Fri, Jun 14, 2013, Rengith M. wrote: I could not find the p5_crpt2.c under \crypto\evp after I unzipped the openssl-fips-ecp-2.0.4.tar, could you please provide the correct installation script needed for WinXP. It is not present in the FIPS module source. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Proplem with RSA_private_encrypt and OAEP
On Fri, Jun 14, 2013, Robert Inzinger - SKIDATA wrote: Hi I try to use RSA_private_encrypt and OAEP and always get the error at the call of RSA_private_encrypt : RSA_private_encrypt() is used for signing data whereas OAEP is a padding mode used for encryption. You'd need to use RSA_public_encrypt and RSA_private_decrypt instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl 1.0.1e Signature verification problems
Hi, I am using openssl 1.0.1e to create a CA and generate certificates. I am facing an issue while generating the device certificates. After creating the ca certificate using below command # openssl req -x509 -new -newkey rsa:1024 -keyout private/cakey.pem -days 3650 -out cacert.pem when we try to display the contents the signature algorithm is shown as itu-t instead of sha1WithRSAEncryption #openssl x509 -in cacert.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 96:15:a3:26:59:5f:46:1d Signature Algorithm: itu-t Issuer: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com Validity Not Before: Jun 14 12:08:24 2013 GMT Not After : Jun 12 12:08:24 2023 GMT Subject: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c1:73:b4:37:ed:d1:1f:fb:bf:63:b0:8a:91:82: a8:f0:83:4d:5a:32:9b:5d:bc:23:06:3f:d4:fc:77: cf:83:0f:ab:ac:35:46:98:02:e5:a3:cc:89:30:34: 05:3f:80:ad:33:ae:dc:7e:57:60:e2:02:d6:c9:6b: b8:76:f7:56:e6:0f:44:c4:71:3a:cf:e1:59:8e:b4: 4b:6a:4a:de:59:25:4d:58:74:f0:82:27:0e:35:34: 72:86:9e:7c:a3:c8:cb:ba:55:8f:d5:8f:2f:cd:a0: 1f:e8:89:7c:74:0e:92:a0:de:72:d1:33:96:41:42: bc:44:d0:20:29:cf:7b:2c:a7 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A X509v3 Authority Key Identifier: keyid:C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A DirName:/C=US/ST=LA/L=CA/O=Internet Widgits Pty Ltd/OU=crop/CN=GWCA/subjectAltName=DNS:www.evmweb.com serial:96:15:A3:26:59:5F:46:1D X509v3 Basic Constraints: CA:TRUE Signature Algorithm: itu-t a0:0e:98:f2:46:4e:0e:b5:d9:ff:f2:e5:57:24:d2:81:66:2e: 4a:2b:3c:f6:02:48:4a:37:d8:4d:d9:70:b2:01:43:f4:71:fc: 92:27:a9:d0:0b:9f:1a:c2:b7:54:3e:67:f3:0e:71:76:15:c0: c2:0f:b7:3a:13:de:93:4e:42:27:f9:5a:bb:d9:9e:e8:19:55: 88:7e:4b:d6:3a:b7:2d:46:3f:79:13:f4:c7:da:59:37:95:ef: 15:47:91:2a:32:4d:0d:ba:6f:a6:13:c3:57:87:ac:70:53:98: 41:11:8d:ee:af:3d:46:d1:48:bb:f7:de:5d:00:a4:f1:59:c2: 0c:56 when we try to sign a device certificate I am getting below error. # openssl ca -policy policy_anything -out certs/evm1gwcert.pem -infiles evm1gwCSR.pem Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for /etc/ssl/private/cakey.pem: Check that the request matches the signature Signature verification problems.. This was not observed in previous versions. When I tried to change default_md to sha1 in openssl.cnf it doesn't had any effect. Please suggest if we need to configure anything in particular in openssl.cnf or is it a bug. Thanks, Anand __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EC command line tools
I am having some trouble finding documentation or examples showing how to perform Elliptic Curve crypto operations using the openssl command line tool. Is possible to perform EC encryption and decryption using the openssl command line tool? In man pkeyutl for version 1.0.1e I see the text The EC algorithm supports sign, verify and derive operations. So, I suspect that command line encryption with EC is not supported, but I just wanted to comfirm that before digging into libcrypto to get that functionality. I would appreciate any help you all can pass on. Thank you, Steve Tarzia __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: EC command line tools
On 14 June 2013 20:12, Steve Tarzia st...@stevetarzia.com wrote: I am having some trouble finding documentation or examples showing how to perform Elliptic Curve crypto operations using the openssl command line tool. Is possible to perform EC encryption and decryption using the openssl command line tool? In man pkeyutl for version 1.0.1e I see the text The EC algorithm supports sign, verify and derive operations. So, I suspect that command line encryption with EC is not supported, but I just wanted to comfirm that before digging into libcrypto to get that functionality. I would appreciate any help you all can pass on. The only openssl supported EC algorithms are ECDSA (for sign/verify) and ECDH (for key agreement). That applies to both the ec command line tool and libcrypto, so you're out of luck I'm afraid. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: EC command line tools
On 6/14/13 2:47 PM, Matt Caswell wrote: On 14 June 2013 20:12, Steve Tarzia st...@stevetarzia.com wrote: I am having some trouble finding documentation or examples showing how to perform Elliptic Curve crypto operations using the openssl command line tool. Is possible to perform EC encryption and decryption using the openssl command line tool? In man pkeyutl for version 1.0.1e I see the text The EC algorithm supports sign, verify and derive operations. So, I suspect that command line encryption with EC is not supported, but I just wanted to comfirm that before digging into libcrypto to get that functionality. I would appreciate any help you all can pass on. The only openssl supported EC algorithms are ECDSA (for sign/verify) and ECDH (for key agreement). That applies to both the ec command line tool and libcrypto, so you're out of luck I'm afraid. Matt Not the answer I was hoping for, but at least you saved me some time. Thanks Matt! -Steve __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Degenerate DH key vulnerability in 0.9.8?
On 14 June 2013 01:55, Jakob Bohm jb-open...@wisemo.com wrote: On 6/12/2013 11:35 PM, Matt Caswell wrote: On 12 June 2013 21:15, Jakob Bohm jb-open...@wisemo.com wrote: As for the DH_check_pub_key() function, checking if pubkey is in the range two to large prime minus 2, inclusive is an insufficient check against accepting degenerate keys. For instance NIST SP 800-56A requires the following check for most FIPS certified implementations (they also allow some less practical checks that typically work only for static DH keys or your own keys): As far as I am aware there is no claim for NIST SP 800-56A compliance in the new versions So how did you go about getting this stuff FIPS validated in the first place? I kind of expected the FIPS validated module to include all those OpenSSL implemented algorithms which can be subjected to the CMVP, not some random subset. From User Guide for the OpenSSL FIPS Object Module v2.0: Only the algorithms listed in tables 4a and 4b of the Security Policy are allowed in FIPS mode. Note that Diffie-Hellman and RSA are allowed in FIPS mode for key agreement and key establishment even though they are “Non-Approved” for that purpose ...snip... The version of DH used by TLS is a variant on PKCS#3 and not the X9.42 specification, and hence is not compliant with SP800-56A. For example, the requirement: Each private key shall be unpredictable and shall be generated in the range [1, q-1] using an Approved random bit generator. For TLS clients that requirement cannot be satisfied as stated because the parameter q is not sent from server to client, only the parameter p. Clients generate a private key in the range [1, p-1] instead I was not aware of that specific TLS protocol shortcoming, which makes it difficult to do a lot of things right. Are the p values used generally from some list of well known group parameters or are they completely arbitrary. In the (as yet unreleased) 1.0.2 there is support for RFC5114 defined DH parameters. These *do* come with a q value. AFAIK there is no support for well known parameters in the released versions - I think they are completely arbitrary. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: A question on EVP_PKEY_copy_parameters
Hi Dave, This is a very detailed and excellent answer, Thank you very much Anu On Wed, Jun 12, 2013 at 6:59 PM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of anu.engineer Sent: Wednesday, 12 June, 2013 15:03 I am reading thru the ca.c in the apps directory to understand how to issue a certificate using OpenSSL and I came across this fragment of code which I am struggling to understand. Just before signing the certificate the code executes this fragment [indentation partially restored] pktmp=X509_get_pubkey(ret); if (EVP_PKEY_missing_parameters(pktmp) !EVP_PKEY_missing_parameters(pkey)) EVP_PKEY_copy_parameters(pktmp,pkey); EVP_PKEY_free(pktmp); I looked up the man pages and the notes section talk about The main purpose of the functions EVP_PKEY_missing_parameters() and EVP_PKEY_copy_parameters() is to handle public keys in certificates where the parameters are sometimes omitted from a public key if they are inherited from the CA that signed it. 1) What parameters are we talking about here ? We just read the Public Key from the CSR and we seem to copy some fields from the CA key ( in the code pkey) to pktmp key which is the key we read from the CSR. pktmp is a copy of the requester's publickey from the CSR, yes. The parameters for DSA are the group-defining prime p, subgroup order q, and subgroup generator g, and optionally some additional values that can be used to prove the parameters were generated randomly (i.e. not manipulated to force user keys into an possibly more breakable sub/group). As indicated, 3279/3280/5280 allow these to be omitted from PublicKeyInfo in child cert if they are the same as parent cert/key; this was apparently intended for cases like people in a business all using the same parameters for their keys and a corporate CA for their certs. AFAICS openssl won't *generate* a CSR like this, because its private keys are always complete, but some other software might. As no one seems to be using DSA certs on the public internet, there's no handy data to check this. The parameters for EC including ECDSA are in principle a prime integer for a GF(p) underlying field or a binary basis polynomial and its length for a GF(2^n) aka binary one, coefficients a and b of the curve equation, a base or generating point represented by two or sometimes one elements of the underlying field, the order of the result group and its cofactor. In practice people don't generate their own EC parameters (which is hard) but instead use one of a few dozen standardized sets, which can be and usually are encoded in the cert as one OID, so there's no practical benefit to using inheritance and I doubt anyone does. There are no parameters for RSA; each key(pair) stands alone. But it doesn't look like this piece of code accomplishes anything. It would make some sense to inherit the parameters (if necessary) then check this key is consistent with the parameters (to the extent possible for a publickey), but it doesn't actually do that. Maybe it did in a past version but got neutered by some change -- and not noticed because in practice people rarely create or accept deliberately defective keys and CSRs. Even when a malefactor wants a fraudulent cert, it's a fraudulent binding to a valid key. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]
On 6/13/2013 1:50 AM, Ryan Hurst wrote: They are doing a CA signed OCSP response, this is legitimate. We will do this in the not so distant future as well for many of our responses also. Please don't! As a knowledgeable GlobalSign customer I would prefer that you keep your root private keys as secure as possible. Using CA signed OCSP responses implies some serious and almost impossible to mitigate security risks: -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a CRL-style CA signed OCSP responder: - I define this as an OCSP responder that returns ONLY pregenerated responses, which it receives a a regular batch of responses for all issued certificates from the offline CA. 1. The short validity times expected by OCSP clients requires that new response batches are created 100 times per day or more, while the need to remain compatible with older (RFC2560) clients requires each response in the batch to cover only one certificate. Together, these two factors provides attackers with an easily collected collection of millions of signatures on algorithmically predictable data issued by the root key. This is exactly the kind of data needed for most otherwise infeasible/theoretical attacks on a public/private key pair. 2. The only way to make the signed data in a pregenerated OCSP response unpredictable is to include a random salt in a non-standard extension in each response. To avoid leaking the state of the internal RNG of the CA's HSM, such salt must be generated by a trusted RNG unrelated to the one in the primary HSM. 3. Due to shortcomings of the OCSP protocol documents, response batches can only be pregenerated ahead of time by including false time information in them, (lack of clarity means that some clients might reject producedAt values before thisUpdate) at best one could use the CRL reference extension to indicate the true generation time, but only if a real CRL is also generated as part of the batch. This makes it hard to take the root key holding HSM temporarily offline for security issues or any other good reason. This issue persists in RFC6960. 4. Due to shortcomings and lack of foresight in the OCSP protocol documents, the generation and return of responses using the SHA-1 hash algorithm will probably remain necessary at least until June 2021 (the 10 year anniversary of RFC6277), and responses using the SHA-256 hash algorithm until an unknown date after the year 2023 (since no RFC has yet been issued specifying any other must-accept algorithms). Furthermore, there are no must-accept algorithms using any contemporary version of DSA, nor using any algorithms not from the NSA-designed MD4-derived old SHA algorithms. There is not even a requirement that clients must accept the algorithm used to sign the certificate being checked. This issue persists in RFC6960. 5. There is no feasible way to pregenerate negative responses for never- issued certificates. Most notably, such negative responses cannot cover a range of unissued serial numbers and standard practice uses serial numbers so long that it is virtually impossible to even store one bit of response data for each unused serial number, let alone transmit such responses. The closest potential solution would be to use a streaming algorithm to generate but not store a sequence of SingleResponse for all serial numbers from X to Y, compute and store the surrounding parts of a BasicOCSPResponse holding that sequence, then recreate it on the fly when sending this response to a requestor, however the transmission bandwidth of such a monster response would still be prohibitive. This issue is present in RFC6960. 6. A CRL-style CA signed OCSP responder cannot respond to requests covering more than one certificate, since doing so requires the generation and storage of responses for almost infinitely many sets of certificates. If the client implements RFC6960, it is possible to simply send back a pre-signed response which is essentially the entire CRL in a different format, however the protocol does not provide this information in the Request, so this cannot be done until June 2023 (10 year anniversary of RFC6960). -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a truly online CA-signed OCSP responder, things are even worse: - I define this as an OCSP responder which generates responses on the fly and signs them with the CA root key. 1. It requires the CA root key to be available to at least one system (HSM or otherwise) with access to the CA private key to be online in a manner which completely prevents human vetting of requests (because the root key must be used at very short notice 24x7). This provides an avenue for seriously motivated attackers to work their way through
Re: A question on EVP_PKEY_copy_parameters
On Wed, Jun 12, 2013 at 12:02:52PM -0700, anu.engineer wrote: Just before signing the certificate the code executes this fragment pktmp=X509_get_pubkey(ret); if (EVP_PKEY_missing_parameters(pktmp) !EVP_PKEY_missing_parameters(pkey)) EVP_PKEY_copy_parameters(pktmp,pkey); EVP_PKEY_free(pktmp); I think that call to EVP_PKEY_copy_parameters should be checked for success, otherwise failure to copy the parameters may go unnoticed. My Question : 1) What parameters are we talking about here? This is in part for GOST R 34.10. Per RFC 4491 section 2.3.1 when the parameters are missing, they are inherited from the issuing certificate. It looks like OpenSSL wants to avoid creating certificates with missing parameters. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Degenerate DH key vulnerability in 0.9.8?
On 6/14/2013 11:12 PM, Matt Caswell wrote: On 14 June 2013 01:55, Jakob Bohm jb-open...@wisemo.com wrote: On 6/12/2013 11:35 PM, Matt Caswell wrote: On 12 June 2013 21:15, Jakob Bohm jb-open...@wisemo.com wrote: As for the DH_check_pub_key() function, checking if pubkey is in the range two to large prime minus 2, inclusive is an insufficient check against accepting degenerate keys. For instance NIST SP 800-56A requires the following check for most FIPS certified implementations (they also allow some less practical checks that typically work only for static DH keys or your own keys): As far as I am aware there is no claim for NIST SP 800-56A compliance in the new versions So how did you go about getting this stuff FIPS validated in the first place? I kind of expected the FIPS validated module to include all those OpenSSL implemented algorithms which can be subjected to the CMVP, not some random subset. From User Guide for the OpenSSL FIPS Object Module v2.0: Only the algorithms listed in tables 4a and 4b of the Security Policy are allowed in FIPS mode. Note that Diffie-Hellman and RSA are allowed in FIPS mode for key agreement and key establishment even though they are “Non-Approved” for that purpose ...snip... The version of DH used by TLS is a variant on PKCS#3 and not the X9.42 specification, and hence is not compliant with SP800-56A. For example, the requirement: Each private key shall be unpredictable and shall be generated in the range [1, q-1] using an Approved random bit generator. For TLS clients that requirement cannot be satisfied as stated because the parameter q is not sent from server to client, only the parameter p. Clients generate a private key in the range [1, p-1] instead I was not aware of that specific TLS protocol shortcoming, which makes it difficult to do a lot of things right. Are the p values used generally from some list of well known group parameters or are they completely arbitrary. In the (as yet unreleased) 1.0.2 there is support for RFC5114 defined DH parameters. These *do* come with a q value. AFAIK there is no support for well known parameters in the released versions - I think they are completely arbitrary. Note by Well known I meant as in We happen to know that most installations of Crypto++ while uses these 10 sets, most installations of OpenSSL 0.9.x these 9 sets, most installations of MS CryptoAPI, these 25 sets etc., in which case all those could be tabulated and recognized even though transmitted as actual (p,g) tupples. P.S. I would love a response to the open mathematical question in my suggested workaround code (previous e-mail). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]
Jakob, Online CA signing keys for something like OCSP signing is a bad idea and don't worry we wont do that; we are looking at doing is using pre-produced OCSP for issuing CAs issued certificates; in this model all cache-misses and root responses would be VA delegated still. This protects the CA key material yet keeps the large majority of the responses much smaller due to the left out keys. For this to be a viable model, as you point out frequency of response generation is one factor, as is the validity period of the issuing CA. CAs are required to produce responses every 7 days, we comply with that but as part of our new infrastructure investment we will be bringing that time down quite a bit; the largest issue here being time skew on the broader internet. This introduces practical limits that mean that you cant be too fresh on your revocation times. It also means producing fresher responses 100s of times a day isn't of much value, you can of course update the changes in the cached responses set to be accurate but fresher / shorter lived responses end up breaking things for a reasonably large % of users. I believe this approach addresses most of the concerns you mentioned bellow, a few exceptions: You state that pre-produced OCSP responses cant span multiple certids (practically), while this is true we receive exactly zero such requests to do and testing shows that major clients don't even handle the case correctly when such responses are returned (geotrust does this); they simply store the larger response many times even if they already had a signed response that was valid covering that certid. Ryan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jakob Bohm Sent: Friday, June 14, 2013 3:10 PM To: openssl-users@openssl.org Subject: Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?] On 6/13/2013 1:50 AM, Ryan Hurst wrote: They are doing a CA signed OCSP response, this is legitimate. We will do this in the not so distant future as well for many of our responses also. Please don't! As a knowledgeable GlobalSign customer I would prefer that you keep your root private keys as secure as possible. Using CA signed OCSP responses implies some serious and almost impossible to mitigate security risks: -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a CRL-style CA signed OCSP responder: - I define this as an OCSP responder that returns ONLY pregenerated responses, which it receives a a regular batch of responses for all issued certificates from the offline CA. 1. The short validity times expected by OCSP clients requires that new response batches are created 100 times per day or more, while the need to remain compatible with older (RFC2560) clients requires each response in the batch to cover only one certificate. Together, these two factors provides attackers with an easily collected collection of millions of signatures on algorithmically predictable data issued by the root key. This is exactly the kind of data needed for most otherwise infeasible/theoretical attacks on a public/private key pair. 2. The only way to make the signed data in a pregenerated OCSP response unpredictable is to include a random salt in a non-standard extension in each response. To avoid leaking the state of the internal RNG of the CA's HSM, such salt must be generated by a trusted RNG unrelated to the one in the primary HSM. 3. Due to shortcomings of the OCSP protocol documents, response batches can only be pregenerated ahead of time by including false time information in them, (lack of clarity means that some clients might reject producedAt values before thisUpdate) at best one could use the CRL reference extension to indicate the true generation time, but only if a real CRL is also generated as part of the batch. This makes it hard to take the root key holding HSM temporarily offline for security issues or any other good reason. This issue persists in RFC6960. 4. Due to shortcomings and lack of foresight in the OCSP protocol documents, the generation and return of responses using the SHA-1 hash algorithm will probably remain necessary at least until June 2021 (the 10 year anniversary of RFC6277), and responses using the SHA-256 hash algorithm until an unknown date after the year 2023 (since no RFC has yet been issued specifying any other must-accept algorithms). Furthermore, there are no must-accept algorithms using any contemporary version of DSA, nor using any algorithms not from the NSA-designed MD4-derived old SHA algorithms. There is not even a requirement that clients must accept the algorithm used to sign the certificate being checked. This issue persists in RFC6960. 5. There is no feasible way to
Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]
On 6/15/2013 1:15 AM, Ryan Hurst wrote: Thanks for your reply, just one tidbit that surprised me: CAs are required to produce responses every 7 days, we comply with that but as part of our new infrastructure investment we will be bringing that time down quite a bit; the largest issue here being time skew on the broader internet. This introduces practical limits that mean that you cant be too fresh on your revocation times. It also means producing fresher responses 100s of times a day isn't of much value, you can of course update the changes in the cached responses set to be accurate but fresher / shorter lived responses end up breaking things for a reasonably large % of users. Ahh, I never heard about this 7 day rule, the closest I had previously heard was a CSP for a (now essentially defunct) national CA, which required CRL update delays of 1 minute or less from compromise reports, and those were not even qualified certs! From this I kind of surmised that OCSP validity times 5 minutes would be as unsupported as DNS TTLs 1 month. I believe this approach addresses most of the concerns you mentioned bellow, a few exceptions: ... You missed another concern: The need to use old dubious signature algorithms for the next 10 years, due to the late publication of RFC6277, the failure to require in the spec that clients must accept the alg used to sign the cert and the failure of even the latest RFC6960 to specify anything other than SHA-1 and SHA-256, and the failure to provide any request indication that a client implements anything post-RFC2560 (you could be lucky to receive a redundant algorithm list specifying the defaults from some post RFC6277 clients). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]
I agree 2560's lack of algorithm agility is a problem and RFC6960's lack of specifying an indicator of which algorithm to use is also a little problematic; that said it is one that can be worked around in most cases. One likely way is that responders will rely on the User Agent header to determine platform support for a given behavior and if algorithm support isn't explicitly known fallback to SHA1; this can help accelerate the adoption of SHA2 in OCSP but the larger platform adoption problem still exists. It takes roughly 10 years from release of Windows to 98% ubiquity; that mean we better hope Windows adds support for RFC6960 soon so that clock can start ticking. Has support been added to OpenSSL yet? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jakob Bohm Sent: Friday, June 14, 2013 5:00 PM To: openssl-users@openssl.org Subject: Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?] On 6/15/2013 1:15 AM, Ryan Hurst wrote: Thanks for your reply, just one tidbit that surprised me: CAs are required to produce responses every 7 days, we comply with that but as part of our new infrastructure investment we will be bringing that time down quite a bit; the largest issue here being time skew on the broader internet. This introduces practical limits that mean that you cant be too fresh on your revocation times. It also means producing fresher responses 100s of times a day isn't of much value, you can of course update the changes in the cached responses set to be accurate but fresher / shorter lived responses end up breaking things for a reasonably large % of users. Ahh, I never heard about this 7 day rule, the closest I had previously heard was a CSP for a (now essentially defunct) national CA, which required CRL update delays of 1 minute or less from compromise reports, and those were not even qualified certs! From this I kind of surmised that OCSP validity times 5 minutes would be as unsupported as DNS TTLs 1 month. I believe this approach addresses most of the concerns you mentioned bellow, a few exceptions: ... You missed another concern: The need to use old dubious signature algorithms for the next 10 years, due to the late publication of RFC6277, the failure to require in the spec that clients must accept the alg used to sign the cert and the failure of even the latest RFC6960 to specify anything other than SHA-1 and SHA-256, and the failure to provide any request indication that a client implements anything post-RFC2560 (you could be lucky to receive a redundant algorithm list specifying the defaults from some post RFC6277 clients). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]
I forgot to respond the the 1 minute reference, we revoke right away and most CAs do that is just different than pre producing all revoked responses when one cert is revoked. Ryan Hurst Chief Technology Officer GMO Globalsign twitter: @rmhrisk Sent from my phone, please forgive the brevity. On Jun 14, 2013, at 4:59 PM, Jakob Bohm jb-open...@wisemo.com wrote: On 6/15/2013 1:15 AM, Ryan Hurst wrote: Thanks for your reply, just one tidbit that surprised me: CAs are required to produce responses every 7 days, we comply with that but as part of our new infrastructure investment we will be bringing that time down quite a bit; the largest issue here being time skew on the broader internet. This introduces practical limits that mean that you cant be too fresh on your revocation times. It also means producing fresher responses 100s of times a day isn't of much value, you can of course update the changes in the cached responses set to be accurate but fresher / shorter lived responses end up breaking things for a reasonably large % of users. Ahh, I never heard about this 7 day rule, the closest I had previously heard was a CSP for a (now essentially defunct) national CA, which required CRL update delays of 1 minute or less from compromise reports, and those were not even qualified certs! From this I kind of surmised that OCSP validity times 5 minutes would be as unsupported as DNS TTLs 1 month. I believe this approach addresses most of the concerns you mentioned bellow, a few exceptions: ... You missed another concern: The need to use old dubious signature algorithms for the next 10 years, due to the late publication of RFC6277, the failure to require in the spec that clients must accept the alg used to sign the cert and the failure of even the latest RFC6960 to specify anything other than SHA-1 and SHA-256, and the failure to provide any request indication that a client implements anything post-RFC2560 (you could be lucky to receive a redundant algorithm list specifying the defaults from some post RFC6277 clients). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME cryptographic signature
Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?]
Btw let me know if I can ever be of help. Ryan Hurst Chief Technology Officer GMO Globalsign twitter: @rmhrisk email: ryan.hu...@globalsign.com phone: 206-650-7926 Sent from my phone, please forgive the brevity. On Jun 14, 2013, at 3:09 PM, Jakob Bohm jb-open...@wisemo.com wrote: On 6/13/2013 1:50 AM, Ryan Hurst wrote: They are doing a CA signed OCSP response, this is legitimate. We will do this in the not so distant future as well for many of our responses also. Please don't! As a knowledgeable GlobalSign customer I would prefer that you keep your root private keys as secure as possible. Using CA signed OCSP responses implies some serious and almost impossible to mitigate security risks: -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a CRL-style CA signed OCSP responder: - I define this as an OCSP responder that returns ONLY pregenerated responses, which it receives a a regular batch of responses for all issued certificates from the offline CA. 1. The short validity times expected by OCSP clients requires that new response batches are created 100 times per day or more, while the need to remain compatible with older (RFC2560) clients requires each response in the batch to cover only one certificate. Together, these two factors provides attackers with an easily collected collection of millions of signatures on algorithmically predictable data issued by the root key. This is exactly the kind of data needed for most otherwise infeasible/theoretical attacks on a public/private key pair. 2. The only way to make the signed data in a pregenerated OCSP response unpredictable is to include a random salt in a non-standard extension in each response. To avoid leaking the state of the internal RNG of the CA's HSM, such salt must be generated by a trusted RNG unrelated to the one in the primary HSM. 3. Due to shortcomings of the OCSP protocol documents, response batches can only be pregenerated ahead of time by including false time information in them, (lack of clarity means that some clients might reject producedAt values before thisUpdate) at best one could use the CRL reference extension to indicate the true generation time, but only if a real CRL is also generated as part of the batch. This makes it hard to take the root key holding HSM temporarily offline for security issues or any other good reason. This issue persists in RFC6960. 4. Due to shortcomings and lack of foresight in the OCSP protocol documents, the generation and return of responses using the SHA-1 hash algorithm will probably remain necessary at least until June 2021 (the 10 year anniversary of RFC6277), and responses using the SHA-256 hash algorithm until an unknown date after the year 2023 (since no RFC has yet been issued specifying any other must-accept algorithms). Furthermore, there are no must-accept algorithms using any contemporary version of DSA, nor using any algorithms not from the NSA-designed MD4-derived old SHA algorithms. There is not even a requirement that clients must accept the algorithm used to sign the certificate being checked. This issue persists in RFC6960. 5. There is no feasible way to pregenerate negative responses for never- issued certificates. Most notably, such negative responses cannot cover a range of unissued serial numbers and standard practice uses serial numbers so long that it is virtually impossible to even store one bit of response data for each unused serial number, let alone transmit such responses. The closest potential solution would be to use a streaming algorithm to generate but not store a sequence of SingleResponse for all serial numbers from X to Y, compute and store the surrounding parts of a BasicOCSPResponse holding that sequence, then recreate it on the fly when sending this response to a requestor, however the transmission bandwidth of such a monster response would still be prohibitive. This issue is present in RFC6960. 6. A CRL-style CA signed OCSP responder cannot respond to requests covering more than one certificate, since doing so requires the generation and storage of responses for almost infinitely many sets of certificates. If the client implements RFC6960, it is possible to simply send back a pre-signed response which is essentially the entire CRL in a different format, however the protocol does not provide this information in the Request, so this cannot be done until June 2023 (10 year anniversary of RFC6960). -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a truly online CA-signed OCSP responder, things are even worse: - I define this as an OCSP responder which generates responses on the fly and signs them with the CA root key. 1. It requires the CA root key
