Re: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05

[Watson Ladd <[e-mail]>]

<chop>

>
> Using a keyed PRF instead of e
> ------------------------------
>
> Two objections were made about the use of e --
>
> (a) because of its definition as the base of the natural log, e has some
>     sort of special internal structure that might make FFDH groups
>     derived from it more vulnerable to analysis.
>
> (b) that starting from e and counting up biases the randomized prime
>     selection by only fiddling certain bits in the prime while counting.
>
> I've spoken with several cryptographers about (a) who dismissed it as
> totally implausible.  I haven't gotten much feedback about (b).
>
> The proposed change is to select the "random" bits by using a keyed PRF,
> or KDF, with the seed or additional input incrementing until a safe
> prime is found.
>
> I confess this sounds better than using e to me, simply because the
> construction avoids any claims about (a) and (b).
>
> One approach would be to use [HKDF] with SHA-512, with the initial key
> material ("IKM") and info parameter both set to "TLS-ffdheNNNN" (where
> ffdheNNNN is the ASCII name of the group), and a salt that we increment
> until a safe prime is found at the right length.
>
>   [HKDF] https://tools.ietf.org/html/rfc5869

I don't see what the gains of this approach are over the existing one.
(b) is valid as far as it goes but I don't think it's a real concern.

>
>
> Avoiding the high-64 and low-64 bits set to 1
> ---------------------------------------------
>
> The high 64 bits and the low 64 bits of these primes are set to 1
> specifically to facilitate Montgomery and Barrett reduction.  This is
> similar to the choices made in the MODP FFDHE groups.
>
> The objection to this is that the special structure may make these
> groups more vulnerable to attacks that we don't know about, potentially
> making them equivalent to groups the size of the inner bits or
> something.
>
> I'd like to think that if any advances had been made against the DLOG
> problem for groups with this special form, they would be published
> already, since the first Oakley group is 768 bits, with the top and
> bottom 64 bits all set to 0xff, so this should be in-range and
> high-profile for anyone who wants to take a crack at it:
>
>   https://tools.ietf.org/html/rfc2409#section-6.1
>
> But i'm not a cryptographer, i know of no such attack, and i have no
> idea how to judge the likelihood of something like this existing.
>
> I also don't know how widespread or desirable Barrett and Montgomery
> reductions are: if these reduction methods are unlikely to be actually
> used in the field, or offer only insignificant efficiency incentives for
> adoption, then we might not need to maintain them.

Montgomery reduction is a very common implementation choice for RSA
and DH implementations. Barrett may get used, but requires a big table
per prime. I doubt there are going to be attacks based on this
"special" property.

>
> Another argument here is that if efficiency is paramount, most people
> will choose ECDHE instead of FFDHE.  So if we're proposing FFDHE groups
> as a bulwark against some future failure of ECDHE, we might as well
> accept that performance efficiency isn't the highest priority.
>
>
>
> These last two points are what Andrei is referring to when he says
> "avoid special-form primes", fwiw.
>
>
> Thoughts, feedback?
>
>           --dkg
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin