4 ms·

Any reason not to just settle on ECDH for new applications?

tptacek 11y ago
It's Complicated. All else equal, yes, you should use ECDH over a good curve, implemented carefully in a curve library you yourself did not write, which library has been carefully reviewed for flaws. But if you don't have access to that code on every platform you might need to deploy on, it might be better to do DH-2048 than to use crappy curve code. Basically, your best choice right now is Curve25519. If you can't get a trustworthy Curve25519, though, it might be tricky to pick between DH-2048 and {other curve software}.
- MichaelGG 11y ago
  Why is there not more hedging of bets by implementing both? That way if one is broken or improperly implemented, there's a bit of safety. Apart from being ugly is there a reason this doesn't work?
  - grrowl 11y ago
    You're increasing your attack surface area. Do you use both, do you let the server choose, do you let the client choose? What if the client requests the lower-security crypto? What if what the client asked you is different to what you think you were asked from the client (MITM)?
    - wfunction 11y ago
      I think the question meant literally both, always.
      - MichaelGG 11y ago
        Yeah, setup one channel and then another inside that. Seems like hash functions could be used this way, too. For instance, are there any practical attacks in sight that'd work simultaneously on both MD5 and SHA1? 3DES does this with DES so it probably works in general?
        johncolanduoni 11y ago
        This gets complicated fast, especially with hashes[1]. Like most of crypto, you shouldn't do it unless you have a team of experts who publicly vetted the algorithm and implementation. [1]: http://security.stackexchange.com/questions/83881/is-using-the-concatenation-of-multiple-hash-algorithms-more-secure http://security.stackexchange.com/questions/83881/is-using-t...
- guelo 11y ago
  I understand the reasoning for this recommendation but as this paper shows there is also a danger in going along with what's popular, even if it's the best currently recommended practices. If you as a reasonably well-versed engineer can come up with a custom implementation it would be more likely that you'll be protected from mass surveillance. Even if your implementation has some weaknesses you won't be caught up in a dragnet. Assuming the eye of Sauron does not look right at you, meaning a government-level adversary targets you directly.
  - tptacek 11y ago
    The opposite is true: if you implement ECDH yourself, you aren't unlikely to end up with software that thousands of different people will be able to break with their laptops. It's tricky to get right.
    - lmm 11y ago
      Any handspun crypto will likely have trivial flaws. But they might escape the NSA's notice, in the same way that a hand-rolled CAPTCHA can sometimes prevent more spam than a better-designed but widely-deployed one?
      - pja 11y ago
        Pretty much: Odds are that, if you roll your own, you’ll make mistakes which make your code trivial to break for a motivated attacker that is willing to put the effort into targeting you personally. It’s also quite possible that the NSA/GCHQ/5-Eyes will notice that your communications are 'interesting, because different' and mark them to be stored in perpetuity in case they ever do decide that you’re of interest so that they can go back and break it all then. So, how lucky are you feeling?
      - johncolanduoni 11y ago
        I don't think many people (let alone businesses) would rather introduce a risk of being exploited by a hacker than a huge government agency that could care less about their existence. And if you are in a position where the NSA does care to look at you closely, bad crypto is going to make their job easy.

It's Complicated. All else equal, yes, you should use ECDH over a good curve, implemented carefully in a curve library you yourself did not write, which library has been carefully reviewed for flaws. But if you don't have access to that code on every platform you might need to deploy on, it might be better to do DH-2048 than to use crappy curve code. Basically, your best choice right now is Curve25519. If you can't get a trustworthy Curve25519, though, it might be tricky to pick between DH-2048 and {other curve software}.

MichaelGG 11y ago
Why is there not more hedging of bets by implementing both? That way if one is broken or improperly implemented, there's a bit of safety. Apart from being ugly is there a reason this doesn't work?
- grrowl 11y ago
  You're increasing your attack surface area. Do you use both, do you let the server choose, do you let the client choose? What if the client requests the lower-security crypto? What if what the client asked you is different to what you think you were asked from the client (MITM)?
  - wfunction 11y ago
    I think the question meant literally both, always.
    - MichaelGG 11y ago
      Yeah, setup one channel and then another inside that. Seems like hash functions could be used this way, too. For instance, are there any practical attacks in sight that'd work simultaneously on both MD5 and SHA1? 3DES does this with DES so it probably works in general?
      - johncolanduoni 11y ago
        This gets complicated fast, especially with hashes[1]. Like most of crypto, you shouldn't do it unless you have a team of experts who publicly vetted the algorithm and implementation. [1]: http://security.stackexchange.com/questions/83881/is-using-the-concatenation-of-multiple-hash-algorithms-more-secure http://security.stackexchange.com/questions/83881/is-using-t...
guelo 11y ago
I understand the reasoning for this recommendation but as this paper shows there is also a danger in going along with what's popular, even if it's the best currently recommended practices. If you as a reasonably well-versed engineer can come up with a custom implementation it would be more likely that you'll be protected from mass surveillance. Even if your implementation has some weaknesses you won't be caught up in a dragnet. Assuming the eye of Sauron does not look right at you, meaning a government-level adversary targets you directly.
- tptacek 11y ago
  The opposite is true: if you implement ECDH yourself, you aren't unlikely to end up with software that thousands of different people will be able to break with their laptops. It's tricky to get right.
  - lmm 11y ago
    Any handspun crypto will likely have trivial flaws. But they might escape the NSA's notice, in the same way that a hand-rolled CAPTCHA can sometimes prevent more spam than a better-designed but widely-deployed one?
    - pja 11y ago
      Pretty much: Odds are that, if you roll your own, you’ll make mistakes which make your code trivial to break for a motivated attacker that is willing to put the effort into targeting you personally. It’s also quite possible that the NSA/GCHQ/5-Eyes will notice that your communications are 'interesting, because different' and mark them to be stored in perpetuity in case they ever do decide that you’re of interest so that they can go back and break it all then. So, how lucky are you feeling?
    - johncolanduoni 11y ago
      I don't think many people (let alone businesses) would rather introduce a risk of being exploited by a hacker than a huge government agency that could care less about their existence. And if you are in a position where the NSA does care to look at you closely, bad crypto is going to make their job easy.