phc-discussions - Re: [PHC] omegacrypt and timing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+hr98Gkkgf9SF-VP=oAoR6XKzVwDTZOwRE_K662pg_xJbmPBQ@mail.gmail.com>
Date: Thu, 18 Sep 2014 13:40:09 +0200
From: Krisztián Pintér <pinterkr@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] omegacrypt and timing

On Thu, Sep 18, 2014 at 12:20 PM, epixoip <epixoip@...dshell.nl> wrote:
> The theoretical attack you first outlined identifies a possible
> early-reject for an offline attack.

this is the exact opposite of my attack. i explicitly said that
attacker has *no* access to the hash, only timing information. and
solely on timing, he can infer some information about the hash.
depending on what kind of information he can get, it can be enough to
narrow down the search to a few passwords. my explanation why is that
important even in the partial information case is that it can allow
attacker to exclude some passwords from a possible set. note again
that it is all without having access to the hash or any data
whatsoever. it is based solely on timing.

the second attack is in fact not a second attack, just a second
example of the same attack. i'm just trying to explain that we can't
dismiss this sort of attack due to its unrealistic nature. it is quite
realistic. not in every situation, but it does not take much effort to
come up with situations. you can say this is a risk we should take.
but you can't call it negligible let alone nonexistent.

i'd rather deliver an algorithm that does not have such caveats. note
on caveats: i also don't like the notion that caveats are OK,
sysadmins and library authors will be careful. simplicity is desired,
and such caveats tend to increase complexity by orders of magnitude.
instead of just using an algorithm, now you need to evaluate whether
your situation matches any undesired pattern, plus you need to
reevaluate every time you introduce changes to your system. not having
an issue is immensely more beneficial than controlling an issue.