lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  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]
Date: Thu, 24 Mar 2016 22:46:07 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] hash encryption

On Thu, Mar 24, 2016 at 10:05:15AM -0700, Andy Lutomirski wrote:
> As a totally different option, you could hash the key and then plug
> the key's hash into the round function hash.

Yes, with some caveats:

1. The hash of the key would need to be personalized, so that if a key
is reused e.g. as a website password elsewhere, its SHA-256 hash can't
be used (without cracking it first) to decrypt yescrypt hashes.

2. This pre-hashing should be done for all keys or for keylen >= 32.
Not doing it for length 32 would allow for trivial construction of pairs
of different yet equivalent keys.

I am considering side-stepping the issue: instead of arbitrary {key,
keylen}, accept only an exactly 32-byte key.  If an application wants to
use a human-friendly string, it will need to derive the key first, such
as with another invocation of yescrypt, which is what would have been
recommended anyway.  This should work great for network services
implemented as persistent processes, but maybe not so great for typical
web apps in PHP, where it might hamper adoption of this feature (will
need either persistent storage of the derived key or repeated key
derivation in each new process).  So I am still undecided.

Alexander

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ