netdev - Re: tc: u32: Wrong sample hash calculation

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:   Fri, 22 Jan 2021 13:24:29 +0100
From:   Phil Sutter <phil@....cc>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org, Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Russell Stuart <russell-lartc@...art.id.au>
Subject: Re: tc: u32: Wrong sample hash calculation

Hi Jamal,

On Fri, Jan 22, 2021 at 06:25:22AM -0500, Jamal Hadi Salim wrote:
[...]
> Is this always true though for all scenarios of key > 8b?

Key size reduction algorithms simply differ, and before applying the
divisor the key is reduced to an eight bit value. If the higher bytes
are zero, the result is identical. So for some keys the differences are
irrelevant.

> And is there a pattern that can be deduced?

Something like: 'broken = !!(key >> 8)'? ;)

> My gut feel is user space is the right/easier spot to fix this
> as long as it doesnt break the working setup of 8b.

My motivation to write the initial email was that I don't like the
kernel's key folding as it's basically just cutting off the extra bits.
I am aware that fixing user space is easier, but better distribution of
entries might be worth the extra effort. Given that you didn't point out
any implications with changing u32's key folding in kernel space, I'll
just give it a try.

Thanks, Phil