Re: [TLS] draft on new TLS key exchange

["Dan Harkins" <[e-mail]>]

On Thu, October 6, 2011 12:06 pm, Martin Rex wrote:
> Dan Harkins wrote:
>>
>> Marsh Ray wrote:
>> >
>> > Comment 4:
>> >
>> > The hunting and pecking loops for both the ECC and FFC password
>> elements
>> > look like a timing oracle to me. They seem to require a large
>> > exponentiation or sqrt on every iteration and the number of iterations
>> > is data-dependent. If I'm not mistaken, every input to the loop except
>> > the password itself is transmitted in cleartext during the handshake.
>> >
>> > Couldn't an attacker observe the timings of a sufficient number of
>> > failed handshakes to enable an offline brute force attack on the
>> > low-entropy password?
>
> I agree with Marsh, it is difficult to conceive how to implement
> this without being a timing oracle.
>
> The question is, how much does it help you.

  Indeed. And I think the answer is, not much.

> If you already have an account or could create one, then the timing
> would help you sort out unlikely passwords, I assume, because you
> know the algorithm and can determine "off-line" whether a computation
> for a newly guessed password is faster or slower than your own password
> and you can measure the servers response times for your password and
> for the unknown password and therefore know their relation.

  The relation-- yours is "faster" than the unknown one-- means nothing.
That knowledge doesn't help. Knowing how many iterations the hunting-
and-pecking loop went through to find PE for an unknown password might
but the relationship between two means nothing. In fact, since both
sides are contributing randomness into the hunting-and-pecking loop
yours might be "faster" one time and considerably slower the next time.
That knowledge doesn't really help.

  After the hunting-and-pecking loop there is a modular exponentiation
(or equivalent in EEC) using a random generator raised to a random
exponent. The timing variations in that calculation will be tremendous.

  The server won't respond until it has done both of these actions
so what the attacker sees is a sum of the time it took to perform both
actions. But the high variability in the time it takes to perform one of
those actions will interfere with the attacker's attempt to find out how
long the other action took.

  This is not a feasible attack.

>>   This is a very good point. I think the attacker would have to observe
>> successful handshakes though. It's the number of times through the loop
>> until the PE is determined that the attacker wants to know and a failed
>> guess will not provide any useful information.
>
> I don't find it very attractive if an authentication protocol gives
> an attacker a huge advantage at guessing an unknown account credential
> if he can create or obtain a valid account credential.

  I don't think it's attractive for an authentication protocol to give
an attack a huge advantage either. And this one doesn't.

> I also feel very uncomforable with the extremely vague term
> "low-entropy password" and the idea that this could be secure.
>
>
> "low-entropy" to me means something like a 4-digit numeric PIN,
> e.g. a complexity of 10^4 or 2^13.28
>
> The only means to retain a meaningful security margin against
> brute-force attacks is a very low lockout counter (e.g 2^4 or less).
>
> If the whole handshake takes 1 second to complete (or fail), then
> a brute force of the entire 2^13.28 entropy universe completes
> in less than 3 hours.  Without a lockout, there just is not any
> meaningful security possible.

  Yes, good point. At the bottom of section 6 I mention some
countermeasures to deal with repeated, failed, active attacks. I
should be more specific and mention what those countermeasures might
look like.

  thanks,

  Dan.