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]
Message-ID: <218AE73F98E99C4C98AF7D5166AA798E0907E79A@TK5EX14MBXC287.redmond.corp.microsoft.com>
Date: Wed, 10 Apr 2013 02:26:45 +0000
From: Marsh Ray <maray@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] Random Hash Functions

> -----Original Message-----
> From: havoc [mailto:havoc@...use.ca]
> Sent: Tuesday, April 9, 2013 8:20 PM
> To: discussions@...sword-hashing.net
> Subject: [PHC] Random Hash Functions
> 
> By "random hash algorithm", I don't mean simply a random
> hash function which you could easily get by prefixing a random salt, I mean
> really generating random *code*.

What's the difference?

Not trying to be dismissive here. I'm wondering how one would go about describing how such a function is fundamentally different than a "static" hash function.

> Of course, generating a random *secure* cryptographic hash function is NOT
> easy, since it takes years of design and testing to become confident in just
> one.

But the function

     H = SHA-2-256(SHA-2-512("a") ++ msg1)

is a "randomly different" function than

     H' = SHA-2-256(SHA-2-512("b") ++ msg2)

right?

In other words, if knowledge of collisions or preimages of H help you to find collisions or preimages of H', then you have broken SHA-2-256 itself.

But maybe not in the sense that you mean.

What are some things that CPUs can do that plain old hardwired data-flow logic can't do as easily? Loops and conditional jumps come to mind. Randomly-chosen memory accesses like bcrypt and scrypt. But even CPUs are implemented with the same logic building blocks that are available in FPGAs.

> However, except for very valuable hashes, attackers probably won't
> spend a lot of time cryptanalyzing them, so it's OK for them to be not-so-
> secure.

Famous last words :-)

IMHO the idea of a randomly-generated function looks very appealing. But in theory and practice you'd end up paying a substantial price in complexity for a something that was basically impossible to show was helpful at all (if not harmful).

- Marsh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ