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

[Watson Ladd <[e-mail]>]

On Mon, Mar 16, 2015 at 7:58 AM, Rene Struik <[e-mail]> wrote:
> 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).

No, the protocol analysis is very simple. If you hash the transcript
with the shared secret, and use that as the key, you never have to
worry about contributory behavior. Even if an attacker dictates the
computed key, that key will never match one computed by an honest
participant. The problem is this needs to include all messages sent
before the key is established. Most protocols do this and don't
require contributory behavior.

This is a standard technique for simplifying security analysis. Of
course, we've always described what's required to ensure contributory
behavior in Curve25519, and it's always the case that implementors
should know what the protocol requires as far as assuring contributory
behavior, namely rejecting 8 inputs. TLS is really the odd man out in
requiring contributory behavior.

But let's assume that we need contributory behavior. Then simply
returning an ignorable error code doesn't work. Instead the function
should return 32 random bytes if computing 0, so as to avoid ignoring
the errors.

Sincerely,
Watson Ladd

>
> 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]
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>



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