"B. Johannessen" <bob@???> wrote:
> sacrificial-spam-address@??? wrote:
>> I recently administered a stiff flaming to the Debian package maintainers
>> for exim4, and was rebuffed with the observation that the behaviour I was
>> complaing about was recommended by the exim specification, section 39.3.
>
> I'm not saying you're wrong and I don't mean to sound disrespectful, but
> I would recommend you also post a few words about why the Exim community
> should care about your opinions on this matter.
Why you should care? Because I'm Napoleon Bonaparte, Emperor of France!
Oh, wait a minute... even if that were true, it wouldn't be a good reason.
Actually, the exim community *shouldn't* care about my opinions, at least the
subjective parts that are just opinion. Only the objective truths matter.
Is there actually any benefit to changing D-H parameters?
> Also, with the exception of the recommendation of using 2048 bits rather
> then 1024, it sound's to me like Exim is 'erring on the side of caution'
> so to speak. Hardly the worst mistake you can make in cryptography...
If that's a well-considered decision based on knowing all the facts,
I have no objection. It just appeared to be based on misunderstanding.
In particular, regenerating the modulus periodically causes operational
problems for a considerable number of users (although that's mostly
due to gnutls's grossly excessive entropy consumption when generating
new moduli), and doesn't give any other advantage over using a slightly
larger fixed modulus.
It's also rather computationally expensive to generate large "safe primes",
which can be a PITA for small network appliances.
So it seems like somewhat misplaced caution, strengthening the deadbolt but
not reinforcing the hinge pins.
Every security standard that I can find that uses D-H considers very
long-lived prime moduli quite reasonable. Examples:
PKCS #3: Diffie-Hellman Key-Agreement Standard
(suggests generation by central authority rather than each user)
ssh: Uses a fixed modulus, but has provision for selecting from a menu.
See the file /etc/ssh/moduli, generally shipped with the distribution.
See RFC4419 for details, and a discussion of the security of
fixed D-H parameters,
RFC 4346, the TLS specification, specifically allows the Diffie-Hellman
parameters to be specified in the long-lived server certificate.
(sect. 8.1.2)
The OpenId spec specifies a particular default modulus.
RFC 2409 (Internet Key Exchange) and RFC2412 (Oakley) use a menu of
fixed parameters, one for each possible size. RFC 3526 provides
the (unique) parameters for sizes from 1536 to 8192 bits, and has
a useful appendix of matching conventional encryption strengths.
I can't find any references that recommend periodic D-H parameter
(also called D-H group) changes.
It seems like someone changing the air in their tires preiodically. No,
it doesn't do any harm, and I suppose it might be considered "erring on
the side of caution", but it doesn't do any good, either.
The correct thing to say is "you MAY change the parameters periodically,
but there's no significant security benefit to doing so."
There is one discrete logarithm algorithm (the so-called "index calculus
algorithm") that has most of its computation depending only on the
modulus p, after which any given discrete log problem g^x = y (mod p)
can be solved rapidly, but it takes L_p[1/2, c] time, i.e.
e^(O(1)*(log p)^(1/2) * (log log p)^(1/2))
This is impractical against moduli sized to resist number field sieve
algorithms that take L_p[1/3, c] time, i.e.
e^(O(1)*(log p)^(1/3) * (log log p)^(2/3))
Even before you reach 512 bits, this is far more efficient.
(The constants c are the O(1) terms, which I don't have at my fingertips
right now.)
In theory, if an algorithm nearly as efficient as the number field sieve
but result-independent were found, there would be a security benefit to
minimizing the number of keys generated with a particular modulus.
But no such algorithm is known.
