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: <20160323172126.GC6565@openwall.com> Date: Wed, 23 Mar 2016 20:21:26 +0300 From: Solar Designer <solar@...nwall.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] hash encryption On Wed, Mar 23, 2016 at 07:54:56AM +0000, Jean-Philippe Aumasson wrote: > What are your requirements wrt key size, 128-bit or larger > block size, 256-bit > mode, N/A since it's just one block. Or we can say it's ECB. > speed? The faster, the better. It should be reasonable, but doesn't have to be fast. What I posted should be fine performance-wise: it's 4 or 7 SHA-256's, whereas many more are computed to expand yescrypt's inputs into B and to compress the final B into yescrypt's output, given a typical r=8 or so. > With all the crypto in yescrypt, we'll probably find a decent scheme based > on existing code :-) Sure, and thanks, but my choice of building upon SHA-256 is also motivated by these considerations: Being able to (continue to) say that yescrypt's basic cryptographic security relies solely on NIST-approved crypto (and on well-studied constructions around such crypto primitives), including for this optional feature. The other option would have been to bring in AES, but I don't like that. Allowing for yescrypt implementations to use third-party implementations of SHA-256, such as provided by a library or by a programming language. This rules out building upon SHA-256 internals as opposed to upon SHA-256 as a whole. Makes sense? Alexander
Powered by blists - more mailing lists