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:	Tue, 23 Sep 2014 19:22:06 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	George Spelvin <linux@...izon.com>
Cc:	adilger@...ger.ca, linux-ext4@...r.kernel.org
Subject: Re: [RFC] mke2fs -E hash_alg=siphash: any interest?

On Tue, Sep 23, 2014 at 07:00:23PM -0400, George Spelvin wrote:
> It's worse than that.  The dcache has an great hit rate, and you have to
> force misses.  But if you actually hit the disk a lot, that will dwarf
> hashing performance into unmeasurability.
> 
> So it requires a very cleverly designed benchmark to highlight it.

Well, yes.  That's why I suggested doing something with a RAM disk.
Perhaps creating a huge number of zero length files, then unmounting
the the file system and remounting it, and then deleting the huge
number of zero length files.

If that doesn't show an improvement, then it's unlikely any real world
use case would likely show an improvement.... 

> By criterion 2, SipHash *is* significantly stronger: it's presented at
> crypto conferences, been studied, and is widely used.
> 
> halfmd4 a very ad-hoc primitive that I don't think anyone's looked at
> seriously.
> 
> It's not obviously terrible, and it's possible that halfmd4 is more work
> to break, but we won't know until someone with cryptanalytic skill takes
> a swing at it.

The other thing to consider is what you get if you manage to crack the
crypto, which is that you might be able to force the worst case
performance, and possibly cause a directory creation to fail with an
ENOENT if the huge number of hash collisions cause the two-level htree
to overfill.

Neither is going to get you a huge amount, so it this decreases the
incentive for someone to spend a lot of effort trying to attack the
system.  I'm quite certain though that if there is some way such a
failure could cause an Iranian nuclear centrifuge to fail
catastrophically, our friends at Fort Meade would have absolutely no
problems finding an attack.  After all, they did for MD5.  :-)

Cheers,

					- Ted
--
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