On 23.08.20 04:26, Kevin Kofler wrote:
> 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?
Good point, that's a thorny issue in general.
I have, of course, not way to disprove that, but those parameters are
not just some random magic numbers, they're derived from a public,
defined & simple [1] formula, using as far as possible common constants
with no known relation to the DHE problem. This is no different than the
process that gives us Ed25519 [2], although admittedly that one is more
extensively explained in the relevant RFC.
There are mathematical ways of looking for trapdoors, and having the
method that created the number known makes such analysis feasable.
In the ideal case, (1) server operator A generates & validates & uses
safe parameters, and (2) user B knows & trusts A to have done so.
However, in general while (1) might well be true, but (2) usually isn't.
So the tradeoff is 'unvetted but secret' vs. 'highly vetted but known to
the NSA'.
There's probably no good answer here (other than not using FFDHE, of
course), but I think given that Fedora by default also uses the
potentially-NSA-tainted NIST curves & TLSv3 with FFDHE, encouraging use
of RFC7919 generally removes some potential security issues while not
introducing attack vectors that we already deem not significant (in
default configurations - what anyone deems significant for their own
system is of course entirely their business).
Christopher
[1] for a given definition of simple - RFC7919 primes are defined as
p = 2^b - 2^{b-64} + (floor(2^{b-130}*e)+X) * 2^64 - 1
where b is the bitsize and X is the smallest integer that creates a safe
prime.
[2] https://tools.ietf.org/html/rfc7748#appendix-A
There's some discussion of the general problem of validating DHE
parameters here:
[3] https://eprint.iacr.org/2019/032.pdf
_______________________________________________
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
