phc-discussions - Re: [PHC] Design Rationale and Security Analysis of PHC candidates

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: <CA+hr98HWAX_6hXOmr-PsVue3CLm7B7hGLhf36w=CdM2MeJGCVg@mail.gmail.com>
Date: Thu, 2 Oct 2014 14:42:33 +0200
From: Krisztián Pintér <pinterkr@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Design Rationale and Security Analysis of PHC candidates

On Thu, Oct 2, 2014 at 1:56 PM, Dmitry Khovratovich
<khovratovich@...il.com> wrote:

> Assuming random ROM (this is important, collisions are easy if ROM can be
> partially chosen)

i claim that the content of ROM is irrelevant. you can not generate
collisions with it, since it can only affect the "rate" part of the
sponge, and not the "capacity". to my understanding, even if you are
in complete control of all the sponge input, you still can not find
collisions (let alone preimages).

this is a primary design principle of mine. i aim to entirely reuse
the security claims of keccak.