[Cfrg] (flaws with Curve25519 DH function, if one does not check the output) Re: Elliptic Curves - curve form and coordinate systems

[Rene Struik <[e-mail]>]

Hi Viktor:

The key words in your email are "depending on", which does suggest that 
protocol analysis may become quite unwieldy and error-prone itself.

For some examples of authenticated key agreement schemes that are 
supposedly secure against, e.g., the unknown key share attack, but where 
this does not seem to hold any more if the DH key is publicly 
computable, see, e.g.,

    Alfred Menezes, Simon Blake-Wilson,
    Unknown Key Share Attacks Against the Station-to-Station (STS)
    Protocol,
    PKC 1999.

This suggests that what you seem to dismiss as an "attack", may indeed 
be one (i.e., one without your quotation marks).

Rene

On 3/16/2015 9:56 AM, Viktor Dukhovni wrote:
> On Mon, Mar 16, 2015 at 09:08:11AM -0400, Rene Struik wrote:
>
>> You are correct: I have no idea where Dan Bernstein got that from. I *did*
>> comment on the DH function, which, with Montgomery-style specification as
>> in the "Curve25519" draft, is completely insecure, if one does not check
>> the output to be nonzero. This is a form of the small subgroup attack and
>> has been known for over 15 years.
> But in this case the "attack" does not leak any secret key bits
> from either party.  So depending on the higher level protocol there
> may not be any issues, provided such an agreement between M and B
> does not enable M to impersonate B in a communication between A
> and B.
>
> I gather then that this is the issue, and that such higher level
> protocols should reject the zero public key (or avoid the problem
> by ensuring that predictable ECDH output cannot lead to MiTM issues
> on other traffic).
>


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]