2

In our product (embedded system), so far we were using diffie-hellman-group1-sha1 with hmac-sha1. But due to security concern we are planning to use diffie-hellman-group14 for key exchange and hmac-sha2-256 for HMAC.

Is it ok to use diffie-hellman-group14-sha1 along with hmac-sha2-256. Would diffie-hellman-group14-sha1 and hmac-sha2-256 combination be good from performance and security point of view?

Would there be much performance impact if we use diffie-hellman-group-exchange-sha256 and hmac-sha2-256 combination.

Since we are using embedded system so we want to maintain a fine balance between security and performance.

I would be very thankful if people can provide their views?

  • As for the performance question, I did a small benchmark once with combinations of ciphers, MACs and KexAlgorithms. Feel free to re-run those test on your environment to see which combination is the fastest in your setup. – ckujau Nov 19 '15 at 22:11
2

The unstated context of this question is an SSH server: these are negotiable cryptographic options in the SSH transport protocol. You may want to update the question to indicate this.

From the form of your question, I first want to clear up something. When you ask:

Is it ok to use diffie-hellman-group14-sha1 along with hmac-sha2-256. Would diffie-hellman-group14-sha1 and hmac-sha2-256 combination be good from performance and security point of view?

... this appears to imply that you think there's something to be concerned about in the mere combination of these algorithms. There isn't; they are entirely independent. These:

  • diffie-hellman-group1-sha1
  • diffie-hellman-group14
  • diffie-hellman-group-exchange-sha256

... are key exchange algorithms. They are used early in the transport protocol to establish the session keys (encryption/MAC), authenticating the server in the process. These:

  • hmac-sha1
  • hmac-sha2-256

... are names of MAC algorithms used to implement integrity checking for user data subsequently transmitted by the protocol. These are used later, with keys derived from the output of the key exchange. If you're asking the question because you think there might be some issue in "mixing" SHA-1 and SHA-256 -- so far as I know, there is no reason to be concerned about that in this scenario.

Would there be much performance impact if we use diffie-hellman-group-exchange-sha256 and hmac-sha2-256 combination.

Now you've introduced the "group exchange" version of the SSH Diffie-Hellman key exchange. This allows the server to use locally configured Diffie-Hellman parameters (finite groups), instead of the fixed groups prescribed by the "group1" and "group14" exchanges. The performance impact would be determined by the groups you provide, mostly by the size of the groups in question. You can reduce the overhead by using smaller groups, with a corresponding reduction in security. Keep in mind that the client requests a modulus by size, so you must provide groups large enough to satisfy your clients.

  • Thanks for your response. Being new to cryptography, I intermixed many things together. My main concern was issues involved in mixing SHA-1 (in key exchange) and SHA-256(in hmac). But you explained them in clear way. This is what I was expecting. Thanks a lot. – Rakesh Gupta Mar 7 '14 at 8:34
  • Could you please explain, what's meant by "use of SHA-256 in cryptography"? Does it indicates use of SHA-256 for HMAC calculation or it's use in Diffie Hellman Key Exchange or both ? – Rakesh Gupta Mar 7 '14 at 8:42
  • I didn't write the phrase "use of SHA-256 in cryptography" anywhere, so I'm not sure what you're asking; however, both the key exchange and the transport integrity checking make use of a hash function to do their jobs. The key exchange uses it as part of a digital signature; the transport uses it via keyed HMAC to provide integrity and origin authentication for user data. – Richard E. Silverman Mar 7 '14 at 17:30
  • I asked it in general not based on ur comments. Thanks for clarification. – Rakesh Gupta Mar 7 '14 at 18:55
0

The other answer doesn't seem to answer the question, only clarify the usage of the terms and bad assumptions. So if you want to know which is better, diffie-hellman-group14-sha1 vs diffie-hellman-group14-sha1, then here's my attempt at it.

One part of the question is between SHA2 and SHA1. SHA2 is stronger to SHA1, and diffie-hellman-group-exchange-sha256 is SHA2.

The other is the primes used in the exchange. The group14 primes are considered strong (2048 bits), but they are publicly known. The group exchange primes depend on a server side list of primes, and client side restrictions. In OpenSSH on Linux, you have a file /etc/ssh/moduli which contains these. That file is provided by the distro, so they are also publicly known, but you can change them.

To see a count of each size you have now, try something like:

awk '$1 != "#" {print $5+1}' /etc/ssh/moduli | sort | uniq -c

Which on a few Ubuntu 16.04 systems I tested say the same thing:

 49 1536
 40 2048
 37 3072
 38 4096
 37 6144
 36 7680
 29 8192

So potentially your group exchange might use very small keys sized 1536. So if you remove all the smallest ones to match group14 (Oakley Group 14, size 2048), it should probably be better (since sha256 is better than sha1), and also because you could control them to be not publicly known. The change in size might have no effect if the clients are limiting their own min and max anyway... but it can't hurt. or if they prefer a large size but min is low, a downgrade attack like LogJam may work.

To trim down your file to contain only primes 2048 and larger (still publicly known), maybe you would use:

awk '$1 == "#" || $5 >= 2048 {print $0}' /etc/ssh/moduli > /etc/ssh/moduli.tmp
mv /etc/ssh/moduli /etc/ssh/moduli.bak.$(date +%s)
mv /etc/ssh/moduli.tmp /etc/ssh/moduli

And to make a new file of unique primes, perhaps not publicly known (there is potential overlap of course), you can generate them (which may take hours):

mv /etc/ssh/moduli /etc/ssh/moduli.bak.$(date +%s)
ssh-keygen -G /tmp/moduli -b 2048
ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli

I suggest restarting sshd after doing this.

Also see https://blog.gdssecurity.com/labs/2015/8/3/ssh-weak-diffie-hellman-group-identification-tool.html

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.