Re: [openssl-dev] Upgrading OpenSSL
I now have Racoon2 working. Steve's comment made me think about the digests used in Racoon2 and I went searching for any commands using SHA1. I found two hardcoded as string "SHA1". I changed it to SHA256 and bobs-your-uncle. I guess this is due to the phasing-out of the SHA1 hash which was not true in the days of v0.9.8? Sorry for using you guys as a soundboard, but I have no other option. Thanks for all your help Regards, LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upgrading OpenSSL
Hi all,
I need to correct my WTF comment - RTFM RSA_size return bytes. Sorry
LJB
> evp = PEM_read_PrivateKey(fp, NULL, NULL, NULL); #ifdef TEST RSA *rsa =
> EVP_PKEY_get1_RSA(evp); printf("\nRSA modulus: %d\n\n", RSA_size(rsa));
> #endif
>
> The output is: "RSA modulus: 512" (WTF!)
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upgrading OpenSSL
Hi all,
I've was able to get the private key from the HSM (added below). Testing it
from the commandline shows:
% openssl rsa -noout -check -in /etc/racoon2/Local/refB.pem
RSA key ok
Next I started from the default Racoon2 source code (20100526a) with NO
patches. It now reads the private key from file. It however still fails with
same error at "p_sign.c:123"!?
Since I know this will be a RSA key I added code after where the file is read
as EVP_PKEY (within ifdef):
evp = PEM_read_PrivateKey(fp, NULL, NULL, NULL);
#ifdef TEST
RSA *rsa = EVP_PKEY_get1_RSA(evp);
printf("\nRSA modulus: %d\n\n", RSA_size(rsa));
#endif
The output is: "RSA modulus: 512" (WTF!)
Output from CLI says modulus is:
$openssl rsa -text -in /etc/racoon2/Local/refB.pem
Private-Key: (4096 bit)
:
:
I also read the file directly with PEM_read_RSAPrivateKey() and also got the
modulus as 512.
I also tested that the private key and public certificate matches by singing
and verifying random data. So the private key must be correct - right?
I've added a line to the Racoon2 init function to print the OpenSSL version and
the output is: "OpenSSL version: 100020cf". OpenSSL and Racoon2 are both
configured with specific parameters to point to "/usr/local/ssl" as the path to
OpenSSL.
Based on search results, I've added "OpenSSL_add_all_algorithms()" to the init
code, but this did not make a difference. The other "add" and "load" stuff was
there already.
Thanks for all the help so far
LJB
-BEGIN RSA PRIVATE KEY-
MIIJKAIBAAKCAgEA5B36X3g6AtbnELtkoKUfAmwAXfFsk8kH0U+vRcuRLQ0VIVHI
FTZBIP4Ao68JPBh+fqS3eCtF5Ra1AxSTHH5+QkkN+c5j+iWbvlT55/gtrGz25dyW
A+xJ1LyvBuLxgczgCTIdvegMQNlo8r/fm492tXI/X3pMJufdMD8ddpBPc+rD1MbX
HcOYuWRdeDic0BepH1cvMnb9nCLz7lHv0j18NFYNYPeB0htu+jzP3EZndVtP3Zt3
C1gdjZf8j4SCI7gGtP/1kQ4lmemLCQhQG7sOgmqrNcX4Xk35sTEfn3ICE6p5vbsB
2hCCKpG8BaLS6jyoXecoXhtsbK4qLtexJdtJmDbKUm1dvFxr5qpes/pcQQR3KxIf
4woZmp24vT08WZHwCsmJd1WZffODBxCcEPn8ZdAABYUTsGlvjTEWnJCr+fJyUz6M
K/J85+sCilvOKVWvTldyleFfe7RFNLRPxxx9KeoSszb4lWe3Ic33vn5W8PthEvkY
ZwK36K4ripjksb0ROzTvFrhl4hgopnpMN5lu8eQExzktC+wyNbDHN3msy4UsQpou
mZq9WfRbvfqOCs/z3hh/bO5efxXhJCTt/5y4fh0qBRjXVCLkZcnaJ0cwaCfF+v/B
AHtJ8/Un3Aon7kFvVaaw7eMz6kC4y4mYMN6Zc+oYom9So+3wU1us5ezCr2UCAwEA
AQKCAgAWXR4DqAy/5IOor0ZxPV7p5N6wVw/W+Tlr+szrIcbszMCKkLL16Wi/LEex
xGI6YwhbsBhQjqV+jRhX4fd+LqSAKRtWpzZD+tXm9fu+EyWfJtuZs2N9pPekBI+A
NFWK7SP1otUpngs9fFL+oXLxlEIGDdpKqPm4Qrj7luRzkDhJ2/Uw8gF66Icbfcxw
EdTFzdwFt41n/CRm30Jc1emWCfMYSmtrWzh9+bSKkdWq+bgA2F/fEPO9x/i1vfXD
uDDuAYeezQ0tGF71VOENlKQN4+vLO1vnnK35yNk21uMLxaiQdwESabgHweCQ/dKa
Ftlon2O+OQBLIZMioHyANSMn2/S96RT6qiiJrf8leIsRRVmvNnSGC9ScPfGqZHHc
/Rh7zifRIDaoRi1/AB9GLoF01musmvULmv0AW2JOomm7Rxp71kED9pKJN/nrZkLT
mftAPBm/4pmrVt28bLQE0sn8JgtSaeP4Z5Y1VV3UHKit8rgY2AdAOCVeHYDeCZwy
n4OGeed6GxJIK0NHa9qTlhznPVvK5WB+vzNIqpd4eQPZ3ETX3fXp0CgEymyGQZIY
+rXkkR7XHPLcey7iEEdhmUdxXLMffuzvj5s1oOL7JY0rRLG6QoLhwNQX/kmmncZw
J24zrGz3KOfQcw1KKTuu/g8iwna3b/PYT15gIhlx1YvdvH34QQKCAQEA9kkoaQGR
fC56Uy9X+HrafDBj+JZc5+qM+9NVx9yigc9AS+Hw31eM9g2+ZotairL++X3ExSTP
0zJZQG5Af/oueX7PO7JpYJywMErymKTEjRnSa31RWgNy0SENWztGnshVjoBkC18U
fiTKrp/mEC3LEnjWG47NP7XnP6kwlZJf5vXyN0ystJXx4CUUHdKiFZ/+Ji8918jP
MADLHIqx6C8wF1nw3rsw7xbfj8hdL2uXc+ccTHaITEM49zf1NY6Y5FlEADmK8PHl
nW+KLz4p1FePP3+7j0vgmPPRAzH+26c+2SkBVLG9tZ4nRQFFoXu3DUZ/yR/kcj6d
6iF7WLg4IZ0M1QKCAQEA7R1dNihL7OrY2V/6F9YkWGThTaChfAlY2qoEzjU+tSN9
Oz4T4ErmNRwZne1bZS+KrDVAT2NyuHqP/d8UCH7+4dPUrCtUa2uocR2ZkCB/8YE0
MBwUGLVvEg9p5UzN8oLi5HYgplXuQyKjNKsOXRsFT+asiIaufGeB6SQH3YsO9d1J
cnFQ+I7syXIpgNVU4Hwva/A6OMn3F5ctHqSPcefoDrjJvZvuxNv2Q+OkfygOwIVl
fG0+cM33TRoHBkgRFsiluxB+HmHvnPruyacnVJr4iMMHoP55o2WFLzLyviCdxWfG
esI2UcYp//yGRomJfhH4ryo352AlZK+6XiGxFhsgUQKCAQEAoU+HfUd+r9SNYGC5
ANIOuprDT/XEQk55KxPfsnlLozRIy6rgJpjkheC4ndeWZRQaNvVuZSXYTV9D4BSW
gHwv5nntaA9SP+pA6FCeluYMqtKH5Ml++DMcB+fbJK8tcSCMETr8zAnplTmp2zh1
6pDj2mR08DXXL2yIW0UIwl7OG6tpi1jYIau4cfQ3OdVVPk69musEWYp4UdujLT2W
ixolKJZLUsdOpLrZkQZOKpoQ5+Quv9I/MZwx+pKXNA4DDEV/aZpG68u0diqxWoIf
yanT9GZIRfIP2H6RnsMnR11Cp9/YtE16kTNWSzcrETrDyZksZ2JRMZbbvZdSf+ih
Mzr3RQKCAQAoDEabCBFS0ZOQm1pFPmDjIR7AmrnLllSQkhi/r1SJCZZ0NBbtUhkx
rS5Scy11mKMGVPQotHZC3EiHq27ZxIFOKRYJgkP+5K8Nc99k7WhOpPDok0V9qt84
oKvVE7TRGfQyfBUlouvcIPSJx75kUVUDWsWXRZAg6OaTNwexDnSXaCmoj6UKZjFu
EL8byGxOggsMYwWiY9I9BMaVH1wu8+lI20MPqE+apkAg1UkKRPzA3Yb3jgf2y4LS
XewDzpY8T+VWBAIZJZdv3x4HpxjIfGgvySj3syNeSp5FC4jePeoH1nA6eaTtCNg9
KSyQq1gyl9x10V6h0KZgLCIBFhWv0yMRAoIBAE9i9Llefme5ZHDcXiJa7x7d11Et
KpHkMfrYwmCCPsZdijwAyN4oBfcfDbfASzSTtcK13qnzwq34xLSe7JgefbR0prws
PsFEx1kSZHxPuCl3/L7cZSTJ3ZrNcdHtcqiGHX4zR3AJ8Vy8dB/w9ip3IDE6+/8L
dujQ2kWHOYAKoQ7+pV8qzfBSVs07COFm73bz7omasZaHPsGH9cmTbgGZSJiUAo36
jAK27hnXSQzqD2Jtmr95wAVJk2PYxtgsCbGFrE1STj9ZHp1OEoZqAdnlOKQEz1S0
ZfzdAMnD2ntpROVrvEEuLT68oePoXgwlG+1C4njPlpwCb0WlHfCM60RcllU=
-END RSA PRIVATE KEY-
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upgrading OpenSSL
Hi Steve, > Have you recompiled the application? Some structures have changed between > OpenSSL 0.9.8 and 1.0.2 so you'll get problems with applications (or an > ENGINE) compiled against the wrong headers. In a build VM, both the TLS application and Racoon2 is compiled against freshly compiled OpenSSL 1.0.2L > If that isn't the problem then what is "md" set to? In the TLS application I only use SHA256, but in Racoon2 I can see it requesting SHA1 (in gdb). Thanks for your time LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upgrading OpenSSL
The upgrade is now working fine in one of the applications which make TLS connections. I can see the engine functions being called when some action (sign/verify) which require the privatekey. However, this engine is also used in a patched version of Racoon2. In one of the files (crypto_openssl.c) a function is called by the IKE daemon (iked) during setup with: : EVP_SignInit(, md); EVP_SignUpdate(, octets->v, octets->l); EVP_SignFinal(, (unsigned char*)sig->v, , pkey); : With the upgraded OpenSSL v1.0.2, the last function now fails with the error: 2017-08-28 15:44:14 [INTERNAL_ERR]: crypto_openssl.c:1238:eay_rsassa_pkcs1_v1_5_sign(): RSA_sign failed: 30972:error:0606B06E:digital envelope routines:EVP_SignFinal:wrong public key type:p_sign.c:123: Q: I assume it is looking for one of the missing parameters (p) in the RSA structure - correct? Q: If so, how did it work in v0.9.8? If I change the first command to: EVP_SignInit_ex(, md, engine); Then it segfaults in the "SignFinal" command :( The engine is dynamically loaded the same way in both my TLS connection application and in the Racoon2 application. Thanks for your time - any help is appreciated! Leon Brits System Engineer Mobile: +27 84 250 2855 [cid:image001.png@01D32016.91CF07F0] 76 Regency Drive Route 21 Corporate Park Irene 0157 Tel +27 12 678 9740 (ext. 9767) | Fax +27 12 345 2561 www.parsec.co.za<http://www.parsec.co.za> [cid:image002.png@01D32016.91CF07F0] From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Leon Brits Sent: 28 August 2017 08:08 AM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Upgrading OpenSSL Thanks for the help. I've come to learn that my problem is the HSM. It removes the RSA values p,q and d from the EVP key before returning it. This is normal since it is protecting the key by keeping it in the HSM - duh. Anyway so, I cannot use it as a normal key. "Live and learn" So this bring me to the next question: Is there any changes I need to make in the OpenSSL Engine for my upgrade (0.9.8 -> 1.0.2) to be complete? Regards, Leon Brits System Engineer Mobile: +27 84 250 2855 [cid:image001.png@01D32016.91CF07F0] 76 Regency Drive Route 21 Corporate Park Irene 0157 Tel +27 12 678 9740 (ext. 9767) | Fax +27 12 345 2561 www.parsec.co.za<http://www.parsec.co.za> [cid:image002.png@01D32016.91CF07F0] From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Leon Brits Sent: 23 August 2017 11:52 AM To: openssl-dev@openssl.org<mailto:openssl-dev@openssl.org> Subject: [openssl-dev] Upgrading OpenSSL Hi all, I am task to update two machines from v0.9.8z to v1.0.2 (since it is LTS). With the minimal changes, I've been able to get the application on the machines to compile with the newer version and generate RSA 4096 key pairs. The applications are able to successfully use their respective private keys and certificates to establish TLS connection between them. However, when I used the CLI to check a dumped privatekey i got the following output: % openssl rsa -check -in privkey.pem unable to load Private Key 1995859152:error:0D078079:asn1 encoding routines:ASN1_ITEM_EX_D2I:field missing:tasn_dec.c:489:Field=d, Type=RSA 1995859152:error:04093004:rsa routines:OLD_RSA_PRIV_DECODE:RSA lib:rsa_ameth.c:121: 1995859152:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private key decode error:evp_pkey.c:92: 1995859152:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib:pem_pkey.c:141: Any suggestions at what is wrong with the key? Note that an ID is stored in the RSA extended data since the private key may be stored in HSM. Thanks for your time LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upgrading OpenSSL
Thanks for the help. I've come to learn that my problem is the HSM. It removes the RSA values p,q and d from the EVP key before returning it. This is normal since it is protecting the key by keeping it in the HSM - duh. Anyway so, I cannot use it as a normal key. "Live and learn" So this bring me to the next question: Is there any changes I need to make in the OpenSSL Engine for my upgrade (0.9.8 -> 1.0.2) to be complete? Regards, Leon Brits System Engineer Mobile: +27 84 250 2855 [cid:image001.png@01D31FD4.CD5D06B0] 76 Regency Drive Route 21 Corporate Park Irene 0157 Tel +27 12 678 9740 (ext. 9767) | Fax +27 12 345 2561 www.parsec.co.za<http://www.parsec.co.za> [cid:image002.png@01D31FD4.CD5D06B0] From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Leon Brits Sent: 23 August 2017 11:52 AM To: openssl-dev@openssl.org Subject: [openssl-dev] Upgrading OpenSSL Hi all, I am task to update two machines from v0.9.8z to v1.0.2 (since it is LTS). With the minimal changes, I've been able to get the application on the machines to compile with the newer version and generate RSA 4096 key pairs. The applications are able to successfully use their respective private keys and certificates to establish TLS connection between them. However, when I used the CLI to check a dumped privatekey i got the following output: % openssl rsa -check -in privkey.pem unable to load Private Key 1995859152:error:0D078079:asn1 encoding routines:ASN1_ITEM_EX_D2I:field missing:tasn_dec.c:489:Field=d, Type=RSA 1995859152:error:04093004:rsa routines:OLD_RSA_PRIV_DECODE:RSA lib:rsa_ameth.c:121: 1995859152:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private key decode error:evp_pkey.c:92: 1995859152:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib:pem_pkey.c:141: Any suggestions at what is wrong with the key? Note that an ID is stored in the RSA extended data since the private key may be stored in HSM. Thanks for your time LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Upgrading OpenSSL
Hi all, I am task to update two machines from v0.9.8z to v1.0.2 (since it is LTS). With the minimal changes, I've been able to get the application on the machines to compile with the newer version and generate RSA 4096 key pairs. The applications are able to successfully use their respective private keys and certificates to establish TLS connection between them. However, when I used the CLI to check a dumped privatekey i got the following output: % openssl rsa -check -in privkey.pem unable to load Private Key 1995859152:error:0D078079:asn1 encoding routines:ASN1_ITEM_EX_D2I:field missing:tasn_dec.c:489:Field=d, Type=RSA 1995859152:error:04093004:rsa routines:OLD_RSA_PRIV_DECODE:RSA lib:rsa_ameth.c:121: 1995859152:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private key decode error:evp_pkey.c:92: 1995859152:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib:pem_pkey.c:141: Any suggestions at what is wrong with the key? Note that an ID is stored in the RSA extended data since the private key may be stored in HSM. Thanks for your time LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] FIPS validation
Hi SteveM, Yes we are copycats - thanks for making it possible. I was also amazed when I received the email very close to our final source code review and operational testing phase. I've used the fips_algv tests suite to have the algorithms validated (#3768) using this lab but I cannot see how to use it to "induce" and error in the FIPS module. I think they want to see that we go into an error state in such cases. Should I use gdb to step into the module and alter return values? Can I compile the FIPS module like that without breaking the compile rules? Thanks for your time LJB > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of > Steve Marquess > Sent: 05 September 2016 01:33 PM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] FIPS validation > > On 09/05/2016 02:09 AM, Leon Brits wrote: > > The FIPS validation company says: > > > > > > > > "The tests I am most interested in are the failure cases, where you > > induce an error in each of the power-on self-tests and conditional > > tests (i.e, continuous RNG test, pairwise consistency test)." > > > > > > > > Can anybody tell me how I can induce these errors? > > > > > > > > I do run the FIPS_selftest() function on demand and the POST has never > > failed when I switch to FIPS mode with FIPS_mode_set(). > > > > > > > > Thanks > > > > LJB > > > > > > > > So you're trying to obtain your own copycat validation based on the > OpenSSL FIPS Object Module code (as many vendors have done). > > Since that has been done so many times your unnamed FIPS validation > consultant or test lab should already be familiar enough with the OpenSSL > FIPS module code to immediately know the answer to this question, rather > than asking it of you (that's a hint). > > Most labs or consultants would direct you to the "fips_test_suite" test > harness (also called from fips_algvs), which is included in the OpenSSL > FIPS module tarballs and documented in the User Guide: > > https://www.openssl.org/docs/fips/UserGuide-2.0.pdf > > Test labs typically just run "fips_algv fips_test_suite" for the > functional testing, as it was designed for exactly that purpose. > > -Steve M. > > -- > Steve Marquess > OpenSSL Validation Services, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marqu...@openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] FIPS validation
The FIPS validation company says: "The tests I am most interested in are the failure cases, where you induce an error in each of the power-on self-tests and conditional tests (i.e, continuous RNG test, pairwise consistency test)." Can anybody tell me how I can induce these errors? I do run the FIPS_selftest() function on demand and the POST has never failed when I switch to FIPS mode with FIPS_mode_set(). Thanks LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] DRBG entropy
Kurt, > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of > Kurt Roeckx > Sent: 30 July 2016 12:19 AM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] DRBG entropy > Have you tried running NIST's software > (https://github.com/usnistgov/SP800-90B_EntropyAssessment) > yourself? Can you run it in verbose mode and give the results of all the > tests it ran? Yes, this is the test that indicated an entropy of 2b/B. I ran the test on 1M and 4M and the result was 2.19 and 2.35 respectively. The 4MB file test output is appended below. Now in the OpenSSL UG2.0 section 6.1.1 a paragraph states: "Now suppose we have a low grade entropy source which provides just 1 bit of entropy per byte. Again assume it is uniform (e.g. we don't get 8 bits of entropy in byte 1 and nothing in the next 7). Again let's have a block size of 16 bytes. This time to get 256 bits of entropy the source must provide it in a 256 byte buffer. An extra block is required which makes 272 bytes but because we only have 1 bit of entropy per byte it just needs to supply 272 bits of entropy." Am I correct to state that for a tested entropy source of 2b/B and the same assumptions as in the paragraph, I need to return 8 blocks of 16B each in my get_entropy() callback? Thanks LJB ** Read in file randomness.bin, 4194304 bytes long. Dataset: 4194304 8-bit symbols, 256 symbols in alphabet. Output symbol values: min = 0, max = 255 Running entropic statistic estimates: - Most Common Value Estimate: p(max) = 0.00411016, min-entropy = 7.92659 - Collision Estimate: p(max) = 0.00873199, min-entropy = 6.83947 - Markov Estimate (map 6 bits): p(max) = 9.71537e-228, min-entropy = 5.89156 - Compression Estimate: p(max) = 0.00743246, min-entropy = 7.07194 - t-Tuple Estimate: p(max) = 0.00495551, min-entropy = 7.65675 - LRS Estimate: p(max) = 0.155747, min-entropy = 2.68272 Running predictor estimates: Computing MultiMCW Prediction Estimate: 99 percent complete Pglobal: 0.003997 Plocal: 0.001358 MultiMCW Prediction Estimate: p(max) = 0.00399729, min-entropy = 7.96676 Computing Lag Prediction Estimate: 99 percent complete Pglobal: 0.004009 Plocal: 0.001358 Lag Prediction Estimate: p(max) = 0.00400879, min-entropy = 7.96262 Computing MultiMMC Prediction Estimate: 99 percent complete Pglobal: 0.004934 Plocal: 0.195448 MultiMMC Prediction Estimate: p(max) = 0.195448, min-entropy = 2.35514 Computing LZ78Y Prediction Estimate: 99 percent complete Pglobal: 0.004034 Plocal: 0.195448 LZ78Y Prediction Estimate: p(max) = 0.195448, min-entropy = 2.35514 --- min-entropy = 2.35514 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] DRBG entropy
John, > Let's play a guessing game. I provide a hardware-based random number > generator of my choosing. It produces a stream of bytes. It has an > entropy density greater than 2.35 bits per byte. This claim is consistent > with all the usual tests, but it is also more than that; it is not just > "apparent" entropy or an upper bound based on testing, but real honest-to- > goodness Boltzmann entropy. The bytes are IID (independent and > identically distributed). The design and implementation are open to > inspection. > > On each move in this game, I try to predict the exact value of the next > byte. Every time I succeed, you pay me a dollar; every time I fail, I pay > you a dollar. We play at least 100 moves, to minimize stray fluctuations. > > The point is, if you think entropy is a good measure of resistance to > guessing, then you should be eager to play this game, expecting a huge > profit. > > Would anybody like to play? Brilliant analogy! > 1a) I assume the idea that "2 is too low" comes from the FIPS lab. Yes > 1b) I assume the designer's boss doesn't directly care about this, >so long as the FIPS lab is happy. Yes > 1c) This requirement has little if any connection to actual security. Correct - it's about perception of the client > 2a) I assume the FIPS lab doesn't care exactly which chip is used. They did request information about its working which FDK where not willing to divulge. > 2b) I assume this requirement comes from the boss. Correct > 2c) This requirement has little if any connection to actual security. Correct > > I am not allowed to use a hash with the DRBGs (FIPS lab and SP800-90B > > section 8.4), > > Where's That From? Section 8.4 says nothing about hashes. It's about > health testing. The hash doesn't interfere with health testing, unless > the implementation is badly screwed up. > > Furthermore, in sections 8.2 and 8.3, and elsewhere, there is explicit > consideration of "conditioning", which is what we're talking about. > > 3a) Does this requirement really come from the FIPS lab? It >certainly doesn't come from SP800-90B as claimed. I will ask them the question. > 3c) This requirement has nothing to do with actual security. > > > It is still get the feeling that this is a "best effort" thing and > > that nobody can actually proof what is correct. > > Where's That From? My opinion (after working on this project) > Two answers: > -- My friend Dilbert says you should do that, in order to make the > pointy-haired boss happy. Wise old Dilbert > -- You should not, however, imagine that it provides actual security. Understood. > That means the chip design is broken in ways that the manufacturer does > not understand. The mfgr data indicates it "should" be much better than > that: > http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf Agreed. That is why it was selected (from what I heard). > The mfgr has not analyzed the thing properly, and nobody else will be able > to analyze it at all. The block diagram in the datasheet is a joke: > http://www.fdk.com/cyber-e/pdf/HM-RAE106.pdf#Page=9 > > > I must however make use of this chip. > > My friend suggests you XOR the chip output with a decent, well- understood > HRNG. That way you can tell the pointy-haired boss that you "make use of > this chip". I wish I could, but my only option to solve this now is using software. Thanks alot for your reply and time taken to help. Much appreciated LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] DRBG entropy
Paul, > I probably should have mentioned this in my earlier message, but the > exponential example is valid for the NSIT SP800-90B non-IID tests too: > 5.74889 bits per byte of assessed entropy. Again about as good a result > as the tests will ever produce given the ceiling of six on the output. > There is still zero actual entropy in the data. The tests have massively > over estimated. I am just trying to get our device validated, and am not in a position to discuss the Labs test methodologies or the intrinsic math behind it. I thought that by using the NDRNG chip the entropy would not be a problem. Should have done my homework better. Thanks for your time LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] DRBG entropy
Thanks for the helping me understand the whole entropy thing better. It is still get the feeling that this is a "best effort" thing and that nobody can actually proof what is correct. I am probably just bringing the math down to my level - sorry. With that said for validation I still need to be sure that I give the required entropy back from the OpenSSL callback. Now since I am not allowed to use a hash with the DRBGs (FIPS lab and SP800-90B section 8.4), can you please confirm that, with a source of raw 2b/B entropy data, I need to return 4 times the data from the callback function? Regards, Leon Brits System Engineer Parsec Work +27 12 678 9740 Cell +27 84 250 2855 Email le...@parsec.co.za www.parsec.co.za/disclaimer > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of > Paul Dale > Sent: 28 July 2016 02:33 AM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] DRBG entropy > > John's spot on the mark here. Testing gives a maximum entropy not a > minimum. While a maximum is certainly useful, it isn't what you really > need to guarantee your seeding. > > A simple example which passes the NIST SP800-90B first draft tests with > flying colours: > > seed = π - 3 > for i = 1 to n do > seed = frac(exp(1+2*seed)) > entropy[i] = 256 * frac(2^20 * seed) > > where frac is the fractional part function, exp is the exponential > function. > > I.e. start with the fractional part of the transcendental π and iterate > with a simple exponential function. Take bits 21-28 of each iterate as a > byte of "entropy". Clearly there is really zero entropy present: the > formula is simple and deterministic; the floating point arithmetic > operations will all be correctly rounded; the exponential is evaluated in > a well behaved area of its curve where there will be minimal rounding > concerns; the bits being extracted are nowhere near where any rounding > would occur and any rounding errors will likely be deterministic anyway. > > Yet this passes the SP800-90B (first draft) tests as IID with 7.89 bits of > entropy per byte! > > IID is a statistical term meaning independent and identically distributed > which in turn means that each sample doesn't depend on any of the other > samples (which is clearly incorrect) and that all samples are collected > from the same distribution. The 7.89 bits of entropy per byte is pretty > much as high as the NIST tests will ever say. According to the test > suite, we've got an "almost perfect" entropy source. > > > There are other test suites if you've got sufficient data. The Dieharder > suite is okay, however the TestU01 suite is most discerning I'm currently > aware of. Still, neither will provide an entropy estimate for you. For > either of these you will need a lot of data -- since you've got a hardware > RNG, this shouldn't be a major issue. Avoid the "ent" program, it seems > to overestimate the maximum entropy present. > > > John's suggestion of collecting additional "entropy" and running it > through a cryptographic has function is probably the best you'll be able > to achieve without a deep investigation. As for how much data to collect, > be conservative. If the estimate of the maximum entropy is 2.35 bits per > byte, round this down to 2 bits per byte, 1 bit per byte or even ½ bit per > byte. The lower you go the more likely you are to be getting the entropy > you want. The trade-off is the time for the hardware to generate the data > and for the processor to hash it together. > > > Pauli > -- > Oracle > Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 > 3031 7217 Oracle Australia > > -Original Message- > From: John Denker [mailto:s...@av8n.com] > Sent: Wednesday, 27 July 2016 11:40 PM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] DRBG entropy > > On 07/27/2016 05:13 AM, Leon Brits wrote: > > > > I have a chip (FDK RPG100) that generates randomness, but the > > SP800-90B python test suite indicated that the chip only provides > > 2.35 bits/byte of entropy. According to FIPS test lab the lowest value > > from all the tests are used as the entropy and 2 is too low. I must > > however make use of this chip. > > That's a problem on several levels. > > For starters, keep in mind the following maxim: > Testing can certainty show the absence of entropy. > Testing can never show the presence of entropy. > > That is to say, you have ascertained that 2.35 bits/byte is an /upper > bound/ on the entropy density coming from the chip. If you care about > se
Re: [openssl-dev] DRBG entropy
John, Thanks for your reply. The SP800-90B test has different types of test but the test with the lowest output is used as the maximum entropy capability of the chip. That is how I understand it from the FIPS lab. For the FIPS validation, using a NDRNG, that source must feed the DRBG directly (FIPS lab) and not from something like the PRNG. I use seed the /dev/random from the NDRNG and then source from the PRNG, but that is not allowed for DRBGs. Again I hope I understand them correct. They said I must look at the OpenSSL user guide v2.0 para 6.1.1 where low entropy sources are discussed. Now, I already make use of the "get_entropy" function for my DRBG implementation. I use to source from the PRNG in that callback. I must now get it directly from my entropy source, which give rise to my question of how to ensure that I have high entropy of data before the callback exits. Regards, LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] DRBG entropy
Hi all, I have a chip (FDK RPG100) that generates randomness, but the SP800-90B python test suite indicated that the chip only provides 2.35 bits/byte of entropy. According to FIPS test lab the lowest value from all the tests are used as the entropy and 2 is too low. I must however make use of this chip. Looking at the paragraph in the User Guide 2.0 where low entropy sources are discussed and have some additional questions: 1. In my DRBG callback for entropy (function get_entropy in the guide), I simply used our chip as the source (the driver reading from the chip, makes it available at /dev/hwrng). Now that I've come to learn that the chip's entropy is too low, how do I ensure that this callback exists with a buffer of acceptable entropy? 2. Should I just return a 4 times larger buffer? Wat if that is larger than the "max_len"? 3. Can the DRBG repeatedly call the callback until the entropy is high enough? Your advice is appreciated Regards LJB -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Bitlocker
Hi all, I have a PC which acts like a USB smartcard on which I have OpenSSLv1.0.1e to simulate the smartcards crypto operations. I use it to sign/verify/encrypt/decrypt etc. and had no problem using Windows to login and sign/verify emails for instance. Recently I tried bitlocker and got the following error: Function call 'EVP_PKEY_decrypt()' failed! (error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02). The part in brackets was returned by OpenSSL. Can anybody shed some light on what possibly I can be doing wrong with regards to the padding. I do implement PKCS1 and PSS. I've written our CSP/KSP for this PC and as I said it works fine with other Windows applications. Thanks for your time LJB ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Diffie Hellman and FIPS
Hi all, For a security policy, based on SP800-132 (page 8) one must state how DH derived keys are used. Currently the secret derived between our FIPS module (level 3) and the Computer is used as is and I state in table 5 of the security profile option 1a of SP800-132. Looking at the latest FIPS1402IG I see on page 159 for scenario 3 (which is applicable to our module), that one must derive the key from the secret via a KDF. Right? On the computer, we only have very limited cryptographic options and we wrote the DH derivation. On the module we can use the OpenSSL PBKDF2 and I was wondering/hoping that running the derived secret thru a PBKDF would be the same as a normal KDF except that the password would be the secret key. Any comment on this thinking? Thanks LJB
RE: RSA [FIPS 186-4] issue
JDM, Leon Brits wrote I am in no way capable of writing such a patch and was hoping that someone is willing to share. To be more specific I need a patch that will change the key generation from: d = e-1 mod((p-1)(q-1)) to this: d = e-1 mod(LCM(p-1, q-1)) We’re also pursuing a patch to RSA Key Generation. Leon, are you saying that you believe this is the change that is necessary in order for it to be validated? What makes you think that? I think you’re further along in the process than we are and I’d like to learn from what you’ve found. The information I've given comes from a discussion our validation company had with someone at NIST. It seems to be the crux of the matter for NIST to go from 186-2 to 4. I am not sure what else may need to be changed.
RSA [FIPS 186-4] issue
Hi all, We use the OpenSSL FIPS Object Module v.2.0, but are not allowed anymore (as of the start of this year) to submit new product for validation because the RSA implementation is only FIPS 186-2 compliant. Based on extensive review and research it seems to be possible to patch the RSA key generation to be FIPS 186-4 compliant and apparently (correct me if I am wrong) the sign/verify is close enough to FIPS 186-4 to pass. I am in no way capable of writing such a patch and was hoping that someone is willing to share. To be more specific I need a patch that will change the key generation from: d = e-1 mod((p-1)(q-1)) to this: d = e-1 mod(LCM(p-1, q-1)) I would appreciate any comment about the statement that the RSA implementation for sign and verify will pass the CAVP testing for FIPS 186-4. As usual thanks for your help Regards, LJB
RE: Thunderbird decrypt issue
Steve, As usual I do not know what I would do without you on this list. The code had a logic error for when to en-/disable the padding depending on the mechanism. Thanks a mil. LJB __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Thunderbird decrypt issue
Hi, I have a problem with Thunderbird which works via the cryptoki to our device which makes use of OpenSSL. Thunderbird passes ciphertext which falls exactly on the blocksize boundary. I translate the cryptoki DecryptUpdate() call to the OpenSSL DecryptUpdate(). OpenSSL retains the last block of ciphertext and return the first (N-1)*blocksize of plaintext. Next I expect a cryptoki DecryptFinal() call so as to decrypt and return the last block of plaintext. Thunderbird instead expected _all_ the plaintext to be returned from the DecryptUpdate() call (it seems). In a discussion with them, they mention that they determined that the ciphertext is not padded and hence expected this behaviour. There code now fails because the length of the plaintext returned by my OpenSSL DecryptUpdated() does not match the length of the ciphertext send to it. Am my understanding of the OpenSSL DecryptUpdate() the wrong: Is it possible to decrypt all the ciphertext and return all the plaintext or must one always call the DecryptFinal() after any and all DecryptUpdate() function calls? Thanks for your time LJB
RE: Diffie Hellman question
Thanks for your reply. Can you provide the source for the problem that you're running into? I cannot give the source code as it is now, but I will create a new test case using only the OpenSSL calls I make in this situation. I will post it or report back if I find an error. Regards, LJB
RE: Diffie Hellman question
Thanks for your reply. Are you, by chance, trying to derive secret from keypairs generated with *different* parameters? This cannot possibly work, of course. Both sides keypairs must be generated for same DH parameters. OK, I guess the larger prime numbers of each group makes there parameters *different*. Thanks, LJB
Diffie Hellman question
Hi all, In a test I have three DH key pairs generated from the IKE groups 14,15 and 16 paramters. When I want to derive a secret and I use the 2048 bit private key then the derivation fails if I use the 3072 or 4096 bit public key. But if I derive using the 3072 bit private key then I can derive using the 2048 and 3072 bit public key. When I use the 4096 bit private key I can derive with any of the public keys. The error I get when it fails is from the EVP_PKEY_derive() function: error:05066066:Diffie-Hellman routines:COMPUTE_KEY:invalid public key It seems the private key must be the same or larger to succeed. Is this correct: Can the public key not be larger than the private key? Regards, LJB
EVP_DecryptUpdate with multiple parts
Hi all, I've been trying to test my working code for the corner case when data arrives which is smaller than the key size, and I am having problems. I must be making a simple mistake, but would like some help please. My test code simply takes an encrypted buffer and sends it piece by piece to DecryptUpdate() and follows it with a DecryptFinal() which gives the error wrong file block length. I dump each piece and my code does seem to send every bit of data. So for AES 128 ECB Encrypt the word Hello, which produce cipher text of 16 byte. I hex dump it as: 10 30 6e 74 fe ed 8e 42 54 38 84 21 d1 3d 2d 14 Next I send it piece by piece to DecryptUpdate(). (two pieces, 8 bytes each). For this mode no data is returned: 10 30 6e 74 fe ed 8e 42 and 54 38 84 21 d1 3d 2d 14 As you can see the hex value of the pieces matches that of the cipher text. With no more data to set, I call DecryptFinal() and get: error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length I know this is some stupid error, but please help me out of my misery Thanks LJB
EVP DSA parameters
Hi all, I generate my DSA key pairs using the EVP API. The older API call DSA_generate_parameters() allowed me to set the seed value. With the EVP API this is automatically generated (it seems). Windows however require this seed value when it exports the Public key. So how can I get this seed value? Is it fixed? Regards, LJB
FIPS certification
Hi all, I've used the FIPS Object Module v2.0.2 in a product which need to be FIPS 140-2 certified. One of the steps in this process is to certify the module algorithms on our platform since it is not one of the platforms which are covered by certificate #1747. I have all these questionnaires from the certification lab about the algorithms and some of the answers I simply do not know. E.g. for RSAPSS they want to know what the salt length is. As far as I know this is dynamically determined based on the modulus size and digest (correct?). Anyway, I do not know what value to fill in as an answer. So is it possible to get access to these algorithm documents which OpenSSL also had to complete for their certification? Regards, LJB
RE: FIPS certification
Steve, We are talking past each other - sorry for that but that is the way people like me get to understand these things. First of we have not changed any code of the FIPS Object Module. We simply do not use all of the algorithms based on requirements. The application linking the libcrypto.so, enforce that only required and allowed cryptographic calls is made to the Module. So, if I understand you (or maybe again not), we must test everything in the Module even if we do not use them? And this is why the new directives will give me problems - right? Background: We were hoping to use your certification of the algorithms as part of our products validation. Using your certificate numbers in our SP in section 2 for Cryptographic Functionality. I thought that is the point of your certification efforts. The lab said we cannot due to the different platform (we have Linux 2.6 on ARMv5tel), but that we simply have to run the algorithm tests on our platform to get our own certification for the algorithms we use. This is an extra cost but less than a complete certification like when we changed code in the Module. So in preparation for these tests I also need to fill in the forms describing each algorithm and their modes. Thanks LJB __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Randomness generation standards
Hi all, I am required to implement the four DRBGs specified in SP 800-90 (HASH, HMAC, CTR, DUAL_EC). I previously received help from this group on that and it works just fine. The client however also required the following ...and ANS X9.62-2005 (HMAC) on the randomness. I am unsure on how to enforce this via the API. What I did was to use the NID_X9_62_prime256v1 curve on the DUAL_EC DRBG. Is this ok? I am confused since the requirement states in brackets at the end: HMAC. Can anybody direct me to something I should have read. Unfortunately I do not have access to the X9 specs. Regards Leon Brits
RE: FIPS verification for AES XTS
I also need to test CCM and GCM mode and realized that I cannot use the CLI for that. So, I started writing a program to do the tests (wanted to avoid this). The XTS works with the data from the one file, but I still do not understand how to make use of the data unit sequence number - anybody!? Also the KAT for the CCM has for example the following information: [Alen = 0, Plen = 0, Nlen = 13, Tlen = 4] Key = 4bb3c4a4f893ad8c9bdc833c325d62b3 Count = 30 Nonce = 5a8aa485c316e9403aff859fbb Adata = 00 CT = 90156f3f Result = Pass Payload = 00 Can anybody please explain to me how I must use the parameters. For instance what is the plaintext? Reagrds, LJB
FIPS verification for AES XTS
Hi, I need to perform some Known-Answer-Tests with every start-up of my system. For this I use the NIST KAT files. However for AES-XTS, one of the files uses the tweak value input of data unit sequence number. Can anybody help me to understand howto use that value from the commandline. The other tweak value input is a 128 hex value which I simply use as a hex IV on the command line and it seems to perform correctly. The test succeeds. The data unit sequence number is a decimal value between 0 and 255. Any suggestions? Thanks LJB Here is my commandline for testing (encrypt and decrypt) the 128 bit hex value: $ echo -n $CTEXT | xxd -p -r | openssl enc $ACTION $CIPHER -nosalt -K $KEY -iv $I -nopad | xxd -p where: KEY=1ea661c58d943a0e4801e42f4b0947149e7f9f8e3e68d0c7505210bd311a0e7cd6e13ffdf2418d8d1911c004cda58da3d619b7e2b9141e58318eea392cf41b08 I=adf8d92627464ad2f0428e84a9f87564 PTEXT=2eedea52cd8215e1acc647e810bbc3642e87287f8d2e57e36c0a24fbc12a202e CTEXT=cbaad0e2f6cea3f50b37f934d46a9b130b9d54f07e34f36af793e86f73c6d7db CIPHER=-aes-256-xts ACTION=-e or -d In the second test file for 256bit, the value of I is a DataUnitSeqNumber (with matching key and other text).
RE: AES-XTS problem in non-FIPS mode
Ok, some weirdness happening here... I've selected to test with option 2 and recompiled my openssl 1.0.1e withOUT fips in ./config fips. $ openssl version OpenSSL 1.0.1e 11 Feb 2013 I've verified that the AES-XTS cipher is present with: $ openssl list-cipher-algorithms In my app I resolve the NID_aes_256_xts to a name with OBJ_nid2sn() and get the same name as in the list above. However when I call EVP_get_cipherbyname() with this name I get a NULL. I've never had an error with this in the FIPS compiled module. This just does not seem possible as an error, so any ideas on what may be wrong with my system? I've working in VirtualBox VM with a default installed Ubuntu 12.04.02. Thanks LJB -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 26 August 2013 03:23 PM To: openssl-dev@openssl.org Subject: Re: AES-XTS problem in non-FIPS mode On Mon, Aug 26, 2013, Leon Brits wrote: I am using a FIPS compiled OpenSSL and I switch between FIPS and non- FIPS mode with the FIPS_mode_set() API call. The selection is made by the application linked to my library based on its configuration. That's weird. It should be using exactly the same algorithm implementation then. Assuming there's no problem with your code the only thing I can think of is some inconsistency between FIPS and non-FIPS initialisation of EVP. To test that have a look in crypto/evp/evp_enc.c in OpenSSL 1.0.1 for the lines that check FIPS_mode(). Change them so they're always caled and not just if FIPS_mode() is non-zero. If possible also try OpenSSL 1.0.1 without the fips compilation option: it will then use its internal implementation and not the one in the FIPS module. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: AES-XTS problem in non-FIPS mode
OK, sorry this stupid error has been resolved. There was some openssl init code which got disabled when I disabled lines of source for FIPS mode. The problem however still persists for me even with this OpenSSL which has been compiled without fips. I will continue looking at my code. Thanks LJB -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Leon Brits Sent: 27 August 2013 12:08 PM To: openssl-dev@openssl.org Subject: RE: AES-XTS problem in non-FIPS mode Ok, some weirdness happening here... I've selected to test with option 2 and recompiled my openssl 1.0.1e withOUT fips in ./config fips. $ openssl version OpenSSL 1.0.1e 11 Feb 2013 I've verified that the AES-XTS cipher is present with: $ openssl list-cipher-algorithms In my app I resolve the NID_aes_256_xts to a name with OBJ_nid2sn() and get the same name as in the list above. However when I call EVP_get_cipherbyname() with this name I get a NULL. I've never had an error with this in the FIPS compiled module. This just does not seem possible as an error, so any ideas on what may be wrong with my system? I've working in VirtualBox VM with a default installed Ubuntu 12.04.02. Thanks LJB -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 26 August 2013 03:23 PM To: openssl-dev@openssl.org Subject: Re: AES-XTS problem in non-FIPS mode On Mon, Aug 26, 2013, Leon Brits wrote: I am using a FIPS compiled OpenSSL and I switch between FIPS and non- FIPS mode with the FIPS_mode_set() API call. The selection is made by the application linked to my library based on its configuration. That's weird. It should be using exactly the same algorithm implementation then. Assuming there's no problem with your code the only thing I can think of is some inconsistency between FIPS and non-FIPS initialisation of EVP. To test that have a look in crypto/evp/evp_enc.c in OpenSSL 1.0.1 for the lines that check FIPS_mode(). Change them so they're always caled and not just if FIPS_mode() is non-zero. If possible also try OpenSSL 1.0.1 without the fips compilation option: it will then use its internal implementation and not the one in the FIPS module. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: AES-XTS problem in non-FIPS mode
OK, found the error. I simply did not give a double size key to the cipher as required. That would explain why it sometimes worked. Sorry for the trouble Thanks for your time and support LJB -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Leon Brits Sent: 27 August 2013 02:48 PM To: openssl-dev@openssl.org Subject: RE: AES-XTS problem in non-FIPS mode OK, sorry this stupid error has been resolved. There was some openssl init code which got disabled when I disabled lines of source for FIPS mode. The problem however still persists for me even with this OpenSSL which has been compiled without fips. I will continue looking at my code. Thanks LJB -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Leon Brits Sent: 27 August 2013 12:08 PM To: openssl-dev@openssl.org Subject: RE: AES-XTS problem in non-FIPS mode Ok, some weirdness happening here... I've selected to test with option 2 and recompiled my openssl 1.0.1e withOUT fips in ./config fips. $ openssl version OpenSSL 1.0.1e 11 Feb 2013 I've verified that the AES-XTS cipher is present with: $ openssl list-cipher-algorithms In my app I resolve the NID_aes_256_xts to a name with OBJ_nid2sn() and get the same name as in the list above. However when I call EVP_get_cipherbyname() with this name I get a NULL. I've never had an error with this in the FIPS compiled module. This just does not seem possible as an error, so any ideas on what may be wrong with my system? I've working in VirtualBox VM with a default installed Ubuntu 12.04.02. Thanks LJB -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 26 August 2013 03:23 PM To: openssl-dev@openssl.org Subject: Re: AES-XTS problem in non-FIPS mode On Mon, Aug 26, 2013, Leon Brits wrote: I am using a FIPS compiled OpenSSL and I switch between FIPS and non- FIPS mode with the FIPS_mode_set() API call. The selection is made by the application linked to my library based on its configuration. That's weird. It should be using exactly the same algorithm implementation then. Assuming there's no problem with your code the only thing I can think of is some inconsistency between FIPS and non-FIPS initialisation of EVP. To test that have a look in crypto/evp/evp_enc.c in OpenSSL 1.0.1 for the lines that check FIPS_mode(). Change them so they're always caled and not just if FIPS_mode() is non-zero. If possible also try OpenSSL 1.0.1 without the fips compilation option: it will then use its internal implementation and not the one in the FIPS module. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
AES-XTS problem in non-FIPS mode
Hi all, I've noticed in my unit tests that, for the same code path, when I encrypt an decrypt the data read from a file which is 959120 bytes in size, then the FIPS mode of AES-XTS works every time, while the non-FIPS mode fails some times. It fails frequently but seemingly random. I've seen another post about block sizes (4K and 32K) and I've tried smaller sizes but got the same result. I am using the EVP_Decrypt/Encrypt API calls and have an Openssl 1.0.1e compiled with FIPS canister v.2.0.2. The question is why does FIPS mode work correctly every time and not non-FIPS? Hope you can help. Leon Brits Senior Design Engineer [cid:image001.jpg@01CEA24B.21A82E40] Work +27 12 678 9740 Fax +27 12 678 9741 Cell +27 (84) 250 2855 Email le...@parsec.co.za mailto:le...@parsec.co.zaBuilding 10, Manhattan Office Park, 16 Pieter Street, Centurion Disclaimer http://www.parsec.co.za/disclaimer.phpinline: image001.jpg
RE: AES-XTS problem in non-FIPS mode
I am using a FIPS compiled OpenSSL and I switch between FIPS and non-FIPS mode with the FIPS_mode_set() API call. The selection is made by the application linked to my library based on its configuration. Thanks LJB -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 26 August 2013 01:26 PM To: openssl-dev@openssl.org Subject: Re: AES-XTS problem in non-FIPS mode On Mon, Aug 26, 2013, Leon Brits wrote: Hi all, I've noticed in my unit tests that, for the same code path, when I encrypt an decrypt the data read from a file which is 959120 bytes in size, then the FIPS mode of AES-XTS works every time, while the non-FIPS mode fails some times. It fails frequently but seemingly random. I've seen another post about block sizes (4K and 32K) and I've tried smaller sizes but got the same result. I am using the EVP_Decrypt/Encrypt API calls and have an Openssl 1.0.1e compiled with FIPS canister v.2.0.2. The question is why does FIPS mode work correctly every time and not non-FIPS? When you say non-FIPS mode have you compiled OpenSSL with the fips configuration option but not set FIPS mode or have you not used fips? It makes a difference because different code paths are involved. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
CMAC with EVP
Hi all, I've been (re)implementing all the ciphers we use to make use of EVP structures. On the wiki (http://wiki.openssl.org/index.php/EVP_Key_and_Parameter_Generation) there is an example to use EVP_PKEY for CMAC. I am a bit confused on the intention of this: Basically, how do I use this generated key with the EVP_Encrypt/Decrypt Init/Update/Final functions since they require an EVP_CIPHER structure to work on the message data for which I want to calculate a tag. Thanks Leon
PKCS12 with multiple key pairs
Hi all, I want/need to create a PKCS12 file which contains more than one key pair and some CA certs. As far as I understand from the spec this is possible, but the OpenSSL API does not seem to support this, since only the CAs can be passed as a list: PKCS12 *PKCS12_create(char *pass, char *name, EVP_PKEY *pkey, X509 *cert, STACK_OF(X509) *ca, ) Help please! Thanks for your time Leon
RE: DRBGs questions
That's it! I've set the personalization size to match the value of entropy_blocklen passed when setting up the callbacks. Thanks Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 14 May 2013 08:05 PM To: openssl-dev@openssl.org Subject: Re: DRBGs questions On Tue, May 14, 2013, Leon Brits wrote: So, I've continued and assumed I can use the header files in the fips- 2.0 directory and added them to my code with: : #include ../fips-2.0/include/openssl/fips.h #include ../fips-2.0/include/openssl/fips_rand.h : All compile fine. When executing the test using NID_sha1 as the DRBG type, then FIPS_drbg_instantiate() fails. I can see that the DRBG successfully got and freed entropy data from my hardware source. So I guess it must be the personalization information given as part of the instantiation which is wrong. The fips test application simply gives it 10 bytes from a static array but I am not sure what the length sould be. The documentation says: If the personalisation string is of an invalid length for the DRBG mechanism a non-fatal error is returned. What does non-fatal error means? I assumed that the length must be 16 bytes (128 bits) since the NID_sha1 DRBG is 128 bit strong? It still fails. Any suggestions? (FIPS is enabled successfully) The parameters to the callback tell you how much data is required. Also you can't return the same data all the time as there is a sanity check for that which will return an error. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: DRBGs questions
Hi Stephen, Thanks for your reply. So I finished the code to create my own DRBGs, but on compile it fails to find the required headers. From the test code on the internet it seems that I need to include fips.h and/or fips_rand.h. Is this correct? These files are however not in the include directory created when I installed the FIPS compiled OpenSSL (/usr/local/ssl/include/openssl for Ubuntu). I found it in /usr/local/ssl/fips-2.0/include/openssl which is not in the system include path returned by my build system's pkg-config query for OpenSSL. Is it ok to just manually point to those two files or should the application rather compile against the headers files found under the 'fips-2.0/include/openssl' directory? Sorry if this is trivial question, but I just do not want to compromise the FIPSness of my setup. Regards, Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 13 May 2013 06:53 PM To: openssl-dev@openssl.org Subject: Re: DRBGs questions On Mon, May 13, 2013, Leon Brits wrote: Hi all, We have a chip (a RNG) which generates randomness at 250kbps and would like this to seed a customer selected type of DRBG so that the customer can get randomness which is FIPS certified. I've read the FIPS user guide to implement a structure to switch between the four types of DRBGs based on the customer selection. I've setup the getEntropy() callback functions per DRBG type context to read entropy data from 'n file pointer at which the RNG data is available. I will instantiate() and uninstantiate() a DRBGs based on the customer selection during initialization of my library. So my questions are: 1. How does the application now access the randomness (normal RAND_* commands)? If you set up the default DRBG to use your entropy gathering technique then calls to RAND_* will use it. 2. In my case, what is the purpose of FIPS_drbg_reseed() and FIPS_drbg_generate()? Should I provide a customer interface to them? Will they need it? These apply to the separate instantiations of a DRBG. If you just use the default DRBG then the calls are made automatically. If you want an independent DRBG then you have to use those calls to generate random data. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: DRBGs questions
So, I've continued and assumed I can use the header files in the fips-2.0 directory and added them to my code with: : #include ../fips-2.0/include/openssl/fips.h #include ../fips-2.0/include/openssl/fips_rand.h : All compile fine. When executing the test using NID_sha1 as the DRBG type, then FIPS_drbg_instantiate() fails. I can see that the DRBG successfully got and freed entropy data from my hardware source. So I guess it must be the personalization information given as part of the instantiation which is wrong. The fips test application simply gives it 10 bytes from a static array but I am not sure what the length sould be. The documentation says: If the personalisation string is of an invalid length for the DRBG mechanism a non-fatal error is returned. What does non-fatal error means? I assumed that the length must be 16 bytes (128 bits) since the NID_sha1 DRBG is 128 bit strong? It still fails. Any suggestions? (FIPS is enabled successfully) Leon Brits Senior Design Engineer -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Leon Brits Sent: 14 May 2013 11:26 AM To: openssl-dev@openssl.org Subject: RE: DRBGs questions Hi Stephen, Thanks for your reply. So I finished the code to create my own DRBGs, but on compile it fails to find the required headers. From the test code on the internet it seems that I need to include fips.h and/or fips_rand.h. Is this correct? These files are however not in the include directory created when I installed the FIPS compiled OpenSSL (/usr/local/ssl/include/openssl for Ubuntu). I found it in /usr/local/ssl/fips-2.0/include/openssl which is not in the system include path returned by my build system's pkg-config query for OpenSSL. Is it ok to just manually point to those two files or should the application rather compile against the headers files found under the 'fips-2.0/include/openssl' directory? Sorry if this is trivial question, but I just do not want to compromise the FIPSness of my setup. Regards, Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 13 May 2013 06:53 PM To: openssl-dev@openssl.org Subject: Re: DRBGs questions On Mon, May 13, 2013, Leon Brits wrote: Hi all, We have a chip (a RNG) which generates randomness at 250kbps and would like this to seed a customer selected type of DRBG so that the customer can get randomness which is FIPS certified. I've read the FIPS user guide to implement a structure to switch between the four types of DRBGs based on the customer selection. I've setup the getEntropy() callback functions per DRBG type context to read entropy data from 'n file pointer at which the RNG data is available. I will instantiate() and uninstantiate() a DRBGs based on the customer selection during initialization of my library. So my questions are: 1. How does the application now access the randomness (normal RAND_* commands)? If you set up the default DRBG to use your entropy gathering technique then calls to RAND_* will use it. 2. In my case, what is the purpose of FIPS_drbg_reseed() and FIPS_drbg_generate()? Should I provide a customer interface to them? Will they need it? These apply to the separate instantiations of a DRBG. If you just use the default DRBG then the calls are made automatically. If you want an independent DRBG then you have to use those calls to generate random data. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
DRBGs questions
Hi all, We have a chip (a RNG) which generates randomness at 250kbps and would like this to seed a customer selected type of DRBG so that the customer can get randomness which is FIPS certified. I've read the FIPS user guide to implement a structure to switch between the four types of DRBGs based on the customer selection. I've setup the getEntropy() callback functions per DRBG type context to read entropy data from 'n file pointer at which the RNG data is available. I will instantiate() and uninstantiate() a DRBGs based on the customer selection during initialization of my library. So my questions are: 1. How does the application now access the randomness (normal RAND_* commands)? 2. In my case, what is the purpose of FIPS_drbg_reseed() and FIPS_drbg_generate()? Should I provide a customer interface to them? Will they need it? Thanks for your time Regards Leon Brits
RE: RSA sign and verify
Hi List, I've implemented the sign of data using the EVP_DigestSign and Verify functions. The client however also require a function to sign exsiting digests calculated by Windows? From some post found on the internet it seems I should call EVP_PKEY_sign() - correct? If so should I do checking that I only pass digests to this function? Thanks Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Leon Brits Sent: 15 March 2013 09:18 AM To: openssl-dev@openssl.org Subject: RE: RSA sign and verify It now works, thanks for your guidance! Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 15 March 2013 12:42 AM To: openssl-dev@openssl.org Subject: Re: RSA sign and verify On Thu, Mar 14, 2013, Leon Brits wrote: Just a view more questions: In my existing code, I used the EVP_SignInit/Update/Final calls. I did not set the padding so the default (RSASSA_PKCS1.5) was always used. So now, to set the padding, I've added the code as mentioned after the EVP_SignInit() and before the first EVP_SignUpdate(). This all worked, until I've commented out the EVP_PKEY_CTX_set_rsa_padding() call from the verification function (as a test). This should cause the default padding to be used and should fail to verify signatures with the PSS padding scheme (right?). Well is succeeds. 1. Comments? 2. Can I mix the EVP_SignInit/Update/Final() and EVP_DigestSignInit/Update/Final() calls? Info: I've noticed that one should not free the key context (EVP_PKEY_CTX) returned from EVP_DigestSignInit() since it is deleted in the digest context (EVP_MD_CTX). This sould be noted somewhere. No you can't mix the two. You should use EVP_Digest* throughout. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
PKCS#7 packaging
Hi List,
With the list help I've recently implemented a sign and verify functions using
EVP_DigestSign{Init/Update/Final}.
This gives back a variable length signature based on the selected digest. My
client however now _also_ requires the option to package the signature in
PKCS#7 for transmission with the original message/data.
Q: Which set of API calls (PKCS7 or CMS) will help me to simply package my
existing signature with the Public certificate (as far as I know this is
basically the important information in a detached PKCS7 package) to get a valid
PKCS#7 package?
Since only the signature need to be package (no data enveloping) I think simple
PKCS7 should be sufficient - correct?
Thanks for your time
Regards,
Leon Brits
RE: EVP and Elliptic curve
The patch works. I am using the openssl-fips-2.0.2 sources. Here is a Kolbitz-409 curve private key: -BEGIN PRIVATE KEY- MIIBiwIBADCB2QYHKoZIzj0CATCBzQIBATAdBgcqhkjOPQECMBICAgGZBgkqhkjO PQECAwICAVcwBgQBAAQBAQRpBABg8F9lj0nBrTqxiQ9xhCEO/QmH4wfITCesz7j5 9nzCxGAYnrWqqmLuIi6xs1VAz+kCN0YB42kFC3xOQqy6Hay/BCmcNGB4L5GOpCfm MlFl6eoQ49pfbELpxVIVqpyielhj7EjY4ChrAjN/ /l+DstTqIEAOxFV9XtPj58pbS1yDuOAeX88CAQQEgakwgaYCAQEEM11q kNyuCz8isUZ7C5zOWVrFAGNjErW9RKH3vluP5lP5YyP2Y+n7PRP/6xh1bn+/0zKv O6FsA2oABAEK21oLBen5xoJDZBZJtaSAyMBrLpBihUS3OHprmX9voA2bR8UUHjeZ 3B8KZNEjHHUrTqYBWgYRuoZta9TEINsEOaG7lt4We5/iRQcpuq8vXr8qOMssuWYa VYvegaty02SSXB2m1wM/ -END PRIVATE KEY- Thanks again Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Matt Caswell Sent: 22 March 2013 01:06 AM To: openssl-dev@openssl.org Subject: Re: EVP and Elliptic curve Hi Leon On 21 March 2013 17:27, Matt Caswell fr...@baggins.org wrote: On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote: Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. I have successfully managed to reproduce your problem. This is a BUG! Looks to me like binary curves are broken in FIPS mode - anything which attempts to encode a private key will fail, I think (and potentianly numerous other functions). I have attached a patch for openssl-1.0.1e. Please can you confirm that this resolves your problem? cd openssl-1.0.1e patch -p1 /path/to/patch I have submitted this to RT for one of the devs to pick up and commit (hopefully!) :-) Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: EVP and Elliptic curve
Matt, You are correct, using the standard installed libraries for Ubuntu 12.10 (OpenSSL 1.0.1 14 Mar 2012), my test app successfully creates EC keys and successfully sign and verify some data for all types of curves of all sizes. The private key however seems to be bigger (more chars in PEM format)? Here is the one created from the sect233r1 curve: -BEGIN PRIVATE KEY- MIIBOQIBADCBywYHKoZIzj0CATCBvwIBATAdBgcqhkjOPQECMBICAgDpBgkqhkjO PQECAwICAUowOQQBAQQdZmR+3mwzLH+MCSO7WCE7Mzsg6c5Cgf4RX32PkK0DFQB0 1Z/wf2tBPQ6hSzRLIKLbBJtQwwQ9BAD6yd/LrIMTuyE58bt1X+9lvDkfizb4+Otz cf1ViwEAagikGQM1BnjlhSi+v4oL7/hnp8o2cW9+AfgQUgIeAQAA E+l05y+KaSIDHSYDz+DXAgECBGYwZAIBAQQdkgFHGcub3q4KILP17VudtpDC 4KS7qMLPA/XpkHKhQAM+AAQAVdHQVSgvfEKnoAzxQu3++YjR60UjmimJUTzTB9QB zwNjc/gjDH6ex4ehhC9BsJ4L6nhphsegp57bIDM= -END PRIVATE KEY- NEW: I changed my compile to again use my FIPS compiled OpenSSL libraries and I got some new errors from the Binary and Kolbitz curves. Prime curves are still working just fine. First off the private key created with the sect233r1 curve are: -BEGIN PRIVATE KEY- MHYCAQAwCQYHKoZIzj0CAQRmMGQCAQEEHVnVyx1BHVTaKFSi758nc0v1SnWNQ1aR BYRjL4ZboUADPgAEAVZmnrloR8NnuKI7pzD8n8UYXHannulPUv2JVqeiAXI1bnBR K10brlEGKzKztusdvxC6UVz1Ew9eVvcL -END PRIVATE KEY- It does contain less information - I am not an expert but this seems wrong? Next, after creating these PEM formatted private and public keys I test them doing a sign and verify operation. I do this in a loop which excercises all the supported digests, but they all fail before the function get to do the actual sign/verify. The initial attempt to sign gives the following error when I try to read the PEM formatted private key using PEM_read_bio_PrivateKey(): (error:0B07707D:x509 certificate routines:X509_PUBKEY_get:public key decode error) The loop then tries to verify the generated signature, which will fail since no signature was created, but again the code does not reach the verify function. I get the following error when I try to read the PEM formatted public key using PEM_read_bio_PUBKEY(): (error:100BF078:elliptic curve routines:i2d_ECPKParameters:group2pkparameters failure) The loop tries the next digest, which again reads the _same_ PEM formatted private key as using PEM_read_bio_PrivateKey() and I get a different error: (error:100C1042:elliptic curve routines:EC_GROUP_get_pentanomial_basis:called a function you should not call) For the verify I also get a different error when parsing the public key with PEM_read_bio_PUBKEY(): (error:100D5010:elliptic curve routines:ECKEY_PRIV_DECODE:EC lib) The loop continues with the next digest, which again fails to read the same PEM formatted private key as using PEM_read_bio_PrivateKey(): (error:100D7010:elliptic curve routines:ECKEY_PUB_DECODE:EC lib) The last errors repeat for all the following attempt to parse the PEM formatted private and public keys in the digest loop. So, to conclude: It seems that this is a FIPS related problem. The keys simply seems incorrect and will therefore cause all the errors I now see. But, I do not get why a will get different errors when reading the exact same PEM formatted key. Or, why it all works for NIST prime curves? Any comment or help is appreciated Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Matt Caswell Sent: 20 March 2013 11:11 PM To: openssl-dev@openssl.org Subject: Re: EVP and Elliptic curve On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote: Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. Regards, Leon Brits Well, I am unable to reproduce your problem, my code works fine under vanilla OpenSSL 1.0.1e. I don't have a fips build environment so it could be a fips issue. Are you able to test your code under normal non-fips openssl and see if you still get the same problem? Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: EVP and Elliptic curve
Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. Regards, Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Matt Caswell Sent: 19 March 2013 11:48 PM To: openssl-dev@openssl.org Subject: Re: EVP and Elliptic curve On 19 March 2013 10:22, Leon Brits le...@parsec.co.za wrote: I've created keys for NIST Prime curves (224-571bit), Binary and Kolbits curves (233-571 bit). I then convert the keys to PEM using the same method which I used successfully for RSA and DSA which only calls PEM_write_bio_PrivateKey() and PEM_write_bio_PUBKEY(). The type is never specified in my functions. What is interesting now is that if I test the EC PEM files, using the openssl command line tool, all the keys generated for the NIST Prime curves is successfully parsed while the others fails with the following error: I have just tested this with no problems using NID_sect233k1. What version of openssl are you using? Please see attached PEM file. Are you able to read that with openssl ec? Please send me a sample PEM that you are having difficulty with and I will see if I can read it. Matt ec-b233.pem Description: ec-b233.pem ec-k233.pem Description: ec-k233.pem ec-p224.pem Description: ec-p224.pem
RE: EVP and Elliptic curve
Hi Matt, Can you send me an offending PEM file? I've replied with this information attached to your second message They are different formats. If it has BEGIN PRIVATE KEY it is in PKCS 8 format. See: https://www.openssl.org/docs/apps/pkcs8.html If it says BEGIN EC PRIVATE KEY then its as per RFC 5915 My requirement is too support PKCS8 for private keys, so I will do so for elliptic curve key pairs as well. The sec ones are named the same as per this document: http://www.secg.org/collateral/sec2_final.pdf The k indicates its a Kolbitz curve, whilst an r indicates that the parameters have been generated verifiably at random. The number is just to distinguish different curves with the similar characteristics e.g. sect193r1 and sect193r2. X9_62 refers to the ANSI standard X9.62 Thanks for that explanation - so, just to understand the history, why is there no secp256_r1 as well as the ANSI standard curve. In other words, why does the ANSI curve replace it instead of being an additional curve? Again my gratitude to the you and the list Leon Brits __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: EVP and Elliptic curve
List, I've continued so long to use the NIST prime curves to implement sign/verify using EVP. I am basically using the same code as for RSA and DSA. This mechanism is so transparent (nice!) that I just want to verify that it is using ECDSA at the backend? Do you have any reference to this fact, which I can add to my code for when the client audits the code? Regards, Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Leon Brits Sent: 20 March 2013 09:27 AM To: openssl-dev@openssl.org Subject: RE: EVP and Elliptic curve Hi Matt, Can you send me an offending PEM file? I've replied with this information attached to your second message They are different formats. If it has BEGIN PRIVATE KEY it is in PKCS 8 format. See: https://www.openssl.org/docs/apps/pkcs8.html If it says BEGIN EC PRIVATE KEY then its as per RFC 5915 My requirement is too support PKCS8 for private keys, so I will do so for elliptic curve key pairs as well. The sec ones are named the same as per this document: http://www.secg.org/collateral/sec2_final.pdf The k indicates its a Kolbitz curve, whilst an r indicates that the parameters have been generated verifiably at random. The number is just to distinguish different curves with the similar characteristics e.g. sect193r1 and sect193r2. X9_62 refers to the ANSI standard X9.62 Thanks for that explanation - so, just to understand the history, why is there no secp256_r1 as well as the ANSI standard curve. In other words, why does the ANSI curve replace it instead of being an additional curve? Again my gratitude to the you and the list Leon Brits __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: EVP and Elliptic curve
Matt / List,
Thanks for the example. It sure helped a lot. But I am still stuck at the EC
key generation.
I've created keys for NIST Prime curves (224-571bit), Binary and Kolbits curves
(233-571 bit). I then convert the keys to PEM using the same method which I
used successfully for RSA and DSA which only calls PEM_write_bio_PrivateKey()
and PEM_write_bio_PUBKEY(). The type is never specified in my functions. What
is interesting now is that if I test the EC PEM files, using the openssl
command line tool, all the keys generated for the NIST Prime curves is
successfully parsed while the others fails with the following error:
$openssl ec -in ec-b233.pem -text -noout
read EC key
unable to load Key
139742524995232:error:100DC08E:elliptic curve routines:ECKEY_TYPE2PARAM:decode
error:ec_ameth.c:178:
139742524995232:error:100D5010:elliptic curve routines:ECKEY_PRIV_DECODE:EC
lib:ec_ameth.c:305:
139742524995232:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private
key decode error:evp_pkey.c:95:
139742524995232:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1
lib:pem_pkey.c:132:
I've noticed that writing the PEM files using the above mentioned mechanism
does not add the letters EC to the PEM header and footer of the private key
(e.g. -BEGIN EC PRIVATE KEY-- misses the EC). The spec seems to say
it must have these two characters. If I add the EC manually, I get the
following parsing error:
$ openssl ec -in ec-b233.pem -text -noout
read EC key
unable to load Key
140357067445920:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
tag:tasn_dec.c:1319:
140357067445920:error:0D06C03A:asn1 encoding
routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:831:
140357067445920:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:tasn_dec.c:751:Field=privateKey, Type=EC_PRIVATEKEY
140357067445920:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC
lib:ec_asn1.c:1130:
140357067445920:error:100DE08E:elliptic curve
routines:OLD_EC_PRIV_DECODE:decode error:ec_ameth.c:565:
140357067445920:error:100DC08E:elliptic curve routines:ECKEY_TYPE2PARAM:decode
error:ec_ameth.c:178:
140357067445920:error:100D5010:elliptic curve routines:ECKEY_PRIV_DECODE:EC
lib:ec_ameth.c:305:
140357067445920:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private
key decode error:evp_pkey.c:95:
140357067445920:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1
lib:pem_pkey.c:132:
Any suggestions on why my binary curve keys are not validated?
Also can someone shed some light on the naming of the curves: Take for example
NID_secp224r1. From the bits I can see that it is a NIST prime curve which is
also indicated by the 'p' (right?), which then makes me wonder why all the
binary curves has a 't' (e.g. NID_sect233r1). Next, to distinguish between the
NIST binary curves and the Kolbitz curves the only indication is that the
Kolbitz curve names ends with a 'k1' - is this correct? And if so what is the
'r' for then in the NIST prime and NIST binary numbers? And finally, why is
there not a NID_sect256r1, but rather a NID_X9_62_prime256v1?
Thanks again for a great mailing list
Leon Brits
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Matt Caswell
Sent: 15 March 2013 02:05 AM
To: openssl-dev@openssl.org
Subject: Re: EVP and Elliptic curve
On Thu, Mar 14, 2013, Leon Brits wrote:
Hi List,
I just want to verify: Elliptic curve functions are not encapsulated by the
EVP functions - correct? If so, what is the
EVP_PKEY_CTX_set_ec_paramgen_curve_nid function then used for? If NOT so,
then please help with an example since I could only find the normal
EC_{KEY,GROUP}* type of example code?
I am required to perform ECDSA and was hoping I could use EVP which is now
working for DSA and RSA (sans the padding problem).
As Steve has said, yes you can use ECDSA using EVP. The
EVP_PKEY_CTX_set_ec_paramgen_curve_nid is used during parameter generation.
Here is some sample code that uses it. Once you have an EVP_PKEY set up with a
type of EVP_PKEY_EC, then the code to do signatures should be pretty much
identical for DSA and ECDSA. This code generates a new key but you can equally
set it directly using EVP_PKEY_set1_EC_KEY. See the man page for further
details:
http://www.openssl.org/docs/crypto/EVP_PKEY_set1_RSA.html
EVP_PKEY *generate_key(int type)
{
EVP_PKEY_CTX *pctx = NULL, *kctx = NULL;
EVP_PKEY *params = NULL, *key = NULL;
/* Check whether we need to generate parameters first */
if(type == EVP_PKEY_EC || type == EVP_PKEY_DSA || type == EVP_PKEY_DH)
{
/* Create the context for generating the parameters */
if(!(pctx = EVP_PKEY_CTX_new_id(type, NULL))) goto err;
if(!EVP_PKEY_paramgen_init(pctx)) goto err;
/* Set the paramgen parameters according to the type */
switch(type)
{
case EVP_PKEY_EC
RE: RSA sign and verify
It now works, thanks for your guidance! Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 15 March 2013 12:42 AM To: openssl-dev@openssl.org Subject: Re: RSA sign and verify On Thu, Mar 14, 2013, Leon Brits wrote: Just a view more questions: In my existing code, I used the EVP_SignInit/Update/Final calls. I did not set the padding so the default (RSASSA_PKCS1.5) was always used. So now, to set the padding, I've added the code as mentioned after the EVP_SignInit() and before the first EVP_SignUpdate(). This all worked, until I've commented out the EVP_PKEY_CTX_set_rsa_padding() call from the verification function (as a test). This should cause the default padding to be used and should fail to verify signatures with the PSS padding scheme (right?). Well is succeeds. 1. Comments? 2. Can I mix the EVP_SignInit/Update/Final() and EVP_DigestSignInit/Update/Final() calls? Info: I've noticed that one should not free the key context (EVP_PKEY_CTX) returned from EVP_DigestSignInit() since it is deleted in the digest context (EVP_MD_CTX). This sould be noted somewhere. No you can't mix the two. You should use EVP_Digest* throughout. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: RSA sign and verify
Just a view more questions: In my existing code, I used the EVP_SignInit/Update/Final calls. I did not set the padding so the default (RSASSA_PKCS1.5) was always used. So now, to set the padding, I've added the code as mentioned after the EVP_SignInit() and before the first EVP_SignUpdate(). This all worked, until I've commented out the EVP_PKEY_CTX_set_rsa_padding() call from the verification function (as a test). This should cause the default padding to be used and should fail to verify signatures with the PSS padding scheme (right?). Well is succeeds. 1. Comments? 2. Can I mix the EVP_SignInit/Update/Final() and EVP_DigestSignInit/Update/Final() calls? Info: I've noticed that one should not free the key context (EVP_PKEY_CTX) returned from EVP_DigestSignInit() since it is deleted in the digest context (EVP_MD_CTX). This sould be noted somewhere. Leon Brits Senior Design Engineer Parsec -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 12 March 2013 03:58 PM To: openssl-dev@openssl.org Subject: Re: RSA sign and verify On Tue, Mar 12, 2013, Leon Brits wrote: I am implementing a sign and verify function for RSA and DSA (for now just RSA) using the EVP methods. In the manual it says this is the preferred method. It all _works_ fine, but I have a requirement to support different padding schemes: RSASSA-PKCS1.5 and RSASSA-PSS. I've searched for how to change the padding scheme when I sign, but could not find how to do it the EVP way. You need OpenSSL 1.0.0 or later and the EVP_Digest*() API. You need to retrieve the EVP_PKEY_CTX uses and then set appropriate parameters using the EVP_PKEY_ctrl function. There are various macros defined to change the padding mode and parameters. So typically you'd call EVP_DigestSignInit(), get the associated context then call EVP_PKEY_CTX_set_rsa_padding() and optionally some other PSS parameters. See manual pages for more info. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
EVP and Elliptic curve
Hi List,
I just want to verify: Elliptic curve functions are not encapsulated by the EVP
functions - correct?
If so, what is the EVP_PKEY_CTX_set_ec_paramgen_curve_nid function then used
for?
If NOT so, then please help with an example since I could only find the normal
EC_{KEY,GROUP}* type of example code?
I am required to perform ECDSA and was hoping I could use EVP which is now
working for DSA and RSA (sans the padding problem).
Regards
Leon Brits
RE: FIPS mode
Hi Tom,
Thanks for your reply. I did read the user guide and do understand that I
cannot use the library directly. This is shown in my explanation where I try to
change the compiler to use the script.
Thanks for all the other suggestions - I will definitively order the CD.
After I read your email, I again read the user guide and could not find fault
in my method. So the only thing left to do is search for an error with SCons.
Eventually I found the correct way to change the compiler settings and now the
application is able to change between FIPS and non-FIPS mode. For anybody else
interested in the solution, here it is (working with most of what I explained
in original message):
:
cc = env['CC']
env.Replace(CC = FIPSLD_CC= + cc + /usr/local/ssl/fips-2.0/bin/fipsld)
:
Thanks again for all the help and emails
Leon Brits
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Tom Francis
Sent: 08 March 2013 04:01 PM
To: openssl-dev@openssl.org
Subject: Re: FIPS mode
I strongly recommend reading the user guide, as it'll help a lot. You need to
do more than simply link your application with libcrypto and libssl. There's a
sample shell script, fipsld, that's also provided in the distribution that
shows the necessary actions (and can even be called in place of ld on most UNIX
and UNIX-like systems). Additionally, if you truly needs FIPS 140 mode, you
don't want to simply download openssl-fips-2.0.2, as the new requirements from
the CMVP indicate that you need a trusted path for obtaining the source code,
and that you need to verify your source package with a FIPS 140 approved
algorithm (again, it's explained in the user's guide). The best way to do get
what you need is to request a CD-ROM with the right stuff (again, see the User
Guide).
http://www.openssl.org/docs/fips/UserGuide-2.0.pdf
On Mar 8, 2013, at 2:27 AM, Leon Brits wrote:
Hi list,
I am not able to enable FIPS mode. FIPS_mode_set(1) fails.
Our build system uses SCons so I hope somebody can help me...
First: I downloaded openssl-fips-2.0.2 and openssl-1.0.1e and extracted them.
Next: In the openssl-fips-2.0.2 directory I typed:
./config
make
sudo make install
This created the directory /usr/local/ssl/fips-2.0 and some other such
as the /usr/local/ssl/include directory
Next: in the openssl-.1.0.1 directory I typed:
./config fips
make
sudo make install
which added some more files and directories to the /usr/local/ssl directory
such as bin and lib. I made a symbolic link to /usr/bin/openssl from
/usr/local/ssl/bin/openssl and openssl version reports OpenSSL 1.0.1e-fips
All seem fine.
Next: I want to use the static libraries with my app so I added the following
code to SConstruct which compiles my app:
libssl = File('/usr/local/ssl/lib/libssl.a')
libcrypto = File('/usr/local/ssl/lib/libcrypto.a')
env.Append(LIBS = [libssl, libcrypto, ])
as well as prepending the path to the new includes so that it will be used
instead of default installed includes:
env.Prepend(CPPPATH =
['/usr/local/ssl/include','/usr/include','/usr/local/include'])
I also changed my environment compiler variable from cc=gcc to cc=fipsld.
The compilation completes successfully, but when I execute the application
simply refuses to enter FIPS mode.
Any suggestions? (please)
Thanks
Leon Brits
Leon Brits
Senior Design Engineer
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: AES modes in FIPS and non-FIPS modes
Thanks for clarifying that for my. Using the example code at http://www.fredriks.se/?p=23, I've duplicated everything of the GCM mode for the CCM mode with the addition of setting the tag length in the beginning of the encryption function. The encryption succeed BUT the decryption fails. Again, just like with GCM, I did not set the IV length or the AAD, so ... 1. Should I set them for CCM to work? 2. What should the tag length be? Regards Leon Brits __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: AES modes in FIPS and non-FIPS modes
Just want to add that I do set the data sizes before EncryptUpdate and DecryptUpdate and mentioned in the CCM section of the OpenSSL support page. This page does answer both my questions (appologies), but I still fail to decrypt. Regards, Leon Brits Senior Design Engineer Parsec Work +27 12 678 9740 Cell +27 (84) 250 2855 Email le...@parsec.co.za www.parsec.co.za/disclaimer -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Leon Brits Sent: 05 March 2013 11:40 AM To: openssl-dev@openssl.org Subject: RE: AES modes in FIPS and non-FIPS modes Thanks for clarifying that for my. Using the example code at http://www.fredriks.se/?p=23, I've duplicated everything of the GCM mode for the CCM mode with the addition of setting the tag length in the beginning of the encryption function. The encryption succeed BUT the decryption fails. Again, just like with GCM, I did not set the IV length or the AAD, so ... 1. Should I set them for CCM to work? 2. What should the tag length be? Regards Leon Brits __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: AES modes in FIPS and non-FIPS modes
Dr. Henson and Matt, Thanks a lot for all the help - my code is also now working. I simply had to not do the DecryptFinal(). The fact that one can call the xxxUpdate() only once is a problem for using our engine. For now a size limit will have to be a limitation on this AES mode. Regards, Leon Brits Senior Design Engineer Parsec Work +27 12 678 9740 Cell +27 (84) 250 2855 Email le...@parsec.co.za www.parsec.co.za/disclaimer -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: 05 March 2013 08:37 PM To: openssl-dev@openssl.org Subject: Re: AES modes in FIPS and non-FIPS modes On Tue, Mar 05, 2013, Matt Caswell wrote: On 5 March 2013 14:13, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Mar 05, 2013, Leon Brits wrote: Just want to add that I do set the data sizes before EncryptUpdate and DecryptUpdate and mentioned in the CCM section of the OpenSSL support page. This page does answer both my questions (appologies), but I still fail to decrypt. I'll add an example for CCM mode in the demos section shortly. CCM mode is a bit picky about setting all the parameters correctly in the correct order. That would be good!! I am working on some test code myself but cannot get it to work. See source code below. This is adapted from some code I have for GCM that works fine. With CCM though encryption (apparently) works fine, but when I get to decryption I get a 0 response from the final EVP_DecryptUpdate call - no error message on the OpenSSL error stack :-( I'd just committed it, it's very similar to the GCM code but with some additional restrictions. The main one is that you can only call EVP_*Update once for AAD and/or the ciphertext/plaintext: this is mainly influenced by the requirement that you cannot reveal any plaintext if the tag verify fails. As a result the tag verify is performed when you call EVP_DecryptUpdate and is reflected by the return value: there is no call to EVP_DecryptFinal. See demos/evp/aesccm.c in the master branch. I'll update the manual page too. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
AES modes in FIPS and non-FIPS modes
Hi List, In the FIPS security policy it states that OpenSSL supports the following modes for AES: 128/ 192/256 ECB, CBC, OFB, CFB 1, CFB 8, CFB 128, CTR, XTS; CCM; GCM; CMAC generate and verify (page 12). My library is required to support of these modes in FIPS and non-FIPS mode. Most of them are now working in non-FIPS-mode except for CCM and CMAC. EVP_get_cipherbynid() complains that it cannot find NID_aes_128_ccm and the compiler complains that it cannot find the NID defines for the CMAC mode. Are these modes available in non-FIPS mode using OpenSSL 1.0.1? Thanks Leon
Error implementing AES-GCM using EVP from OpenSSL
I am trying to add AES-GCM mode to my code which has been working for most other modes for quite a while now. The mode is given as a parameter and I use it for GCM mode to switch and do special stuff such as to set the AAD and get/set the tag for AES-GCM mode. In the encipherment function I store the tag at the end of the ciphertext and return a larger data size. In the decipherment function I automatically reduce the size by 16 and use the last 16 bytes as the tag to compare. This will be so documented for this mode in the library header. I've followed the advise of these two posting: http://stackoverflow.com/questions/12153009/openssl-c-example-of-aes-gcm-using-evp-interfaces and http://incog-izick.blogspot.in/2011/08/using-openssl-aes-gcm.html My problem is that the call to get the tag fails (EVP_CIPHER_CTX_ctrl() returns 1) in the encipherment function. Can anybody shine some light on what my problem may be? (I can post code if you want, but the referenced links contain good code already) I am working on Ubuntu 12.10 which has the following OpenSSL installed: $ openssl version -a OpenSSL 1.0.1 14 Mar 2012 built on: Tue Aug 21 05:18:48 UTC 2012 platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: /usr/lib/ssl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
SSL protocol server certificate stage
Hi all, My question is basically, how many CA certificates is allowed to be send during the server certificate stage of the SSL protocol negotiations and do I control it (if at all)? My clients (a mono application), is able to connect to my SSL server if I only have 6 CA certificates in the CA directory configured in the SSL_CTX. Adding another two causes the clients to fail due to an SSL certificate error. Watching the protocol with Wireshark it stops at the Server certificate stage of the negotiations. My theory is that the clients are limited and does not like so many (8) CA certs being send and/or can not parse them all to validate it's own certificate. Is this possible and what is the limit if any? All of the certificates is signed by a root CA so the depth level is 2. Thanks LJB -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SSL protocol server certificate stage
Sorry my mistake - the CA certificates was manually added to the context instead of just pointing to the directory where the CAs are. The order in which the CA certificates was added was wrong and hence the problem. Changing the code to just search in the directory causes only one cert to be send to the client and the connection succeeds everytime - nice. Thanks for all your help Leon -- Leon Brits ljbr...@fastmail.fm On Friday, September 30, 2011 10:26 AM, Leon Brits ljbr...@fastmail.fm wrote: Hi all, My question is basically, how many CA certificates is allowed to be send during the server certificate stage of the SSL protocol negotiations and do I control it (if at all)? My clients (a mono application), is able to connect to my SSL server if I only have 6 CA certificates in the CA directory configured in the SSL_CTX. Adding another two causes the clients to fail due to an SSL certificate error. Watching the protocol with Wireshark it stops at the Server certificate stage of the negotiations. My theory is that the clients are limited and does not like so many (8) CA certs being send and/or can not parse them all to validate it's own certificate. Is this possible and what is the limit if any? All of the certificates is signed by a root CA so the depth level is 2. Thanks LJB -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- http://www.fastmail.fm - Email service worth paying for. Try it for free __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
