> From: owner-openssl-us...@openssl.org On Behalf Of Ram Prasad Reddy
> Sent: Wednesday, 04 April, 2012 09:08
> We are using OpenSSL DH for key establishment in our product.
> Recently we increased the size of P parameter to 2048 bits from
> 640 bits (we use g parameter of value 5), which is in accordance
> with the latest NIST standard document. Using the established
> shared secret, we are deriving 4 sub keys of size 128, 192 and 256
> for symmetric key encryption using AES.
> NIST Special Publication 800-131a: <snip>
> - For DH and MQV schemes using finite fields: ?The use of
> |p| = 2048 bits, and |q| = 224 or 256 bits is acceptable? (pages 8 and 9).
-131a is Jan 2011. -57 part 1 rev 3 DRAFT is May 2011, which is
later if you count drafts. But that draft says substantively the
same thing on this point, so it doesn't matter which you use.
> But due to the above change the time of key establishment
> has increased by 20-30 times. <snip> By default OpenSSL DH
> generates the private key with size same as the size of P parameter,
> so in our case private key size is 2048 bits.
I'd expect somewhat less. The number of modexps should be
linear in (on average 1.5 times) privatekey size, and for
tiny g (as allowed and as you use) each modexp should be
linear in group size, giving about 10x overall.
> When we set the DH->priv_key to a 256 bit random number before
> calling DH_generate_key(), [it's faster].
There is another method, though not documented. If you set
the 'length' field in dh_st before DH_generate_key, it will
generate a privatekey of that size, and matching publickey.
'length' is included in OpenSSL's DHparams (sub)structure, so
if you use that method of storing/encoding/etc your parameters
you get this 'for free'. It is currently used in the code only
for DH params (and keys) converted from DSA ones, because in DSA
the subgroup size (which limits the privatekey and signedvalue
size) is specified small compared to the group (but not tiny).
(I found it because I was experimenting with DSA-to-DH.)
> Can you please let us know the acceptable sizes of private key
> for 2048 bit P parameter? Are there any standards/specifications
> for the private key sizes?
Both -131a and -57.1 on which it is based, and -56a on which
both are based, specify exact sizes for the subgroup order q
significantly smaller than the size of the field order p, so
I think you're technically not conforming by using g=5 which
I believe won't ever generate a subgroup of such small order.
I don't believe there's any security *need* for an exact subgroup
size, but there's no security benefit to a subgroup larger than
is protected by the *group* against discrete-log, and the -57.1
(and 186-3) sizes were chosen to match these reasonably closely.
You should never use DH privatekey exceeding the subgroup order
(or not significantly, OpenSSL may go a fractional bit over) OR
the protection from the group which for 2048bit p is about 224.
-57 says for 128bit strength FFC you need 3072/256, and 186-3
standardizes just that for DSA, but -56a doesn't do so for DH.
The OpenSSL implementation can handle 3072/256 fine, so you
can use it if you want IF your counterparty(ies) also can, but
you can't claim it conforms to -56a (or -131a); this is noted in
one of the changes in the new draft of -57.1 (page 62).
I have seen authoritative statements DH privatekey size must be
twice the size=strength of the agreement, and -57.* and others
consistently do so, although I don't understand the reason for
this (as I do most other security parameters); reversing this
your agreement value has strength of half the privatekey size.
DH 2048bit p protects only 224 or maybe 256bit agreement, so
if you derive a 192 or 256bit AES key, you *don't* have 192
or 256bit strength only about 112. Symmetric ~112 does satisfy
NIST through 2030, and all other valid requirements I've seen;
but I've seen unconfirmed reports NSA and similar TLAs require
more, and I'd guess other governments and militaries the same
but I haven't seen them. If you're just doing AES 192,256 for
interop or fun, and don't actually need that strength, fine.
And if you need to meet crypto requirements at the NSA level,
you shouldn't be relying on advice from a mailing list.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
