4 ms·

Rotating DH groups periodically is difficult. SSHv2, for example, has support for this. It takes a lot of computation to generate new groups, but then how do

Rotating DH groups periodically is difficult. SSHv2, for example, has support for this. It takes a lot of computation to generate new groups, but then how do the client and server agree on a group? Well, the server tells the client, and the client has to like it -- i.e., the client has to trust the server's group. This isn't better than just having a bigger nothing-up-my-sleeves group to begin with. That, ultimately, has been the solution the community landed at: nothing-up-my-sleeve curves for ECDH and EdDSA. The nothing-up-my-sleeve part is all about setting / agreeing to obvious and hard guidelines for generating and selecting curves before doing the selection, then you can see that a curve was generated and selected without any hidden agendas. We have several of these now that are generally thought to be secure, though, of course, it's hard to say for sure. It's a pretty good outcome.

ustolemyname 6y ago
If the client doesn't trust the server, the crypto protocol is a little irrelevant. I otherwise agree that we (ostensibly) are in a better place now with pre-defined curves.
- dcow 6y ago
  > If the client doesn't trust the server, the crypto protocol is a little irrelevant. What? No. The protocol is the only thing that is relevant. Peers don't generally trust each other a priori at all. They trust the protocol. If they can authenticate each other within the bounds of the protocol then they trust each other. If one party no has reason to distrust a certain protocol, then it should not be used as a basis for establishing trust. If the two peers can't agree on a protocol: stalemate. If I compromise your server and only serve weak protocols a responsible client won't authenticate me whereas a vulnerable client would take my word that my protocol is secure.
  - kortilla 6y ago
    We’re talking about rotation though, something that can be triggered when both sides are authed.
    - deleted 6y ago
      [deleted]
  - PeterisP 6y ago
    If don't trust a server, then any strong protocol that results in a secure shared secret or session key is trivially sidestepped by the server intentionally leaking these secrets or keys.
    - ben_w 6y ago
      Two interpretations of the same phrase: 1. Do you trust that 123.123.123.123 is the real https://example.com https://example.com ? 2. Do you trust the real https://example.com https://example.com to not leak? The protocol is for 1. You’re right that nothing can help with 2.
    - dependenttypes 6y ago
      I trust the server only after I verify its PK. SSH performs mutual authentication.
john_alan 6y ago
Ephemeral ECDH over 25519 solves all of these issues. How is it not standard.
- cryptonector 6y ago
  Did I say it doesn't? Read carefully.
  - john_alan 6y ago
    Lol
- zahllos 6y ago
  It is a standard. RFC 7748. It is also a part of TLS 1.3.
zahllos 6y ago
Rotating the group was never the point or the problem. The problem was that typically Linux distributions shipped a 1024-bit hard coded DH parameters file and most people didn't bother to change it. Groups with low security remain the default for things like IPsec configurations in firewalls and so on, even now. It's perfectly fine to keep a fixed DH parameter choice. In some senses that's exactly what using ed25519 is. The point is that the strength of the group that results is sufficient to mean that even the NSA with their budget can't break it, even targeting that one curve. It's just that elliptic curves are much more efficient than picking a single 2048-bit or 4096-bit DH group, so why bother with that when we can pick a 256-bit EC group instead? The nothing up my sleeve part isn't particularly relevant to this. The choice of elliptic curve is quite involved so it doesn't make sense to simply spit out a random field and random curve coefficients. Moreover given the server communicates a prime and a generator for the DH group, the client is quite free to do some primality testing and reject the DH group if it wanted to. Also, there's a nice body of work showing NUMS can be manipulated. You might be interested in https://bada55.cr.yp.to/ https://bada55.cr.yp.to/ I think you're muddling the concepts a bit here. Nothing up my sleeve isn't the main and only argument that justifies the move to ed25519; the original group wasn't backdoored in the first place. Just potentially within range of the NSA.

ustolemyname 6y ago

If the client doesn't trust the server, the crypto protocol is a little irrelevant. I otherwise agree that we (ostensibly) are in a better place now with pre-defined curves.

dcow 6y ago
> If the client doesn't trust the server, the crypto protocol is a little irrelevant. What? No. The protocol is the only thing that is relevant. Peers don't generally trust each other a priori at all. They trust the protocol. If they can authenticate each other within the bounds of the protocol then they trust each other. If one party no has reason to distrust a certain protocol, then it should not be used as a basis for establishing trust. If the two peers can't agree on a protocol: stalemate. If I compromise your server and only serve weak protocols a responsible client won't authenticate me whereas a vulnerable client would take my word that my protocol is secure.
- kortilla 6y ago
  We’re talking about rotation though, something that can be triggered when both sides are authed.
  - deleted 6y ago
    [deleted]
- PeterisP 6y ago
  If don't trust a server, then any strong protocol that results in a secure shared secret or session key is trivially sidestepped by the server intentionally leaking these secrets or keys.
  - ben_w 6y ago
    Two interpretations of the same phrase: 1. Do you trust that 123.123.123.123 is the real https://example.com https://example.com ? 2. Do you trust the real https://example.com https://example.com to not leak? The protocol is for 1. You’re right that nothing can help with 2.
  - dependenttypes 6y ago
    I trust the server only after I verify its PK. SSH performs mutual authentication.

john_alan 6y ago

Ephemeral ECDH over 25519 solves all of these issues. How is it not standard.

cryptonector 6y ago
Did I say it doesn't? Read carefully.
- john_alan 6y ago
  Lol
zahllos 6y ago
It is a standard. RFC 7748. It is also a part of TLS 1.3.

zahllos 6y ago

Rotating the group was never the point or the problem. The problem was that typically Linux distributions shipped a 1024-bit hard coded DH parameters file and most people didn't bother to change it. Groups with low security remain the default for things like IPsec configurations in firewalls and so on, even now. It's perfectly fine to keep a fixed DH parameter choice. In some senses that's exactly what using ed25519 is. The point is that the strength of the group that results is sufficient to mean that even the NSA with their budget can't break it, even targeting that one curve. It's just that elliptic curves are much more efficient than picking a single 2048-bit or 4096-bit DH group, so why bother with that when we can pick a 256-bit EC group instead? The nothing up my sleeve part isn't particularly relevant to this. The choice of elliptic curve is quite involved so it doesn't make sense to simply spit out a random field and random curve coefficients. Moreover given the server communicates a prime and a generator for the DH group, the client is quite free to do some primality testing and reject the DH group if it wanted to. Also, there's a nice body of work showing NUMS can be manipulated. You might be interested in https://bada55.cr.yp.to/ https://bada55.cr.yp.to/ I think you're muddling the concepts a bit here. Nothing up my sleeve isn't the main and only argument that justifies the move to ed25519; the original group wasn't backdoored in the first place. Just potentially within range of the NSA.