# Diffie-Hellman Secret Exponent Size and Shared Secret Usage [closed]

I'm developing my own protocol and I'll use Diffie-Hellman to achieve PFS. It will work in this way:

The symmetric encryption algorithm will be AES_256_CBC.

The DH parameters will be: P: a 2048-bit safe prime as defined in RFC 3526. Generator: 2 (also defined in RFC 3526). Secret Exponent: a 512-bit ephemeral random number *

• If it is true that the secret must be twice the security level, it should be OK

Only the secret exponent will be different every time and P and G will be always the same (forever).

The key-exchange will be authenticated with RSA-2048.

Once the shared secret is computed, it will be used to derive a 256-bit symmetric key (perhaps with HKDF) to setup a AES-256 cipher that will run in CTR mode to generate a 1024-bit random material that will be splitted in four parts:

2 x AES-256 keys (write and read keys)
2 x HMAC-SHA256 keys [write and read keys, 256-bit each]

-

## closed as unclear what you're asking by D.W., rath, e-sushi, Ricky Demer, AFSDec 30 '13 at 5:30

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

A weird choice. 2048 bit modulus has about 112 bits of security, a 512 bit exponent 256 bits of security. A 3000 bit modulus with a 256 bit exponent would have a higher security level and similar performance. Or use ECC which is about 10x as fast. –  CodesInChaos Dec 11 '13 at 13:30
@CodesInChaos Just creating a DH API, you are certainly correct with regarding the modulus limitation above. It may be tricky to find static parameters for such keys however. ECDH should certainly be preferred for these kind of requirements. Amended answer. –  owlstead Dec 11 '13 at 17:02
What's the question? The entire body of the question seems to be a bunch of sentences about what you are planning to do, but I can't see any specific question. We expect questions on this site to ask a specific, objectively answerable question. –  D.W. Dec 29 '13 at 0:24

The scheme itself seems pretty standard, so it should be secure, if defined and implemented correctly. A simple textual descripion as you have provided here is not enough to prove your protocol secure. The authentication part only describes the RSA algorithm and key size - it does not specify how trust is established, nor does it define how the session keys are to be used.

I don't really understand your key derivation part; if you use HKDF and use the expand funtionality (with different info fields) you can generate multiple keys without having to resort to AES-CTR.

You may want to adhere to to NIST SP 800-56A Rev 2. This document also defines extract-than-expand key derivation schemes. One important issue with it is that it defines a lot of KDF's, so it will lead to another choice. It does certainly contain a lot of security hints regarding Diffie-Hellman which you may want to consider.

[EDIT]

As for the secret exponent size, the size of 512 bit is certainly enough, but the size of the modulus is very small. This means that the security is bounded by that of the modulus. It is very tricky to talk about effective key sizes within Diffie-Hellman. To get a good idea about possible key sizes, please take a look at the NIST or ECRYPT recommendations, e.g. at http://www.keylength.com/ . For good performance at higher key sizes, it is recommended - also by NIST - to switch to Elliptic Curve Diffie-Hellman. A 521 bit or 512 bit Elliptic Curve seems more appropriate for your needs.

-
Thanks for the answer. So 512-bit secret size is good, right? PS: I'll use only HKDF and not AES-CTR! –  user2908183 Nov 15 '13 at 10:45
Yes, 512 bit secret exponent seems quite large. If used in DH, then the security is bounded by the 2048 bit size of $p$. There is a table in 56A... –  owlstead Nov 15 '13 at 11:15
Do you know what is the secret and p size used in TLS? –  user2908183 Nov 15 '13 at 19:52
Not out of the top of my head, but here comes stackexchange to the rescue: security.stackexchange.com/questions/42253/openssl-dh-modp-size –  owlstead Nov 16 '13 at 10:34