Christopher Engelhard wrote:tl;dr should we make it easier/automatic for users to use the Diffie-Hellman parameters defined in RFC7919?While I understand the motivation behind the RFC (interoperability, safety against intentionally or unintentionally bad parameters), hardcoded parameters sound suspicious to me. How do we know that these are not chosen to allow the NSA or some other country's equivalent agency to decrypt the conversation?
TL/DR:
Most "randomly" chosen values for primes today are known to be subject to small group attacks. Getting this right is difficult (which I'll demonstrate below). The chosen primes were vetted by the TLS working group based on physical constants and a generation scheme that has the required safe criteria. That is these values meet the requirements that we already know. We can all recheck them. The chances that the NSA has an attack, that happens to work on primes that someone else (IETF) generated, and doesn't work on all DH primes is pretty unlikely. As simo says, If you are worried, don't use DH. If you aren't using one of these primes, your DH connection is probably vulnerable to active attacks.
Longer explanation:
In order to do DH safely, you need to make sure that the public
key you are provided is in a large subgroup. This can be checked
in the following ways:
- The prime 'P' is a safe prime (sometimes incorrectly called a strong prime. This means the p is prime and (p-1)/2 is prime (in this case (p-1)/2 is called a Sofie-germaine prime).
- You check p is prime, and (p-1)/2 is prime. This is expensive for a random prime.
- You check that the public key y is < p, and != 0, 1, or -1 mod p. This check is very fast.
- The prime 'P is not a safe prime, but you know a large prime 'q' which is a factor of (p-1).
- You check that p is prime, and q is prime.
- You check that y^q mod p == 1
- You check y != 1 or -1
If you precheck known 'P' values you can skip the very expensive prime checks (because we've already checked those values and they are known to be good). To make matters worse, It's very expensive to generate a safe prime for large prime values. If you search the internet about how to do this, they well give you instructions on how to generate a non-safe prime with large q, but none of our common protocols include a q value, which means you cannot do either the prime check or the y^q mod p ==1 check, and thus a man in the middle attacker can supply a q that falls in a small subgroup and eaves-drop on your connection.
TLS 1.3 allows you to only connect if the server is using a known prime, which has already been vetted as a safe prime. If you aren't using and requiring these primes, you basically have the following choices:
1) use RSA and loose PFS.
2) use ECDH (which will likely fall to quantum computers first).
Since Quantum computers will ultimately remove PFS, ECDH is
probably your best bet. But then you are again trusting in fixed
sets of Curves that came from somewhere, and if you are paranoid
about the NSA, well....
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
