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
| ||
|
Message-ID: <56F21DBA.3000300@dei.uc.pt> Date: Wed, 23 Mar 2016 04:38:18 +0000 From: Samuel Neves <sneves@....uc.pt> To: discussions@...sword-hashing.net Subject: Re: [PHC] hash encryption On 23/03/2016 03:41, Solar Designer wrote: > Hi, > > I am planning to release yescrypt 1.0 later this year. One planned > feature that stayed on my to-do list so far is builtin support for > (re-)encryption of hashes. > > One way to do it would be to use a block cipher like AES. However, > yescrypt does not normally use any block cipher, and bringing in an > extra crypto primitive just for this one feature is not great. > > Another way would be to reuse the salt as IV when reusing an already > available hash function as a stream cipher. However, this increases > reliance on salts being unique. > > Yet another way would be to create a block cipher out of a hash, using > the Luby-Rackoff construction. This is my current preference. > > Attached is an implementation of a 256-bit block cipher based on > SHA-256 (which yescrypt has anyway). I'd appreciate a review. Underlying the SHA-256 compression function there is already a block cipher, often known as SHACAL-2. It is used in Davies-Meyer mode (SHACAL-2(key, block) + block) to turn it into a compression function. Turning SHA-256 into a Feistel block cipher seems like overkill, but obviously works. Alternatively, sticking with primitives already in (ye)scrypt, one can reuse the underlying permutation of Salsa20 to turn it into an Even-Mansour block cipher---P(block xor key) xor key.
Powered by blists - more mailing lists