phc-discussions - Re: [PHC] pufferfish

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: <1187208444.20140406171514@gmail.com>
Date: Sun, 6 Apr 2014 17:15:14 +0200
From: Krisztián Pintér <pinterkr@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] pufferfish

Jeremi Gosney (at Sunday, April 6, 2014, 4:09:28 PM):
>> @@ -132,7 +132,7 @@ int PHS (void *out, size_t outlen, const void *in,
>> -        memmove (out, hash, strlen (hash));
>> +        memmove (out, hash, outlen);

> No, this is incorrect. The `hash' variable in this context is not the
> raw hash value, it is the encoded hash plus the hash identifier and
> encoded salt string.

it might need some clarification then, what the intended use of PHS
is. as i interpreted it, "out" should be raw bytes of length "outlen".
that poses the question though, what if a scheme does not even produce
anything that could be called "raw value" (e.g. it produces two
numbers in a prime field).

i would suggest to include a little memo for all candidates, what can
we expect from the output, is it random, is it a struct, etc. i added
that to Gambit, but i won't resubmit for this little change, it will
be there with the next significant update.