linux-kernel - Re: Where exactly will arch_fast

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1417959696.17658.37.camel@localhost>
Date:	Sun, 07 Dec 2014 14:41:36 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	George Spelvin <linux@...izon.com>
Cc:	dborkman@...hat.com, herbert@...dor.apana.org.au,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org, tgraf@...g.ch
Subject: Re: Where exactly will arch_fast_hash be used

On So, 2014-12-07 at 08:30 -0500, George Spelvin wrote:
> Thanks for the encouragement!
> 
> > Please consider xfs, too.
> > AFAIK xfs doesn't seed their hashing so far and the hashing function is
> > pretty weak. One example:
> > http://marc.info/?l=linux-xfs&m=139590613002926&w=2
> 
> Is that something that *can* be changed without breaking the
> disk format?  SipHash is explicitly *not* designed to be secure as
> an unkeyed hash in the way that SHA-type algorithms are.

I did some research and it looked like it would need a change to the
disk format but it should be doable by incrementing the super block
version, so at least newly created filesystem would benefit from it.

> What it's designed to do is provide second preimage resistance
> of its output, or a function (like modular reduction) of its output,
> against an attacker who doesn't know the secret seed.
> 
> > Ack. If we want to use it in the networking stack we should be able to
> > use it without a dependency to the crypto framework.
> 
> Already understood.  My big question is whether a single function call
> is okay or we need something inlinable.

Like md5_transfrom, I think a non-inline function would be just fine.
Otherwise kernel code size would increase. Most hash users in the
network stack mostly deal with less bytes of input than one round needs.

Bye,
Hannes


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/