Re: Error 20 at 0 depth lookup:unable to get local issuer certificate
The -untrusted argument to verify command takes a single file containing multiple certificates concatenated together. Try adding cert1.pem and cert2.pem into a single file and check again. Thanks, Sandeep On Tue, Dec 14, 2010 at 12:00 PM, Vinay Kumar L vinaykuma...@globaledgesoft.com wrote: Hi all, I have generated certificate chain using Openssl(OpenSSL 0.9.8e). The certificate hierarchy is as follows: ca.pem cert1.pemcert2.pem-last.pem Openssl doesn't give any error when verifying these certificate chain(Certificate chain verification is successful) during TLS connection establishment(Connection establishment is successful) but when verified using Openssl command *openssl verify *gives following error: *# openssl verify -CAfile ca.pem -untrusted cert1.pem cert2.pem last.pem* cert2.pem: OK last.pem: /C=IN/O=Xyz/OU=CableLabs Key Distribution Center/CN=kdc.xyz.com error 20 at 0 depth lookup:unable to get local issuer certificate The Subject and Issuer names in certificates are correct. Please let me know the cause of error and changes required in the certificate hierarchy. Regards, Vinay
Re: How to disable compression?
On Tue, Dec 14, 2010 at 06:20:54PM +1100, Corin Lawson wrote: Hi All, Is it possible to establish an SSL connection with no compression? How? OpenSSL 1.0.0 provides a new option that can be set via SSL_CTX_set_options() or SSL_set_options(). SSL_OP_NO_COMPRESSION While I'm at it, is it possible to use no encryption? See ciphers(1). The eNULL ciphers offer no encryption, while the aNULL ciphers offer no authentication. Usually you want both, you are unlikely to want neither. Thus if you want eNULL, make sure to exclude aNULL. For encryption with no authentication: aNULL:!EXP:!LOW:!eNULL:@STRENGTH For authentication with no encryption: eNULL:!EXP:!LOW:!aNULL:@STRENGTH -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problems building FIPS Openssl under Server 2008 R2
On Mon, Dec 13, 2010, Christopher A Hotchkiss wrote: Just a quick note. There was a bug in the 1.2 module which meant Win64 ASM builds didn't function properly. A change letter has addressed this and the newly uploaded 1.2.2 module should now work fine with Win64 ASM. Steve. Does the updated 1.2.2 module need to be revalidated before we can use it? The updated version has been approved via something called a change letter to the 1.2.2 version is validated. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Using DH parameters from OpenSSL
Good afternoon, I'm trying to understand the data format that OpenSSL writes out its DH parameters in. I am aware that the actual data is encoded using ASN.1 DER and have a way to parse the container. My question really amounts to byte ordering when DH parameters are generated like this: openssl dhparam -outform DER -5 -out parameters.dh 4096 Take, for example, the safe prime 'p' in parameters.dh. Are its bytes stored in MSB...LSB form, such that the number is interpreted similarly to a human reading base 10 numbers on paper? That is to say, left to right 1 byte at a time? Thanks for any clarification, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Using DH parameters from OpenSSL
DER encoding of numeric data should always be network byte order MSB...LSB. Note that if the high order bit is set then an additional 0 byte is prepended. Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Mike Mohr Sent: Tuesday, December 14, 2010 3:42 PM To: openssl-users@openssl.org Subject: Using DH parameters from OpenSSL Good afternoon, I'm trying to understand the data format that OpenSSL writes out its DH parameters in. I am aware that the actual data is encoded using ASN.1 DER and have a way to parse the container. My question really amounts to byte ordering when DH parameters are generated like this: openssl dhparam -outform DER -5 -out parameters.dh 4096 Take, for example, the safe prime 'p' in parameters.dh. Are its bytes stored in MSB...LSB form, such that the number is interpreted similarly to a human reading base 10 numbers on paper? That is to say, left to right 1 byte at a time? Thanks for any clarification, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Using DH parameters from OpenSSL
How do you mean, an additional 0 byte is prepended? I generated several DH parameters and exported them to C code ( -C ), some of which has the MSB set. It looks like BN_bin2bn is used directly on the raw bytes of the prime without any padding. Mike On Tue, Dec 14, 2010 at 12:54 PM, Erik Tkal et...@juniper.net wrote: DER encoding of numeric data should always be network byte order MSB...LSB. Note that if the high order bit is set then an additional 0 byte is prepended. Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Mike Mohr Sent: Tuesday, December 14, 2010 3:42 PM To: openssl-users@openssl.org Subject: Using DH parameters from OpenSSL Good afternoon, I'm trying to understand the data format that OpenSSL writes out its DH parameters in. I am aware that the actual data is encoded using ASN.1 DER and have a way to parse the container. My question really amounts to byte ordering when DH parameters are generated like this: openssl dhparam -outform DER -5 -out parameters.dh 4096 Take, for example, the safe prime 'p' in parameters.dh. Are its bytes stored in MSB...LSB form, such that the number is interpreted similarly to a human reading base 10 numbers on paper? That is to say, left to right 1 byte at a time? Thanks for any clarification, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl and legacy openbsd crypto project
this story is going around the net like hotcakes. http://marc.info/?l=openbsd-techm=129236621626462w=2 http://marc.info/?l=openbsd-techm=129236621626462w=2 i have no idea how much 'truth' is in there... but didn't openssl get its start with that same openbsd crypto code? is any of this potentially suspect code still in place? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Using DH parameters from OpenSSL
From: owner-openssl-us...@openssl.org On Behalf Of Mike Mohr Sent: Tuesday, 14 December, 2010 19:14 How do you mean, an additional 0 byte is prepended? I generated several DH parameters and exported them to C code ( -C ), some of which has the MSB set. It looks like BN_bin2bn is used directly on the raw bytes of the prime without any padding. Mike On Tue, Dec 14, 2010 at 12:54 PM, Erik Tkal et...@juniper.net wrote: DER encoding of numeric data should always be network byte order MSB...LSB. Note that if the high order bit is set then an additional 0 byte is prepended. In DER encoding of INTEGER is bigendian signed (twos-complement) so +127 is (02 02) 7F, +128 is (02 02) 00 80, -128 is (02 01) 80, +258 is (02 02) 01 02, -258 is (02 02) FF FE, etc. In C code using openssl, the bignums we care about (DH/DSS groups, RSA moduli, etc.) are always positive and bin2bn is unsigned. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How to compute crt coefficient (PQ) value of a private key?
I have a private key that I need to load onto the smart card. The prime P value used being 00CC11DBABBC3648BF4C3800DD73C769580D60B8F45BA41210674FCFB6EDE6C604FD20FBD0EC3125BB9A116238CE4900A0308155971AB606CFB9945551B519ED6F And the prime Q value being 00DF613AEA2FF8438C58766639DCED24D9BCBAF75926734EAD56ECFF03E7801DF812604926EF03A1A88F38B5B03A8E7A6361258C7A4B84FDA3D2286A50608DC291 The PIV User Guide says PQ = P-1 mod Q For (P-1) mod Q I arrive at the value 00CC11DBABBC3648BF4C3800DD73C769580D60B8F45BA41210674FCFB6EDE6C604FD20FBD0EC3125BB9A116238CE4900A0308155971AB606CFB9945551B519ED6E which fails to load into the card. The PQ value for the same private key used by the PIV demo tool is C3E06EAC8B7A4A0BB3EF2B0241FCAF74814580579F56EBB36E4035CDEDBDF3252DAE4BFBD83545F91BC3E2C2ED1BE6F2DB01F92B2DC64B96FE74ADAE61FD28EF I don't know how this value is arrived at. I also tried P - (1 mod Q) and simply P*Q but these values don't match with the expected value either. I'm attaching the private key file and the openssl dump for your reference. I have interchanged the P and Q because according to the card specs, P should be the smaller prime. Please advice. thanks Kannan -BEGIN RSA PRIVATE KEY- MIICXQIBAAKBgQCyERAVj1p8CGytZXPZqKTlUXT4j4xySOBUL/Mw+ofoAhUAgzOe PtXrSzeN4pfnEJUFlkuUBRvVflQE+IAB0UNb+BxL5ocJUtfStj7IzjxARiucU82X OwA4XhZRCRCvgdIbT2be6e1wdC6op5v6QZrlBPOuZF6rDQCjWN+Gn8CZ3wIDAQAB AoGBAJ7Bs7NlMekvoaUetKE0SH/jlgQeB7vE2ax1a78ZPp5NbOgeEaFeqF61mvw3 L/Nkx1hJ3WxE+cHodYRRAd+c8Q3LF3lfOhEfv88yUs39+0N8BEoqe4FdV0x+w+/3 S8e8YDu8NmHIsD6a+A6M05+FXJMmtyvcNX+9P/3yxkR+EyRBAkEA32E66i/4Q4xY dmY53O0k2by691kmc06tVuz/A+eAHfgSYEkm7wOhqI84tbA6jnpjYSWMekuE/aPS KGpQYI3CkQJBAMwR26u8Nki/TDgA3XPHaVgNYLj0W6QSEGdPz7bt5sYE/SD70Owx JbuaEWI4zkkAoDCBVZcatgbPuZRVUbUZ7W8CQGiIqrZfHnIV4mv96MQfYehXLrOD z7+UKQANxkVAd68OoSLX+NVPQL6Nz38O6kg0s/8JQFUWtDSyDi4FmnmkvVECQQCI XCZ9Sva7BZjYkztm8gjiXY4UCLRznd54KkyR38Yk65B5ScsBCJY+FWUoTO0KuvBP eRzIK4EWbBeFlr1SVlDhAkAI9+Tlp0pjOUPtF9biXf3tdGR+r8lBgguMtyMRbFgt bfFnfGyPxx55JAGtZx8RJ5ImarJ8EHbvAPJvZl5iC00P -END RSA PRIVATE KEY-Private-Key: (1024 bit) modulus: 00:b2:11:10:15:8f:5a:7c:08:6c:ad:65:73:d9:a8: a4:e5:51:74:f8:8f:8c:72:48:e0:54:2f:f3:30:fa: 87:e8:02:15:00:83:33:9e:3e:d5:eb:4b:37:8d:e2: 97:e7:10:95:05:96:4b:94:05:1b:d5:7e:54:04:f8: 80:01:d1:43:5b:f8:1c:4b:e6:87:09:52:d7:d2:b6: 3e:c8:ce:3c:40:46:2b:9c:53:cd:97:3b:00:38:5e: 16:51:09:10:af:81:d2:1b:4f:66:de:e9:ed:70:74: 2e:a8:a7:9b:fa:41:9a:e5:04:f3:ae:64:5e:ab:0d: 00:a3:58:df:86:9f:c0:99:df publicExponent: 65537 (0x10001) privateExponent: 00:9e:c1:b3:b3:65:31:e9:2f:a1:a5:1e:b4:a1:34: 48:7f:e3:96:04:1e:07:bb:c4:d9:ac:75:6b:bf:19: 3e:9e:4d:6c:e8:1e:11:a1:5e:a8:5e:b5:9a:fc:37: 2f:f3:64:c7:58:49:dd:6c:44:f9:c1:e8:75:84:51: 01:df:9c:f1:0d:cb:17:79:5f:3a:11:1f:bf:cf:32: 52:cd:fd:fb:43:7c:04:4a:2a:7b:81:5d:57:4c:7e: c3:ef:f7:4b:c7:bc:60:3b:bc:36:61:c8:b0:3e:9a: f8:0e:8c:d3:9f:85:5c:93:26:b7:2b:dc:35:7f:bd: 3f:fd:f2:c6:44:7e:13:24:41 prime1: 00:df:61:3a:ea:2f:f8:43:8c:58:76:66:39:dc:ed: 24:d9:bc:ba:f7:59:26:73:4e:ad:56:ec:ff:03:e7: 80:1d:f8:12:60:49:26:ef:03:a1:a8:8f:38:b5:b0: 3a:8e:7a:63:61:25:8c:7a:4b:84:fd:a3:d2:28:6a: 50:60:8d:c2:91 prime2: 00:cc:11:db:ab:bc:36:48:bf:4c:38:00:dd:73:c7: 69:58:0d:60:b8:f4:5b:a4:12:10:67:4f:cf:b6:ed: e6:c6:04:fd:20:fb:d0:ec:31:25:bb:9a:11:62:38: ce:49:00:a0:30:81:55:97:1a:b6:06:cf:b9:94:55: 51:b5:19:ed:6f exponent1: 68:88:aa:b6:5f:1e:72:15:e2:6b:fd:e8:c4:1f:61: e8:57:2e:b3:83:cf:bf:94:29:00:0d:c6:45:40:77: af:0e:a1:22:d7:f8:d5:4f:40:be:8d:cf:7f:0e:ea: 48:34:b3:ff:09:40:55:16:b4:34:b2:0e:2e:05:9a: 79:a4:bd:51 exponent2: 00:88:5c:26:7d:4a:f6:bb:05:98:d8:93:3b:66:f2: 08:e2:5d:8e:14:08:b4:73:9d:de:78:2a:4c:91:df: c6:24:eb:90:79:49:cb:01:08:96:3e:15:65:28:4c: ed:0a:ba:f0:4f:79:1c:c8:2b:81:16:6c:17:85:96: bd:52:56:50:e1 coefficient: 08:f7:e4:e5:a7:4a:63:39:43:ed:17:d6:e2:5d:fd: ed:74:64:7e:af:c9:41:82:0b:8c:b7:23:11:6c:58: 2d:6d:f1:67:7c:6c:8f:c7:1e:79:24:01:ad:67:1f: 11:27:92:26:6a:b2:7c:10:76:ef:00:f2:6f:66:5e: 62:0b:4d:0f -BEGIN RSA PRIVATE KEY- MIICXQIBAAKBgQCyERAVj1p8CGytZXPZqKTlUXT4j4xySOBUL/Mw+ofoAhUAgzOe PtXrSzeN4pfnEJUFlkuUBRvVflQE+IAB0UNb+BxL5ocJUtfStj7IzjxARiucU82X OwA4XhZRCRCvgdIbT2be6e1wdC6op5v6QZrlBPOuZF6rDQCjWN+Gn8CZ3wIDAQAB AoGBAJ7Bs7NlMekvoaUetKE0SH/jlgQeB7vE2ax1a78ZPp5NbOgeEaFeqF61mvw3 L/Nkx1hJ3WxE+cHodYRRAd+c8Q3LF3lfOhEfv88yUs39+0N8BEoqe4FdV0x+w+/3 S8e8YDu8NmHIsD6a+A6M05+FXJMmtyvcNX+9P/3yxkR+EyRBAkEA32E66i/4Q4xY dmY53O0k2by691kmc06tVuz/A+eAHfgSYEkm7wOhqI84tbA6jnpjYSWMekuE/aPS KGpQYI3CkQJBAMwR26u8Nki/TDgA3XPHaVgNYLj0W6QSEGdPz7bt5sYE/SD70Owx JbuaEWI4zkkAoDCBVZcatgbPuZRVUbUZ7W8CQGiIqrZfHnIV4mv96MQfYehXLrOD z7+UKQANxkVAd68OoSLX+NVPQL6Nz38O6kg0s/8JQFUWtDSyDi4FmnmkvVECQQCI XCZ9Sva7BZjYkztm8gjiXY4UCLRznd54KkyR38Yk65B5ScsBCJY+FWUoTO0KuvBP eRzIK4EWbBeFlr1SVlDhAkAI9+Tlp0pjOUPtF9biXf3tdGR+r8lBgguMtyMRbFgt
Re: Using DH parameters from OpenSSL
On Tue, Dec 14, 2010 at 04:14:01PM -0800, Mike Mohr wrote:
How do you mean, an additional 0 byte is prepended? I generated
several DH parameters and exported them to C code ( -C ), some of
which has the MSB set. It looks like BN_bin2bn is used directly on
the raw bytes of the prime without any padding.
The BN_bin2bn constructor always geneates positive numbers, for signed
numbers, you need to use BN_mpi2bn. Thus, for example, Postfix (in
src/tls/tls_dh.c) has:
/*
* Generated via openssl dhparam -2 -noout -C 1024 2/dev/null TODO:
* generate at compile-time.
*/
static unsigned char dh1024_p[] = {
0xB0, 0xFE, 0xB4, 0xCF, 0xD4, 0x55, 0x07, 0xE7, 0xCC, 0x88, 0x59, 0x0D,
0x17, 0x26, 0xC5, 0x0C, 0xA5, 0x4A, 0x92, 0x23, 0x81, 0x78, 0xDA, 0x88,
0xAA, 0x4C, 0x13, 0x06, 0xBF, 0x5D, 0x2F, 0x9E, 0xBC, 0x96, 0xB8, 0x51,
0x00, 0x9D, 0x0C, 0x0D, 0x75, 0xAD, 0xFD, 0x3B, 0xB1, 0x7E, 0x71, 0x4F,
0x3F, 0x91, 0x54, 0x14, 0x44, 0xB8, 0x30, 0x25, 0x1C, 0xEB, 0xDF, 0x72,
0x9C, 0x4C, 0xF1, 0x89, 0x0D, 0x68, 0x3F, 0x94, 0x8E, 0xA4, 0xFB, 0x76,
0x89, 0x18, 0xB2, 0x91, 0x16, 0x90, 0x01, 0x99, 0x66, 0x8C, 0x53, 0x81,
0x4E, 0x27, 0x3D, 0x99, 0xE7, 0x5A, 0x7A, 0xAF, 0xD5, 0xEC, 0xE2, 0x7E,
0xFA, 0xED, 0x01, 0x18, 0xC2, 0x78, 0x25, 0x59, 0x06, 0x5C, 0x39, 0xF6,
0xCD, 0x49, 0x54, 0xAF, 0xC1, 0xB1, 0xEA, 0x4A, 0xF9, 0x53, 0xD0, 0xDF,
0x6D, 0xAF, 0xD4, 0x93, 0xE7, 0xBA, 0xAE, 0x9B,
};
and then calls tls_get_dh(dh1024_p, (int) sizeof(dh1024_p)):
static DH *tls_get_dh(const unsigned char *p, int plen)
{
DH *dh;
static unsigned char g[] = {0x02,};
/* Use the compiled-in parameters. */
if ((dh = DH_new()) == 0) {
msg_warn(cannot create DH parameter set: %m); /* 200411 */
return (0);
}
dh-p = BN_bin2bn(p, plen, (BIGNUM *) 0);
dh-g = BN_bin2bn(g, 1, (BIGNUM *) 0);
if ((dh-p == 0) || (dh-g == 0)) {
msg_warn(cannot load compiled-in DH parameters);
DH_free(dh);
return (0);
}
return (dh);
}
So indeed, no leading 0 is required.
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: openssl and legacy openbsd crypto project
On Tue, Dec 14, 2010 at 05:05:06PM -0800, John R Pierce wrote: but didn't openssl get its start with that same openbsd crypto code? No. From the information-free OpenBSD mailing list message: It is alleged that some ex-developers (and the company they worked for) accepted US government money to put backdoors into our network stack, in particular the IPSEC stack. Around 2000-2001. http://www.mail-archive.com/openssl-users@openssl.org/msg00873.html In 1995, Eric Young and Tim Hudson posted version 1 of SSLeay to the Internet. SSLeay (eay for Eric A. Young) is a free cryptographic library in which Young managed to single-handedly implement the full suite of cryptosystems used in SSL: the RSA-based security protocol that provides confidentiality, integrity, and digital signature authentication functions for secure connections, transactions, and file transfers over the World Wide Web (WWW) recently invented by European programmers. See also http://en.wikipedia.org/wiki/Timeline_of_OpenBSD So OpenSSL predates and is completely independent of same code. No developed of OpenSSL was done in the US, in part to avoid crypto export issues. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to compute crt coefficient (PQ) value of a private key?
On Tue, Dec 14, 2010 at 07:30:33PM -0800, Kannan J wrote: I have a private key that I need to load onto the smart card. The PIV User Guide says PQ = P-1 mod Q Instead of re-interpreting it is best to provide a direct reference, or at least an unedited quote of the specificied requirements with enough context so the specs make sense... Clearly PQ is always zero mod Q, so you seem to want P = 1 mod Q, which is only possible if P is the larger of the two primes. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to compute crt coefficient (PQ) value of a private key?
I'm copying and pasting the text from the smart card guide. It is too big to attach. The following convention applies for the P, Q, DP1, DQ1, and PQ parameters: · P is the smallest RSA prime · Q is the other RSA prime · DP1 = D mod (P – 1), where D is the secret RSA exponent · DQ1 = D mod (Q – 1) · PQ = P-1 mod Q NOTE: For the key being loaded, Size of (P) must be equal to Size of (Q) and this value must be half the size of modulus. For example: For RSA 2048-bit key, modulus size is 256, and size (P) , Size (Q) are half the modulus size, (I.e.) 128 bytes thanks Kannan --- On Wed, 15/12/10, Victor Duchovni victor.ducho...@morganstanley.com wrote: From: Victor Duchovni victor.ducho...@morganstanley.com Subject: Re: How to compute crt coefficient (PQ) value of a private key? To: openssl-users@openssl.org Date: Wednesday, 15 December, 2010, 10:08 AM On Tue, Dec 14, 2010 at 07:30:33PM -0800, Kannan J wrote: I have a private key that I need to load onto the smart card. The PIV User Guide says PQ = P-1 mod Q Instead of re-interpreting it is best to provide a direct reference, or at least an unedited quote of the specificied requirements with enough context so the specs make sense... Clearly PQ is always zero mod Q, so you seem to want P = 1 mod Q, which is only possible if P is the larger of the two primes. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to compute crt coefficient (PQ) value of a private key?
From my relentless search on the internet I hit upon this webpage http://www.mobilefish.com/services/rsa_key_generation/rsa_key_generation.php which accepts prime values and generates the rest of the exponents and coefficients. It mentions Enter CRT coefficient (qInv)*: qInv = q-1 mod p I wonder if the smart card user guide might have printed P-1 instead of P-1. Even so I don't know how such a small real number obtained after taking the inverse can be a big integer. In fact Java BigInteger doesn't allow raising to a negative exponent value. --- On Wed, 15/12/10, Kannan J kannan_jayapraka...@yahoo.co.in wrote: From: Kannan J kannan_jayapraka...@yahoo.co.in Subject: Re: How to compute crt coefficient (PQ) value of a private key? To: openssl-users@openssl.org Date: Wednesday, 15 December, 2010, 11:16 AM I'm copying and pasting the text from the smart card guide. It is too big to attach. The following convention applies for the P, Q, DP1, DQ1, and PQ parameters: · P is the smallest RSA prime · Q is the other RSA prime · DP1 = D mod (P – 1), where D is the secret RSA exponent · DQ1 = D mod (Q – 1) · PQ = P-1 mod Q NOTE: For the key being loaded, Size of (P) must be equal to Size of (Q) and this value must be half the size of modulus. For example: For RSA 2048-bit key, modulus size is 256, and size (P) , Size (Q) are half the modulus size, (I.e.) 128 bytes thanks Kannan --- On Wed, 15/12/10, Victor Duchovni victor.ducho...@morganstanley.com wrote: From: Victor Duchovni victor.ducho...@morganstanley.com Subject: Re: How to compute crt coefficient (PQ) value of a private key? To: openssl-users@openssl.org Date: Wednesday, 15 December, 2010, 10:08 AM On Tue, Dec 14, 2010 at 07:30:33PM -0800, Kannan J wrote: I have a private key that I need to load onto the smart card. The PIV User Guide says PQ = P-1 mod Q Instead of re-interpreting it is best to provide a direct reference, or at least an unedited quote of the specificied requirements with enough context so the specs make sense... Clearly PQ is always zero mod Q, so you seem to want P = 1 mod Q, which is only possible if P is the larger of the two primes. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to compute crt coefficient (PQ) value of a private key?
On Tue, Dec 14, 2010 at 09:46:11PM -0800, Kannan J wrote: I'm copying and pasting the text from the smart card guide. It is too big to attach. Please use plain-text (non-HTML) email when sending mail to lists. The following convention applies for the P, Q, DP1, DQ1, and PQ parameters: P is the smallest RSA prime Q is the other RSA prime ... PQ = P-1 mod Q Then PQ is not a product, rather the value P-1 mod Q. So what's the issue? NOTE: For the key being loaded, Size of (P) must be equal to Size of (Q) and this value must be half the size of modulus. For example: For RSA 2048-bit key, modulus size is 256, and size (P) , Size (Q) are half the modulus size, (I.e.) 128 bytes Perhaps your primes are not exactly 128-bytes long? They may need to be padded with leading zeros. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Error 20 at 0 depth lookup:unable to get local issuer certificate
Thank you. It worked fine after concatenating cert1.pem and cert2.pem into single file. Regards, Vinay sandeep kiran p wrote: The -untrusted argument to verify command takes a single file containing multiple certificates concatenated together. Try adding cert1.pem and cert2.pem into a single file and check again. Thanks, Sandeep On Tue, Dec 14, 2010 at 12:00 PM, Vinay Kumar L vinaykuma...@globaledgesoft.com mailto:vinaykuma...@globaledgesoft.com wrote: Hi all, I have generated certificate chain using Openssl(OpenSSL 0.9.8e). The certificate hierarchy is as follows: ca.pem cert1.pemcert2.pem-last.pem Openssl doesn't give any error when verifying these certificate chain(Certificate chain verification is successful) during TLS connection establishment(Connection establishment is successful) but when verified using Openssl command /openssl verify /gives following error: *# openssl verify -CAfile ca.pem -untrusted cert1.pem cert2.pem last.pem* cert2.pem: OK last.pem: /C=IN/O=Xyz/OU=CableLabs Key Distribution Center/CN=kdc.xyz.com http://kdc.xyz.com error 20 at 0 depth lookup:unable to get local issuer certificate The Subject and Issuer names in certificates are correct. Please let me know the cause of error and changes required in the certificate hierarchy. Regards, Vinay
Re: How to compute crt coefficient (PQ) value of a private key?
On Wed, Dec 15, 2010 at 12:55 AM, Kannan J kannan_jayapraka...@yahoo.co.inwrote: From my relentless search on the internet I hit upon this webpage http://www.mobilefish.com/services/rsa_key_generation/rsa_key_generation.php http://groups.google.com/group/sci.crypt/browse_frm/thread/d228e099f78164e3 which accepts prime values and generates the rest of the exponents and coefficients. It mentions Enter CRT coefficient (qInv)*: qInv = q-1 mod p I wonder if the smart card user guide might have printed P-1 instead of P-1. Even so I don't know how such a small real number obtained after taking the inverse can be a big integer. In fact Java BigInteger doesn't allow raising to a negative exponent value. -1 simply means the inverse. [SNIP HTML]
Re: How to compute crt coefficient (PQ) value of a private key?
On Tue, Dec 14, 2010 at 09:55:26PM -0800, Kannan J wrote: From my relentless search on the internet I hit upon this webpage http://www.mobilefish.com/services/rsa_key_generation/rsa_key_generation.php which accepts prime values and generates the rest of the exponents and coefficients. It mentions Enter CRT coefficient (qInv)*: qInv = q-1 mod p I wonder if the smart card user guide might have printed P-1 instead of P-1. Even so I don't know how such a small real number obtained after taking the inverse can be a big integer. In fact Java BigInteger doesn't allow raising to a negative exponent value. You need to brush-up on prime-field modular arithmetic. :-) Large integers don't have ordinary (integer) reciprocals, but they do have reciprocals modulo any number to which they are co-prime. The reciprocal is found using Euclid's algorithm. You are looking at all the wrong things. What's the real problem? What tool or API is used to load the key into the card? What key format does it expect. Are your primes exactly 128-bytes long for a 2048-bit modulus? Is the modulus exactly 256-bytes long? This is perhaps just a simple padding issue, or your key format is not what the card expects? Either way, all the number theory is likely a red-herring. Don't waste your time trying to debug the number theory, this is almost certainly an interface mismatch. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to compute crt coefficient (PQ) value of a private key?
On Wed, Dec 15, 2010 at 12:58 AM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Tue, Dec 14, 2010 at 09:46:11PM -0800, Kannan J wrote: I'm copying and pasting the text from the smart card guide. It is too big to attach. Please use plain-text (non-HTML) email when sending mail to lists. Agreed. The following convention applies for the P, Q, DP1, DQ1, and PQ parameters: P is the smallest RSA prime Q is the other RSA prime ... PQ = P-1 mod Q Then PQ is not a product, rather the value P-1 mod Q. So what's the issue? NOTE: For the key being loaded, Size of (P) must be equal to Size of (Q) and this value must be half the size of modulus. For example: For RSA 2048-bit key, modulus size is 256, and size (P) , Size (Q) are half the modulus size, (I.e.) 128 bytes Perhaps your primes are not exactly 128-bytes long? They may need to be padded with leading zeros. Microsoft .Net goes the other way in the case of DSA: if there is a leading 00 octect (from an ASN1 encoding) *and* the bigint is 129 bytes (due to the leading 00), .Net will throw an exception. The 0x00 has to be stripped. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to compute crt coefficient (PQ) value of a private key?
Yes, that was the case. It was power -1 instead of subtract. Java BigInteger has a function modInverse that does the required work for me. Now got it loaded onto the smart card. --- On Wed, 15/12/10, Kannan J kannan_jayapraka...@yahoo.co.in wrote: From: Kannan J kannan_jayapraka...@yahoo.co.in Subject: Re: How to compute crt coefficient (PQ) value of a private key? To: openssl-users@openssl.org Date: Wednesday, 15 December, 2010, 11:25 AM From my relentless search on the internet I hit upon this webpage http://www.mobilefish.com/services/rsa_key_generation/rsa_key_generation.php which accepts prime values and generates the rest of the exponents and coefficients. It mentions Enter CRT coefficient (qInv)*: qInv = q-1 mod p I wonder if the smart card user guide might have printed P-1 instead of P-1. Even so I don't know how such a small real number obtained after taking the inverse can be a big integer. In fact Java BigInteger doesn't allow raising to a negative exponent value. --- On Wed, 15/12/10, Kannan J kannan_jayapraka...@yahoo.co.in wrote: From: Kannan J kannan_jayapraka...@yahoo.co.in Subject: Re: How to compute crt coefficient (PQ) value of a private key? To: openssl-users@openssl.org Date: Wednesday, 15 December, 2010, 11:16 AM I'm copying and pasting the text from the smart card guide. It is too big to attach. The following convention applies for the P, Q, DP1, DQ1, and PQ parameters: · P is the smallest RSA prime · Q is the other RSA prime · DP1 = D mod (P – 1), where D is the secret RSA exponent · DQ1 = D mod (Q – 1) · PQ = P-1 mod Q NOTE: For the key being loaded, Size of (P) must be equal to Size of (Q) and this value must be half the size of modulus. For example: For RSA 2048-bit key, modulus size is 256, and size (P) , Size (Q) are half the modulus size, (I.e.) 128 bytes thanks Kannan --- On Wed, 15/12/10, Victor Duchovni victor.ducho...@morganstanley.com wrote: From: Victor Duchovni victor.ducho...@morganstanley.com Subject: Re: How to compute crt coefficient (PQ) value of a private key? To: openssl-users@openssl.org Date: Wednesday, 15 December, 2010, 10:08 AM On Tue, Dec 14, 2010 at 07:30:33PM -0800, Kannan J wrote: I have a private key that I need to load onto the smart card. The PIV User Guide says PQ = P-1 mod Q Instead of re-interpreting it is best to provide a direct reference, or at least an unedited quote of the specificied requirements with enough context so the specs make sense... Clearly PQ is always zero mod Q, so you seem to want P = 1 mod Q, which is only possible if P is the larger of the two primes. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
