linux-ext4 - RE: [RFC] mke2fs -E hash_alg=siphash: any interest?

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: <BAY179-W560EC72EB98547138373E3FDB20@phx.gbl>
Date:	Sun, 21 Sep 2014 18:08:28 -0400
From:	TR Reardon <thomas_reardon@...mail.com>
To:	"linux@...izon.com" <linux@...izon.com>
CC:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: RE: [RFC] mke2fs -E hash_alg=siphash: any interest?

Is protection against hash DoS important for local on-disk format? I can't come up 
with a scenario, but maybe there is one.  The kinds of DoS contemplated are 
really Google-scale, not really at the scale of ext4 directories, imo.

I ask because if hash perf is the main goal here, then CityHash and particularly SpookyHash 
are better candidates. The latter has good performance even on legacy ARMv5 hardware. 

+Reardon


----------------------------------------
> Date: Sun, 21 Sep 2014 17:04:16 -0400
> From: linux@...izon.com
> To: linux@...izon.com; tytso@....edu
> Subject: Re: [RFC] mke2fs -E hash_alg=siphash: any interest?
> CC: linux-ext4@...r.kernel.org
>
>> I'm certainly not against adding a new hash function. The reality is
>> that it would be quite a while before we could turn it on by default,
>> because of the backwards compatibility concerns.
>
> Well, yes, obviously! My itch is just that I want to use it myself;
> I prefer it for security and cleanliness reasons. The benchmarks are
> mostly to prove that it isn't slower.
>
>> The question I would ask is whether we can show an anctual performance
>> improvement with the hash being used in situ.
>
> I quite agree, but I'll have to have a working patch before such
> a test can be made.
>
> One things I'm coming across immediately that I have to ask for
> design guidance on is the hash algorithm number assignment:
>
> - Should I leave room for more hashes with a signed/unsigned distinction,
> or should I assume that's a historical kludge that won't be perpetuated?
> SipHash is defined on a byte string, so there isn't really a signed
> version.
> - Should I use a new EXT2_HASH_SIPHASH_62 = 6, or should I
> renumber the (internal-only) EXT2_HASH_*_UNSIGNED values and use
> EXT2_HASH_SIPHASH_4_2 = 4?
>
> None of this is truly final, but it would make my life easier if I
> didn't have to change it on my test filesystems too often.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
 		 	   		  --
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html