Date: Thu, 18 Sep 2014 03:20:16 -0700
From: epixoip <epixoip@...dshell.nl>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] omegacrypt and timing

On 9/17/2014 11:42 PM, Krisztián Pintér wrote:
> epixoip (at Thursday, September 18, 2014, 12:37:49 AM):
>> No
>> threats are excluded from the threat model, but the access vector,
>> complexity, probability, and impact are all a factor in determing
>> whether a threat actually poses significant risk.
> so your point is that the attack i have outlined earlier is
> insignificant? can you explain why?

The theoretical attack you first outlined identifies a possible
early-reject for an offline attack. If you know how long omegacrypt
takes to hash the correct password for the target user on the target
hardware, you can abort your offline cracking attempts early if they
take longer than that to run.

To support this attack, you would first need the hash+salt for the
target user and side channel access. Once you have that, you then need a
way of measuring the time it takes for omegacrypt to run when the target
user authenticates with a correct password.

The threat model starts with the attacker already knowing the hash+salt,
so you get that for free. However, as a passive attacker, you have no
real way of triggering an authentication attempt with the correct
password, so that's your first hurdle. Measuring omegacrypt's execution
time on the target system with enough granularity to show a variance for
the correct password vs. incorrect password is the second hurdle, which
may pose quite the challenge as an unprivileged user.

The last hurdle is actually using this information to gain some sort of
advantage. This means writing a cracker that is able to determine if the
execution time for each hashing operation has exceeded the target
runtime, and if so, reject the password candidate -- in less time than
it would take to just let the algorithm run to completion. This
early-reject check would not be applicable to every hashing operation,
as some will likely complete before the target runtime and the algorithm
will run to completion regardless. So you will only be gaining an
advantage (if you can even call it an advantage) 25-75% of the time, and
a 25% chance of no advantage at all, and that's only if you can find a
way to abort quicker than it takes to just let the algorithm run to
completion.

So access requires a shell on and/or physical access to the target
hardware, complexity is very high, probability is very low, and impact
is also very low / none. This translates into very low / no risk.

For the second attack you kind of outlined, you imagine a timing attack
where the attacker can infer the actual password itself without having
the hash or salt, but maybe some partial knowledge about the password. I
don't think this is even possible. Maybe if you had the salt it would be
possible, but would still be highly improbable.


> imagine a dedicated
> authentication server. it does nothing but receives a password via the
> local network, checks it out, and returns a validity flag. then takes
> the next password. the beginning and end of validation is clearly
> marked by the network activity. all i need to do is to do traffic
> analysis, possibly via EM detection, and i have timing information.
> how is that insignificant?

I suppose this is your explanation of how you would ascertain total
omegacrypt execution time. This seems entirely implausible, but even so,
my answer above still stands. I don't see any real advantage being
gained by this theoretical side channel.

Powered by blists - more mailing lists