1

Let's say that one does not trust ECC a lot, and values confidentiality over authenticity (perhaps simply for the reason that MitM is more difficult than passive eavesdropping and decryption later on). In this case one might use classical DHE for key exchanges, and ECDSA for signatures.

Is there anything problematic in doing so? In order to have high encryption strength, one would use large DH params (16k perhaps) since the classical DHE key exchange is not computationally expensive, and faster ECDSA signatures on the exchanged DHE keys. Further, this combination is not part of the TLS specification (as far as I know), why not?

EDIT: Just to clarify, it appears this is indeed not part of the specification, but I am seeking answers as to why not, or if this would be a bad idea from a security perspective.

2

In order to have high encryption strength, one would use large DH params (16k perhaps) since the classical DHE key exchange is not computationally expensive,

I can't give you hard numbers for the speed. The openssl speed command does not seem to offer the benchmark for regular (finite field) Diffie-Hellman.

This answer offers guidance on practical DH-parameter sizes:

this combination is not part of the TLS specification (as far as I know)

Correct. There is no combination of _DHE_ and _ECDSA in the current cipher suite assignments.

$ wget https://www.iana.org/assignments/tls-parameters/tls-parameters.txt
$ cat tls-parameters.txt | grep -i _ecdsa_  | awk '{print $2}' | cut -d _ -f2 | sort | uniq -c
     17 ECDH
     21 ECDHE
  • Thanks for showing that it is not a part of the TLS spec. In particular I wasn't aware of the IANA list, which is useful. – user1207217 Jul 6 '15 at 19:03
1

The classical DHE is computationally expensive, at least as these things go. This rarely matters (a normal PC can still do hundreds of DHE per second), but if you are in a situation where computing budget is tight (e.g. small embedded systems) then ECDHE is substantially cheaper.

With "normal" implementations, the cost of DHE is proportional to p2r, where p is the size of the modulus, and r is the size of the secret exponent used in DHE. r needs not be larger than, say, 256 bits, IF the DH parameters are such that the size of the subgroup does not have small prime factors. Unfortunately, TLS gives no way to the server to convey to the client the size of the subgroup, so a cautious client will need to use a secret DH exponent at least as big as the modulus, raising the cost to p3. Even if a "small" exponent can be used, a DHE with a 16384-bits modulus is going to be expensive (depending on the size of the secret exponent, it will be between 64 and 512 times the cost of a more mundane 2048-bit DHE modulus). Perhaps more importantly, an oversized DH modulus may not work at all, because many implementations have internal limitations for various engineering reasons.

There is no defined cipher suite that combines a classic DHE, and ECDSA signatures. So the question may be moot anyway. Such cipher suites could be conceptually defined; it would not be hard; but it has not been done, hence implementations don't support it.

  • Any comments on why its not in the spec? Simply anybody didn't dream this up, is a silly idea in the fact of ECC, or is problematic in a security perspective? – user1207217 Jul 6 '15 at 19:02
  • It is not problematic -- no more than DHE is by itself (the problem with DHE being that the subgroup order is not transmitted). But people who defined the ECDSA cipher suites probably felt that it "made no sense" to use elliptic curve for signatures but not for key exchange. – Tom Leek Jul 6 '15 at 19:11
  • That being said there is no reason to not use 4096 bits too. On my openvpn we only use 4096 bits. In certificates and key exchange. Its widely supported – Freedo Jul 8 '15 at 14:53

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.