HowTo: Engine-specific TLS master secret generation?
Hello, Now OpenSSL generates master secret and read/write keys inside the library, left only premaster secret decryption to the engine. In case of hardware-based TLS engine it could be not an option, as there may be no possibility to set read/write keys from outside (or it may be restricted according to some rules of such hardware usage). If someone would needed to implement such device support in OpenSSL: 1. How would you estimate required effort? 2. What is the best base OpenSSL version to start with? 3. What is necessary to take into account, but may be not visible from the beginning? Would be really appreciated for any answer. Andrey.
[openssl.org #2438] [PATCH] ecrypto/ecdsa: fix a zero change in the test suite
[openssl-...@ml.breakpoint.cc - Sun Jan 23 20:16:44 2011]: At the end of the testsuite in test_builtin() happens the following: - a previously created signature gets modified at a random spot - this signaure is compared against the data which was used to create the signature. Now, in theory this should always fail in reality is passed sometimes. The modifcation algorith did the following: | offset = sig[10] % 66; | dirt = sig[11]; | dirt = dirt ? dirt : 1; | sig[offset] ^= dirt; If sig[10] is 0xa7 and sig[11] is 0x9e the last line envolves to: | sig[35] ^= 0x9e; The signature consists of to BIGNUMs encoded as ASN1 string. sig[34] and sig[35] is the begin of the second and last number. sig[35] contains the length of this number and its content is 0x1e. Now, 0x9e ^ 0x1e = 0x80 and this is a special value. It means that the length of the value is infinite i.e. everything until the end of the stream. So the ASN1 parser considers the remaining data as the last element. Since there is nothing after it, it succeeds. This random modification was a zero change. There are several bugs here. The ASN1 parser should reject indefinite length primitive encodings as that is illegal. The original modification routine for ECDSA signatures has another possible flaw: if the ASN1 is modified so it is no longer valid you could get an ASN1 parser error. That arguably isn't a good thing if you want to check signature verification failure. I think the simplest solution is to so the do_sign and do_verify functions instead which avoid the ASN1 parser totally and then you can modify a BIGNUM. 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
Re: Extracting cert from pfx file
Hi All, I'm resending the mail with more details with sample pfx file key and cert extracted using PKCS12_parse() fn is as follows. Plz note the localKeyID field in cert and key. ** MAC verified OK Bag Attributes localKeyID: 01 00 00 00 friendlyName: mysrt localKeyID: E3 E8 08 75 10 C2 89 A6 8A 5C 81 B5 4B 0C 43 49 10 FC 00 BD subject=/C=IN/ST=Karnataka/L=bangalore/O=mycompany/OU=mybu/CN= 10.10.1.68/emailAddress=shaf...@gmail.com issuer=/DC=com/DC=autocert/CN=rootca -BEGIN CERTIFICATE- MIIGDjCCBPagAwIBAgIKQAum1gAAQDANBgkqhkiG9w0BAQUFADBAMRMwEQYK wEEyMlzv32iuW2QTeQ8980fk -END CERTIFICATE- Bag Attributes friendlyName: mysrt localKeyID: E3 E8 08 75 10 C2 89 A6 8A 5C 81 B5 4B 0C 43 49 10 FC 00 BD Key Attributes: No Attributes -BEGIN RSA PRIVATE KEY- MIIEpAIBAAKCAQEAtsU6UvSXKcbCqLJFapFNNSPBiu1pYtsxqm/tPMJW5caqaGtD uJuUCTtysSTd0XMs20Xkk857mCR6mMct5fFo6sd1HY57kFtzNX7cIA== Key and cert extracted from the same pfx file using openssl command line utility has only one localKeyID in key and cert each with value 01 00 00 00 (openssl pkcs12 -in input.pfx -clcerts -nokeys -out outcert.pem) (openssl pkcs12 -in input.pfx -nocerts -out outkey.pem) Please let me know whether PKCS12_parse function has any such know issues. -Shafeek On Sun, Jan 23, 2011 at 10:26 PM, Muhammed Shafeek shafee...@gmail.comwrote: Hi All, The following code is to extract cert from a pfx file. p12Cert = d2i_PKCS12_fp(fp, NULL); //fp points to a .pfx file. PKCS12_parse(p12Cert, pass, NULL, oCert, NULL); Here the resultant oCert has multiple localKeyID as shown below. MAC verified OK Bag Attributes localKeyID: 01 00 00 00 localKeyID: E3 E8 08 75 10 C2 89 A6 8A 5C 81 B5 4B 0C 43 49 10 FC 00 BD The second localKeyID seen in the Bag attributes is actually the thumbprint. But extracting cert from the same pfx file using openssl command line utility (openssl pkcs12 -in input.pfx -clcerts -nokeys -out outcert.pem) results in single localKeyID attribute. Bag Attributes localKeyID: 01 00 00 00 Can anyone please tell me why there is an additional localKeyID with the first method? Thanks in Advance Shafeek
