I'm using a Diffie-Hellman key exchange to encrypt data using AES-256. The prime number I'm using is the one from the 8192bit group specified in RFC 3526 (page 6).

Page 7 suggests that, with a 620 bit exponent, that's an equivalent key strength of 310 bits, so, large enough for AES-256. It also suggests that the 6144bit prime with a 540 bit exponent would be good enough (270 bits).

Now, both of these are rather slow. The larger one results in the exchange taking about two seconds in my scenario.

My question therefore:

Am I being ridiculous? Should I use a smaller prime, maybe even AES-128 with the 2048 bit prime and a 320bit exponent? Did I maybe misunderstand something entirely?

For context: Speed isn't all that critical. I need this encryption to be very strong for about the next 10 years (at the very most). If that takes two seconds to do, so be it.

  • In case it matters much: I'm using salted key-stretching with 2^16 iterations (enough?) before encrypting. AES is running in CBC mode. The hash is sha512. – Stefano Palazzo Jul 13 '11 at 8:00
  • I'm not sure you can be sure of anything being very strong for the next ten years. With quantum computing you could have a huge shift in what's safe and what's not. – k to the z Jul 13 '11 at 15:17
  • Yeah indeed, though in my (completely made up) scenario, having this kind of assurance only means you don't have to bother changing the system any time soon. If a breach starts to seem more likely, it would be possible to just change the system, just very inconvenient. – Stefano Palazzo Jul 13 '11 at 15:32
  • I see. Good luck to you. – k to the z Jul 13 '11 at 18:41
  • @StefanoPalazzo Key stretching and a salt is completely unnecessary if you are deriving the key from DH. It's only important if the key is coming from a potentially low-entropy and possibly re-used human password. As for AES being in CBC mode, remember that CBC is malleable. You really must use authentication with something like HMAC if you want to use CBC safely. – forest Jun 12 '18 at 9:08

AES-256 and a 8192-bit DH modulus are both overkill. Comparing them with each other is a delicate exercise which verges on the meaningless, since both are quite far into the realm of "can't break it now, can't do it in 30 years either". You can have a look at this site for information and calculators on various ways to estimate relative strength of symmetric and asymmetric algorithms.

Practical parameters which can be recommended now for proper security are AES-128 and a 2048-bit DH prime modulus (with 256-bit exponents).

  • 3
    <Tin Foil hat ON>Overkill is a relative term, as it entirely dependent on what you're protecting. The speed difference isnt that bad between AES256 and its' 128bit version, so might as well use the better one, just in case. <Tin Foil hat OFF> Having said that, AES-128 is quite sufficient for anything less important than national-security. – Marcin Jul 13 '11 at 12:27
  • 3
    Hey @Marcin is that the 2012 tinfoil hat with quad layer mesh and extended VHF filtering? Does it come in blue? – this.josh Jul 13 '11 at 16:44
  • @Marcin Really the only tangible thing that makes AES256 any "better" than AES128 is the fact that it uses a few more rounds which may protect it from future cryptanalysis, not that it has a larger keyspace (though the keyspace may be relevant to multi-target attacks for other threat models). – forest Jun 12 '18 at 9:10

Yes. Your approach is way over the top. AES-128 and a 2048-bit Diffie-Hellman group (with a 256-bit exponent) is more than sufficient. Even with those parameters, it is exceptionally unlikely that the crypto-math is the weakest link in your system. Your system is much more likely to be broken by bypassing the crypto, than by breaking the crypto head-on.


Yes. You are ridiculous in choosing AES-256 and 8192 bit DH.

There are several things which you may want to consider.

  1. Are you protecting enterprise data ? If yes, then you can actually be happy with AES-128 and 2048 bit DH. The reason is simple. AES-256 has export control polices and if you want to package your app, then you must use special jar(if you are using JAVA) etc.. But, you can use AES-256. No probs. Also, it is slow if you are using anything above 2048 bit DH. You must also take care of the system on which data will be decrypted. It shouldn't take too much of time. Lots of Fortune-1000 companies still use 3DES and you are using AES which is a far better algorithm. So you are safe with AES-128 and 2048 DH

  2. Are you protecting data private to a small closed group? Then, you just need AES-128 and 2048 bit DH. Anything more than that is not needed as the time frame you are looking at is just 10 years.

If you really want more security and want to future proof it, then DH is the wrong way forward. Elliptic Key Cryptography is best suited for this. Not many resources in this direction. But, it is definitely worth it.

Bottom line - Size isn't everything in Cryptography. The correct choice of algorithms and implementation is what that actually counts. Go ahead with AES-128 and 2048 bit DH. It is safe.


@stefano - Hi, There are several things which must be considered since you said governmental espionage in journalists. Governments never tell us their real capacity. So, it is possible that they have already have infrastructure to crack AES-256. NSA won't approve something that goes above their head. Also, AES is not the highest level of security available. It forms the tier-2 in NSA algorithm stack if my memory is correct. But, we have limited options. So we can go with AES-256 to provide better security.

To provide better security in the long term, you must consider Elliptic Key Cryptography. It is the only system that is available in public that can future proof things in a reasonable manner. DH can be used when you want to transfer data between 2 or more parties. I'm assuming that you know the basics of asymmetric key cryptography and why you need DH. If you are storing data in your system and not transferring it, there is no need for DH or RSA or Elliptic Key Cryptography.

Also, you can use a very strong password which will directly influence the key selected in AES through salting and SHA-512, This will provide you with the ability to change the encrypted text once in a while so that a weak key that comes up in some journal will not trouble your encrypted data. 256-bit exponent is fine. But, for your current scenario, a little higher exponent can do a better job.

  • Fantastic! Actually, AES128 is about twice as fast compared to 256 (in my particular case). And using a 2048bit modulus is plenty quick enough. This is very appeasing. Do you agree with @Thomas on the 256 bit exponent? My threat model, by the way, is governmental espionage on journalists, it's not for holiday pictures. :) – Stefano Palazzo Jul 13 '11 at 14:36
  • Wow, thanks a lot for your effort. You should put all of these comments into your answer to make them easier to read. You should be able to delete the comments (or maybe that's at 15 rep, if not, ask one of the moderators to do it for you). – Stefano Palazzo Jul 13 '11 at 16:18
  • @Stefano - Done – Andrew Anderson Jul 13 '11 at 16:21
  • 2
    @Stefano: the 256-bit exponent comes from generic discrete logarithms attacks, which work with effort 2^(n/2) when the range of exponents has size n bits. So 256 bits for "128-bit security". – Thomas Pornin Jul 13 '11 at 16:32
  • 3
    @Stefano: as for your threat model, when your system will be successfully attacked, it will not be through cryptanalysis. A key logger, a discrete hidden cam... as so much easier to plant than 128-bit AES to break ! If only because technology for key loggers or small cams already exists. – Thomas Pornin Jul 13 '11 at 16:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.