phc-discussions - Re: [PHC] Quick gripe... in case there's ever another contest

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]

Date: Sat, 5 Apr 2014 20:35:36 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Quick gripe... in case there's ever another contest

On Sat, Apr 5, 2014 at 6:47 PM, Solar Designer <solar@...nwall.com> wrote:
> This is not without merit, but which approach is best is unclear to me.
>
> As you pointed out, there may be language-related bugs in Java code too,
> and here's a relevant example:
>
> http://mindrot.org/files/jBCrypt/internat.adv
>
> Alexander

This probably just shows my age, but I agree more with Poul-Henning
Kamp in this case.  Password hashing may get implemented in PHP or
Javascript, but the main implementation will be in C/C++.

The thought that we could develop the next generation PHS in Java
gives me the heebie-jeebies (and I am a Java fan).  How exactly are we
supposed to take into account SSE/AVX2, or AESENC instructions in
Java?  Imagine an EARWORM implementation in Python, Javascript, or
PHP.  Ug...

You can't do a good job at this with pencil and paper.  You have to
roll up your sleeves, write some code, benchmark, and iterate.
Otherwise, you'll only have a nice academic paper to show for your
work.  A nice high level language implementation would be a bonus, but
I just can't see tuning a PHS without going bare metal.

Bill