phc-discussions - Re: [PHC] hash encryption

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: Thu, 24 Mar 2016 15:19:02 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] hash encryption

On Thu, Mar 24, 2016 at 02:57:48PM +0300, Solar Designer wrote:
> On Thu, Mar 24, 2016 at 02:27:01PM +0300, Solar Designer wrote:
> > Don't hash the key length, but instead hash in the round number after
> > rather than before the key.  Since the round number is different for
> > each round whereas the key is fixed across all rounds, the round numbers
> > used for k1 can't (except for any one of them) be part of the longer k2.
> 
> Thinking of it some more, the exception may actually be important, still
> allowing to attack the last 1 or 2 rounds.

Or not, since the computation in the previous rounds would be different.

> So my proposed change isn't
> as complete a mitigation as hashing in the key length would be.

Or maybe it is.

However, the very fact that this needs more thinking suggests it isn't
as good, except in terms of code simplicity.

So it may be a case of reasoning simplicity vs. code simplicity.

Alexander