Re: openssl RSA public key does not match key read from C code
There is currently a parsing bug when converting from PEM to DER. I encountered this as well, but with DSA keys. I suppose the same bug occurs with RSA keys. In DSA the G component gets copied to the pub component when converting from PEM to DER. From DER to PEM works fine. Regards, Dereck On Sun, Jan 5, 2014 at 8:49 PM, Alan D. Cabrera l...@toolazydogs.comwrote: I've created a public key file using the following commands: openssl genrsa -out mykey.pem 2046 openssl rsa -in mykey.pem -pubout mykey.pub I then read it from some C code: public_key = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL); and then obtain the DER form of this public key: int len = i2d_RSAPublicKey (public_key, NULL); buf = (unsigned char *) malloc (len); i2d_RSAPublicKey (public_key, buf); here len == 269 but the command line openssl tells me: openssl rsa -outform der -pubin -inform pem -in mykey.pub | wc writing RSA key 1 10 293 When I print out the DER forms from openssl and my C code they, obviously, don't match and, oddly, the DER encoding that my C code obtains has a lot of zeros. What could I be doing wrong? Regards, Alan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
how to get a maximum digest length of a specific algorithm by nid
Hello, Is there an easy way in OpenSSL to call some function which returns the length of the digest/hash it returns? Like SHA256 would return 32 (maximum digest length of 32 bytes). Dereck
What does RSA_public_encrypt use for hash and mgf
Can someone tell me what hash algorithm the RSA_public_encrypt function uses? Is this SHA1 only for both? Dereck
Re: What does RSA_public_encrypt use for hash and mgf
I read that. Still doesn't give me a clue if the hash and the mgf both use sha1 On Thu, Dec 12, 2013 at 3:21 PM, Kenneth Goldman kgold...@us.ibm.comwrote: The documentation says: *RSA_PKCS1_OAEP_PADDING* EME-OAEP as defined in PKCS #1 v2.0 with SHA-1, MGF1 and an empty encoding parameter. This mode is recommended for all new applications. -- Ken Goldman kgold...@us.ibm.com 914-945-2415 (862-2415) From:Dereck Hurtubise djhurtub...@gmail.com To:openssl-users@openssl.org Date:12/12/2013 07:55 AM Subject:What does RSA_public_encrypt use for hash and mgf Sent by:owner-openssl-us...@openssl.org -- Can someone tell me what hash algorithm the RSA_public_encrypt function uses? Is this SHA1 only for both? Dereck
Re: how to get a maximum digest length of a specific algorithm by nid
How do you use EVP_MD_size() if the only thing you have is the NID of the algorithm? On Thu, Dec 12, 2013 at 5:59 PM, Michel msa...@paybox.com wrote: Did you see EVP_MD_size() at http://www.openssl.org/docs/crypto/EVP_DigestInit.html Le 12/12/2013 09:29, Dereck Hurtubise a écrit : Hello, Is there an easy way in OpenSSL to call some function which returns the length of the digest/hash it returns? Like SHA256 would return 32 (maximum digest length of 32 bytes). Dereck
Re: Verification of a x509 certificate signature
It is NTP indicating that this certificate is held by a supposed trusted root (authority). This is NTP's way of figuring out if the certificate of the subject/issuer should be trusted or not. So they misuse X509 extensions for their own purposes. This alone is not enough. So they also implement a challenge/response scheme that they do after the certificates are verified. Read RFC 5906 (autokey) on the CERT message/exchange for more information and why they do this. The Trust Root is used in the identity exchange scheme after the CERT exchange. Also in the RFC. On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.infowrote: Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verification of a x509 certificate signature
I want to thank everyone who replied for the help. I figured out what went wrong. Two things. The RSA public key wasn't loaded with the correct values. Thank you for giving a hint about that. The second thing was the data to verify somehow included the OID of the signature. So the second time the OID is in the file. This should've been omitted from the data, but somehow didn't Thank you all for the help. On Thu, Nov 28, 2013 at 2:26 PM, Dereck Hurtubise djhurtub...@gmail.comwrote: It is NTP indicating that this certificate is held by a supposed trusted root (authority). This is NTP's way of figuring out if the certificate of the subject/issuer should be trusted or not. So they misuse X509 extensions for their own purposes. This alone is not enough. So they also implement a challenge/response scheme that they do after the certificates are verified. Read RFC 5906 (autokey) on the CERT message/exchange for more information and why they do this. The Trust Root is used in the identity exchange scheme after the CERT exchange. Also in the RFC. On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.infowrote: Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Bad OIDs (was: Re: Verification of a x509 certificate signature)
Welcome to the wonderful world of NTP Autokey. Where they misuse X509v3 extensions for their own purposes. Nothing I can do about it. It's in the specification of that RFC (5906) On Thu, Nov 28, 2013 at 4:14 PM, Erwann Abalea erwann.aba...@keynectis.comwrote: How nice, they're asking for a self-signed certificate to include a specific EKU to indicate it's a Trust Anchor, and the OID used for this has never been allocated. Crazy. I just looked at OpenSSL's objects.txt database, and found some OIDs that need some change: id-pkix-OCSP 8: extendedStatus: Extended OCSP Status should be id-pkix-ocsp-pref-sig-algs (RFC6960). id-pkix-OCSP 9: valid should be id-pkix-ocsp-extended-revoke (RFC6960). id-pkix-OCSP 10 : path id-pkix-OCSP 11 : trustRoot : Trust Root have never been defined by PKIX. RFC5906 uses a trustRoot EKU, without any OID being proposed or referenced. Your certificate includes the later one in the EKU extension. -- Erwann ABALEA Le 28/11/2013 14:26, Dereck Hurtubise a écrit : It is NTP indicating that this certificate is held by a supposed trusted root (authority). This is NTP's way of figuring out if the certificate of the subject/issuer should be trusted or not. So they misuse X509 extensions for their own purposes. This alone is not enough. So they also implement a challenge/response scheme that they do after the certificates are verified. Read RFC 5906 (autokey) on the CERT message/exchange for more information and why they do this. The Trust Root is used in the identity exchange scheme after the CERT exchange. Also in the RFC. On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.infowrote: Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verification of a x509 certificate signature
Hello, I'm trying to verify an x509 certificate with a custom library (other than openssl) The reason I'm writing to this mailing list is that I can't figure out what is going wrong. The library is checked and nothing is wrong so I must be missing something. The program I'm writing has to be compatible with NTP, which uses openssl to create its certificates and uses NIDs for algorithm identification. The certificate is created on a server by openssl with RSA/SHA1, or some other algorithm. The modulus is 1024 bit and the e-bits are 3. The algorithm used to create the signature, is that RSA/SHA1 with PKCS1 v1.5? The OID I'm getting is: 1.2.840.113549.1.1.5 The NID given, according to NTP, is 65. The functions called to create this certificate, used by ntp-keygen, are these: - Create RSA key-pair - RSA_generate_key(1024, 3, cb, RSA); - So the modulus is 1024 bits, the exponent is 3, cb is some callback function, and RSA is what? - RSA_check_key(rsa) - This checks the rsa key generated for validity, right? - Create certificate - The certificate is filled with all the necessary info - The public key is set: X509_set_pubkey(cert, pkey) - cert is the internal openssl certificate format. - pkey is the key pair in the openssl internal format. - The CA is set to TRUE, along with some other extensions for key constraints etc. - The certificate is signed: X509_sign(cert, pkey, md) - md is the message digest algorithm to use, which is the NID of RSA/SHA1 (65 correct?) - The certificate is verified using: X509_verify(cert, pkey) Then the certificate is transmitted from this server in DER format (converted from the internal openssl format to DER with the i2d routine in openssl) This DER format is what I'm getting. The certificate is read correctly. The only thing I can't figure out is how this certificate's signature should be verified. The certificate being verified is self-signed and created in the above manner. So the issuer and subject are the same and the extension CA is TRUE. Also, there is an extension called trustRoot. So the main questions are these: - How should the RSA key format be interpreted? - The modulus is easy - Is the exponent transmitted the e-bits portion of the RSA format? - If so, how does this translate to the exponent portion? If the e-bits are 3, does this mean the exponent is (2^(e-bits -1)) + 1? So, in the example: 2^2 + 1 = 5? - If not, then what? - How do I verify the signature? - Is the algorithm to verify with RSA/SHA1 with PKCS1 v1.5? - Is the signature wrapped in any way and with which scheme if so? - Do I use the DER data up to and excluding the signature portion? - If any data of the DER format needs to be excluded from the hash, which data? Any help would be great and much appreciated. Thanks, Dereck
Re: Verification of a x509 certificate signature
The certificate is received in ASN.1 DER format. Not PEM. The only thing I want to do is verify the signature of the certificate, and thus verify the signature itself. It is self-signed so the public key in the certificate should be used to verify the signature, but it isn't working. Certificate: Data: Version: 3 (0x2) Serial Number: 3593335860 (0xd62df434) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=NL1SPF002 Validity Not Before: Nov 13 12:51:00 2013 GMT Not After : Nov 13 12:51:00 2014 GMT Subject: CN=NL1SPF002 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c7:42:a0:7f:ff:a8:1f:65:a0:39:dc:63:d9:8b: 09:7c:f2:d3:59:6d:84:a6:4b:1f:05:de:30:1b:6b: fa:42:b0:86:8c:88:75:9f:a9:57:5b:b2:6e:e6:60: 79:d7:12:1e:22:1b:91:18:d5:93:41:80:28:2c:4d: f7:d5:46:a6:3e:9d:55:e1:a2:89:86:ed:dc:88:9d: 1b:de:b8:f2:03:5a:56:5b:0e:cb:97:3d:b1:32:74: 6a:a8:3b:24:6c:45:e7:1a:69:eb:2c:ef:d7:fd:c1: 4c:60:2a:6d:ba:4b:a3:34:3c:d6:56:4a:3e:ca:32: cd:6c:5c:47:a1:05:e6:e7:8d Exponent: 3 (0x3) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: Digital Signature, Certificate Sign X509v3 Extended Key Usage: Trust Root Signature Algorithm: sha1WithRSAEncryption c2:3a:8d:8e:2c:a2:b5:46:7f:cf:05:e2:01:38:c7:df:6f:6e: 5f:4e:e1:94:42:65:5a:67:bb:21:48:fe:e1:fc:eb:ab:be:b2: 34:65:ac:99:2e:2f:53:20:87:ec:a5:0a:14:5d:3a:08:dc:2b: f2:1c:9e:46:f0:b3:e9:f9:26:fc:6e:12:bd:bf:95:4f:e7:bc: 11:ce:7c:22:05:b3:c7:28:e8:e9:67:a5:05:1b:a0:47:c0:e1: dc:b2:d1:96:9d:46:90:97:66:c0:26:0f:88:90:a2:d1:6f:88: bb:cb:fe:f4:bb:a1:90:99:ab:82:a4:87:27:95:80:27:a4:59: 69:87 DER format: 30 82 01 d6 30 82 01 3f a0 03 02 01 02 02 05 00 d6 2d f4 34 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 14 31 12 30 10 06 03 55 04 03 13 09 4e 4c 31 53 50 46 30 30 32 30 1e 17 0d 31 33 31 31 31 33 31 32 35 31 30 30 5a 17 0d 31 34 31 31 31 33 31 32 35 31 30 30 5a 30 14 31 12 30 10 06 03 55 04 03 13 09 4e 4c 31 53 50 46 30 30 32 30 81 9d 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 81 8b 00 30 81 87 02 81 81 00 c7 42 a0 7f ff a8 1f 65 a0 39 dc 63 d9 8b 09 7c f2 d3 59 6d 84 a6 4b 1f 05 de 30 1b 6b fa 42 b0 86 8c 88 75 9f a9 57 5b b2 6e e6 60 79 d7 12 1e 22 1b 91 18 d5 93 41 80 28 2c 4d f7 d5 46 a6 3e 9d 55 e1 a2 89 86 ed dc 88 9d 1b de b8 f2 03 5a 56 5b 0e cb 97 3d b1 32 74 6a a8 3b 24 6c 45 e7 1a 69 eb 2c ef d7 fd c1 4c 60 2a 6d ba 4b a3 34 3c d6 56 4a 3e ca 32 cd 6c 5c 47 a1 05 e6 e7 8d 02 01 03 a3 36 30 34 30 0f 06 03 55 1d 13 01 01 ff 04 05 30 03 01 01 ff 30 0b 06 03 55 1d 0f 04 04 03 02 02 84 30 14 06 03 55 1d 25 04 0d 30 0b 06 09 2b 06 01 05 05 07 30 01 0b 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 03 81 81 00 c2 3a 8d 8e 2c a2 b5 46 7f cf 05 e2 01 38 c7 df 6f 6e 5f 4e e1 94 42 65 5a 67 bb 21 48 fe e1 fc eb ab be b2 34 65 ac 99 2e 2f 53 20 87 ec a5 0a 14 5d 3a 08 dc 2b f2 1c 9e 46 f0 b3 e9 f9 26 fc 6e 12 bd bf 95 4f e7 bc 11 ce 7c 22 05 b3 c7 28 e8 e9 67 a5 05 1b a0 47 c0 e1 dc b2 d1 96 9d 46 90 97 66 c0 26 0f 88 90 a2 d1 6f 88 bb cb fe f4 bb a1 90 99 ab 82 a4 87 27 95 80 27 a4 59 69 87 On Wed, Nov 27, 2013 at 3:45 PM, Salz, Rich rs...@akamai.com wrote: NID is an internal openssl implementation detail; X509 data structures have OID’s. Post the PEM of the cert. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA
