[curves] Curves Digest, Vol 5, Issue 1

[Samuel Neves]

On 02-02-2014 01:01, Watson Ladd wrote:
> On Sat, Feb 1, 2014 at 4:55 PM, Samuel Neves <sneves at dei.uc.pt> wrote:
>> On 31-01-2014 09:59, Paulo S. L. M. Barreto wrote:
>>> On Thu, 30 Jan 2014 22:45:03 -0800 Robert Ransom wrote:
>>>
>>>> A true drop-in replacement for one of the NSA curves would be a
>>>> small-parameter Edwards curve over the same field, satisfying the
>>>> ?SafeCurves? criteria, with a=1 and non-square d, such that:
>>> This is impossible per se. Most NIST fields simply do not satisfy the
>>> SafeCurves criteria (this is pointed out in Mike Hamburg et al's Elligator
>>> paper wrt P-256).
>>>
>> Another wrinkle here is that the NIST curves have prime order, which
>> makes them naturally immune to small subgroup attacks (assuming
>> implementations are verifying points are on the curve). Replacing them
>> with cofactor >= 4 curves may have some unexpected results.
> Revelation of the low three bits. You need a smooth group order to do
> much damage: a large
> prime factor is good enough.
>

Not every protocol is plain Diffie-Hellman, nor is key recovery the only
possible attacker goal. For example, SPEKE and some variants of DH-EKE
allow an active attacker to confine one of the Diffie-Hellman values to
a small subgroup, thereby getting a good chance at controlling the
shared key. An implementation that was previously using a NIST curve
could see itself vulnerable by changing to a drop-in replacement that
did not preserve the cofactor.