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: <5340A46E.8070201@dei.uc.pt>
Date: Sun, 06 Apr 2014 01:48:46 +0100
From: Samuel Neves <sneves@....uc.pt>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Quick gripe... in case there's ever another contest

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 personally don't like Java, but it does seem to be a reasonable middle-ground in this context.
Perhaps in the future Rust could be a good language for submissions, since it is both a systems
language and seems to have few undefined behavior traps.

[1] http://corp.galois.com/cryptol/