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] [day] [month] [year] [list]
Date: Sat, 5 Apr 2014 21:10:10 -0400
From: Bill Cox <>
Subject: Re: [PHC] Quick gripe... in case there's ever another contest

On Sat, Apr 5, 2014 at 8:48 PM, Samuel Neves <> wrote:
> On 06-04-2014 01:35, Bill Cox wrote:
>> On Sat, Apr 5, 2014 at 6:47 PM, Solar Designer <> 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:
>>> 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...
> Thomas was talking of *reference* implementations. A reference implementation is useful to
>  determine *what* the function computes, not *how* it is computed. In that sense, the less
> undefined behavior the language has, the better. There is a case to be made on using formal
> specification languages like Cryptol [1], but 1) very few people are familiar with them and 2)
> this would actively discourage submissions.

I agree that the reference implementation should be clear, concise,
and portable, and C hurts this.  Having one in a language like Java
(or better) and one in C would be best.  However, I've been through
the code of all 24 submissions, and only a few had alternate
implementations, and several seem hard pressed to deliver a polished C
implementation.  I'm fighting with compiling them now, and it's pretty
shocking to me how much more optimization could/should have been done.
 If a second compatible implementation were required, I suspect half
of the submissions would have gone away.  Maybe there would be some
good in that, but I'm finding all kinds of good ideas in these
unpolished implementations.  It would be a crime to raise the bar so
high that they never get submitted, IMO.


Powered by blists - more mailing lists