| 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
| ||
|
Date: Sun, 06 Apr 2014 04:12:49 +0400 From: Evgeny Kapun <abacabadabacaba@...il.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] Quick gripe... in case there's ever another contest 06.04.2014 02:47, Solar Designer wrote: >> (In fact, my opinion is that a _reference_ implementation, meant to test >> other implementations for correctness, should be done in a language >> which does NOT have undefined or architecture-dependent behaviour. C >> should be banned for that; reference implementations should be in Java >> or C#, or ideally something even stricter because even Java or C# may >> offer non-portable behaviour when using floating-point types.) > > 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 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.
Powered by blists - more mailing lists