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
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
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
