On 8/22/20 7:26 PM, Kevin Kofler wrote:
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).
o You check p is prime, and (p-1)/2 is prime. This is expensive
for a random prime.
o 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).
o You check that p is prime, and q is prime.
o You check that y^q mod p == 1
o 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
