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: <541C9A93.3060509@rub.de>
Date: Fri, 19 Sep 2014 23:05:23 +0200
From: Markus Duermuth <markus.duermuth@....de>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] omegacrypt and timing

On 17.09.2014 19:12, Bill Cox wrote:
>> Adobe did this for encrypting PDFs 
>> (http://esec-lab.sogeti.com/post/The-undocumented-password-validation-algorithm-of-Adobe-Reader-X).
> 
> This is why we see these submissions.

Right, however, we (and apparently others as well) feel that Adobe did
not do it the right way.
* Three branches is not enough to seriously impact speed,
* I assume that some fraction of the three diverging branches can still
be executed in parallel, and
* The branches are quite long (an entire hash computation), so it may
pay off to re-arrange the guesses so you can always compute one hash
function per block.

> [...] 
> There are only maybe 30 different instructions that need to be
> executed, at least if the shift distance is computed rather than

This is precisely the reason why we tried to use "esoteric functions"
(i.e. floating point arithmetic) in our proposal,  as it increases the
number of available functions.  (It also requires relatively large space
on ASICS, and has certain drawbacks that have been discussed already...)

Cheers,
Markus