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]

Date: Sun, 6 Apr 2014 04:43:24 +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 Sun, Apr 06, 2014 at 04:12:49AM +0400, Evgeny Kapun wrote:
> 06.04.2014 02:47, Solar Designer wrote:
> > 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
> 
> It is important that cryptographic functions are defined to operate on
> bytes, not characters. Otherwise, the definition of such functions would
> depend on the definition of what a character is, and how they are
> represented, which could be as much as the entire Unicode standard.
> 
> When it comes to arithmetic operations on integers, results are defined
> unambiguously in Java, unlike in C. It is even possible to get
> unambiguous behavior of floating point operations (if someone seriously
> decided to use them in cryptography) by using strictfp modifier. The
> above mentioned bug was caused by incorrect representation of a Unicode
> string as bytes, which is not what a hash function should be about
> anyway.

Fair enough.

Alexander