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]

Message-ID: <20140406005732.GD19305@openwall.com>
Date: Sun, 6 Apr 2014 04:57:32 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Quick gripe... in case there's ever another contest

On Sat, Apr 05, 2014 at 08:35:36PM -0400, Bill Cox wrote:
> 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.

Thomas suggests Java for reference implementation, not for "main"
implementation if by "main" we mean something people would actually use
(when finalized).

The reference implementation would be somewhere half way between
pseudo-code in the specification and optimized code for actual use.
It'd be like machine-readable pseudo-code (happening to be Java).

AESENC would have to be a pseudo-code (Java) function, with a comment
saying that in native implementations on capable CPUs it'd be just one
instruction.

I think this makes some sense, although it would have made it harder for
me to participate and to propose something as complicated as yescrypt
(many of us would view that as a good thing, but I think the complexity
is, unfortunately, justified).  Luckily, I don't have to code any Java
for PHC. ;-)  For a next competition, maybe we can find a language that
is more suitable for unoptimized reference implementation than both
C/C++ and Java.  Unfortunately, we also have to consider the language's
popularity.

Other than the above, I'm also with phk.

Alexander