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  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: Sun, 6 Apr 2014 04:57:32 +0400
From: Solar Designer <>
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

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

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


Powered by blists - more mailing lists