On Sun, Apr 07, 2019 at 07:25:38PM +0000, admin--- via Exim-dev wrote:
> > If so, assuming the p for a parameter has been chosen as a "safe prime",
> > q is entirely dependent on p - which we have from the PEM representation.
> > Why do we care about loading q?
>
> FWIW: I have no idea. I almost knew, once, when Viktor explained it before.
> This again is part of why I try to stick to using crypto-engineering, not
> crypto policy, and defer to experts.
There are two common representations of FFDHE groups:
* (p, g) with just the modulus p and a generator g of a suitable
subgroup of the non-zero residues mod p under multiplication.
* (p, g, q) with the modulus p, a generator g of a suitable
subgroup of the non-zero residues mod p under multiplication,
and the order (element count) of the subgroup generated by g.
The equivalent symmetric strength depends on p with brute-force attacks
roughly as difficult as for RSA keys of the same size, and also on q,
with attack cost of half the bit count of q.
Thus, e.g. for 80-bit security (now passé), you'd go with a 1024-bit
modulus and a generator of a subgroup with 2^160 elements.
Because exponents can be reduced mod q, computations are faster in (p,
g, q) groups when q is chosen much smaller than p, to match the
symmetric strength of the construction.
With "safe" primes, there is indeed no point in specifying q, unless
the library or protocol wants to work with (p, g, q). With "safe"
primes there are no small subgroups other than {1, -1}. With (p, g, q)
one can check that q is prime and that the order of g is q, and then
be sure to not be at risk of small subgroup issues.
These days, the trend is to use ECDHE, but when using FFDHE, to use
one of the RFC7919 groups.
--
Viktor.
