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: <20170316193210.GA21035@openwall.com> Date: Thu, 16 Mar 2017 20:32:10 +0100 From: Solar Designer <solar@...nwall.com> To: discussions@...sword-hashing.net Subject: [PHC] trivial delegation Hi, This is something many of us probably had in mind (I did), but I don't recall us discussing it. So here goes. I'll start with the counterpart of delegation: what Catena calls server relief. It's computation of almost-final hash on the client, with the hash function being defined such that the computation can be completed on the server without needing to transfer a lot of internal state from client to server (but rather just a tiny pre-final hash). Delegation of heavy computation by a client or a server to another server (e.g., Facebook backend node to Facebook frontend node, as Alec Muffett mentioned in his talk) can similarly be trivially accomplished by computing a fast pre-hash on the requesting system and finishing the computation on a delegation server (then having this hash sent back to the requesting system). Both things can readily be done on top of any existing password hashing scheme - in fact, this is why some of us (including me) were skeptical about Catena's server relief as a built-in feature. However, PHC being a competition I ended up adding an equivalent (and more: also usable in challenge/response) to yescrypt, and I am now thinking whether built-in trivial delegation support would also be worth it. In order to minimize the exposure of sensitive information to the server, the requesting system should include a secret in its pre-hash computation. It can be a global secret (per deployment) or it can be a second per-account salt. This is fine, but this extra data will then need to be stored somewhere, and the computation will need to precede our hashing scheme's computation each time, even if the delegation is not always used or is dismantled later. So we can't just say that this e.g. yescrypt standard hash encoding includes all of the inputs to this hash computation (sans the password and optional encryption key) and that the entire algorithm is specified by yescrypt - rather, there would be site-specific pre-hashing algorithms (we could recommend some "standard" for pre-hashing, but technically it'd remain separate). What I am thinking is that similarly to built-in server relief, we could instead structure the hashing scheme such that it'd include the separable pre-hashing as a standard step that is always done (whether there's delegation or not). Then delegation-computed hashes will not require extra storage for an extra secret key and/or secret salt. Specifically, it means that the main and only salt will also serve this purpose, and in a delegation setup will not be revealed to the server. The hashing scheme will then start by combining the password and salt inputs e.g. with HMAC, and then will never use the salt directly again. In a delegation setup, the requester will compute the HMAC on its end, send it and yescrypt parameters (but not the salt) to the server, and receive the hash value, which it will re-combine with the parameters and the salt to form a standard yescrypt hash encoding string for storage or comparison. For cost-upgraded hashes, this means that each upgrade should not require the original salt either, or else upgraded hashes would not be fully computable in a delegation setup like the above. As long as we use strong cryptography like HMAC-SHA256 at the beginning and end of each hash "body" computation (each upgrade step), this should be OK - we'll have entropy bypasses over the heavy computation (like SMix) via the HMAC-combined password and salt values (gradually HMAC-combined with the heavy computation intermediate results, as yescrypt already does, and overwritten). Here are my past concerns on pre-hashing, where I ended up using HMAC of the password along with a personalization string: http://lists.openwall.net/phc-discussions/2015/01/31/3 To better support trivial delegation as above, I am now thinking of revising this HMAC to use the salt instead of the personalization string (or along with it if there's a good reason, or to avoid the need for reasoning on why dropping the personalization would be safe). I think using the salt instead of the personalization string would be fine, and as a bonus could allow some existing frameworks/apps using HMAC-SHA256 to upgrade to yescrypt easier (without keeping custom code), although unfortunately most (maybe all?) of them appear to use key=password, message=salt, which we should not (should do it the other way around, because of HMAC's optional pre-hashing of the key). If anyone knows of examples of frameworks, web apps, or whatever that use HMAC-SHA256 with key=salt, message=password, please let me know. As I'm only aware of private uses of yescrypt for password hashing so far (plus two cryptocoins), which is no surprise given I never made an official release of it outside of PHC, I still feel empowered to make adjustments like this for the official 1.0 release, and it's OK, even though not ideal, that PHC's 0.8 is slightly different. (FWIW, the privately used 0.9.x is still compatible with PHC's 0.8.1 - it just has some extras in its reversible string encoding and optional encryption.) Seeing how even Argon2i was tweaked post-PHC is empowering, too. ;-) I'd appreciate any comments on any/all of the above. Thanks, Alexander
Powered by blists - more mailing lists