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]

Date:	21 Sep 2014 17:04:16 -0400
From:	linux@...izon.com
To:	linux@...izon.com, tytso@....edu
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [RFC] mke2fs -E hash_alg=siphash: any interest?

> 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