| 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: <20140228155728.GA17032@openwall.com> Date: Fri, 28 Feb 2014 19:57:28 +0400 From: Solar Designer <solar@...nwall.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] Overwriting early hashing memory On Fri, Feb 28, 2014 at 10:16:14AM -0500, Bill Cox wrote: > This is a super-simple upgrade to my algorithm, and I think I'm going > to do this. I just don't know how much overwriting initial memory is > worth. Is it worth running 50% longer, or only 3% longer? I think it depends on use case. You shouldn't universally say that leaking memory contents is the primary threat; for many (most?) use cases and threat models, it is not. When I added runtime self-test and zeroization to crypt_blowfish, I measured its cost at 0.6% at the $2a$08 bcrypt cost setting. I think this is a good tradeoff. 3% might be (barely) acceptable too. 50% definitely not, although it could be OK as a non-default option (but then having that option might not be worth the complexity). Alexander
Powered by blists - more mailing lists