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] [day] [month] [year] [list]

Date: Sat, 5 Apr 2014 21:10:10 -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 8:48 PM, Samuel Neves <sneves@....uc.pt> wrote:
> On 06-04-2014 01:35, Bill Cox wrote:
>> 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...
>
> 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.

Bill