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
| ||
|
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.
Powered by blists - more mailing lists