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: Wed, 2 Apr 2014 13:47:37 -0400
From: Bo Zhu <bo.zhu@...terloo.ca>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Endian Issue in Catfish

As I already mentioned, phhash() was modified from one old piece of code.
It was using big endian internally, but I modified the code to invert the
input/output arrays, so it is now little-endian.
So there is no bug in it.

Especially we have three different versions of the code implemented in C,
CPP and Python, their output has been cross-verified.

--Bo


On Wed, Apr 2, 2014 at 1:41 PM, Steve Thomas <steve@...tu.com> wrote:

>   OK then there is a bug in the reference code because it is being read
> as big endian.
>
> On April 2, 2014 at 12:36 PM Bo Zhu <bo.zhu@...terloo.ca> wrote:
>
>  Sorry if I am making you more confused.
>
>  By " chose little endian to be compatible with Keccak", I meant we are
> trying to use the same bit and byte ordering conventions as Keccak's, in
> order to avoid possible confusions when someone wants to implement both
> Keccak and Catfish by himself/herself.
>  But it should not matter if you treat Keccak as a black box and just
> link some Keccak libs.
>
>  If you are interested, you can read more info about Keccak's bit/byte
> ordering in its specs at
> http://keccak.noekeon.org/Keccak-implementation-3.2.pdf.   (Sec 1.2, Page
> 9).
>
>  Thanks.
>
>  --Bo
>
>
>
>
>  On Wed, Apr 2, 2014 at 1:24 PM, Steve Thomas <steve@...tu.com> wrote:
>
>
> On April 2, 2014 at 12:13 PM Bo Zhu < bo.zhu@...terloo.ca> wrote:
>
>  Hi Steve,
>
> Thanks for your interest in our design and especially the source code.
>
> The pkhash_slow() was modified from one piece of old code, and it was
> using big endian.
> I was in a hurry to complete the C ref code to be submitted to the
> competition.
> That's the reason why it seems a little weird.
>
> We chose little endian to be compatible with Keccak and other minor
> issues.
> It is perfectly fine if you can implement the pkhash in little endian.
>
> Best,
> Bo
>
>
>  On Wed, Apr 2, 2014 at 1:06 PM, Steve Thomas <steve@...tu.com> wrote:
>
>   I think there is an issue with endian in Catfish. E verywhere in
> catfish() it is little
>  endian until it gets  passed into pkhash_slow() then it thinks it's big
> endian and
>  "in" is  "reverse for little-endian". Then is used as little endian.
> Although this
>  doesn't really matter since the input  is  from keccak. It just seems
> weird.
>
>    I guess I'm either confused or being confusing, are you suppose to
> read the output
>  of  keccak as little or big endian .
>
>
>
>
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ