phc-discussions - Re: [PHC] Endian Issue in Catfish

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: <CAN5JNV2b-fY26mOULBL+uPy4LEB_woBdmGkn-SwCg==6SqUhGg@mail.gmail.com>
Date: Wed, 2 Apr 2014 14:04:43 -0400
From: Bo Zhu <bo.zhu@...terloo.ca>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Endian Issue in Catfish

To further ease your confusions, I found the change log I first made for
the little/big endian conversion at
https://github.com/ComSec/Catfish/commit/c5e284dcdc8500393b579646527b10929756f8c9#diff-f2b9235a3749e49795a0036f1b91e85d

Hope this's helpful :)

Thanks again for your interests in our design!

Best,
Bo


On Wed, Apr 2, 2014 at 1:47 PM, Bo Zhu <bo.zhu@...terloo.ca> wrote:

> 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