Colin,Thank you very much for the reply and for your efforts. >That assumption is incorrect. I understand scrypt blows others out of the water in terms of resources needed to for an attack with the currently known calculation algorithms. I don't have the cryptographical+mathematical knowledge, but I was under the impression that it hasn't been mathematically proven (while admittedly it would be extraordinarily difficult or downright impossible to) that either of pbkdf2 (say with hmac+sha-256), bcrypt or scrypt are not computable with as of yet undiscovered algorithms, faster than the current ones, hardware acceleration and physical processing advancements aside. Is there such a proof for scrypt, or a proof that such a discovery for scrypt would automatically apply to pbkdf and/or bcrypt as well? I guess there's also no proof that either of these isn't actually reversible, so each of them could (theoretically) have something against them discovered, that would make them useless, while not applying to the other two, isn't that correct? Again, I understand that mathematical proofs for irreversability/no-easier-computability might not even be within reach,and that just because there isn't one for either of them, it doesn't mean they are on equal footing, since their design can tell a lot, even without definitive proof, but just taking the worst case theoretical scenario, wouldn't it make sense to combine, for someone who's not that much bothered by adding an extra 20 seconds to the user-side computation time? Again, thank you for your time. From: Colin Percival <[email protected]> To: Maricel Gregoraschko <[email protected]>; "[email protected]" <[email protected]> Sent: Tuesday, March 24, 2015 3:13 PM Subject: Re: chaining multiple key derivation functions together On 03/23/15 20:04, Maricel Gregoraschko wrote: > I was looking at PBKDF2, bcrypt and scrypt as options for key derivation; and > would like to try using them all together in order to get the cryptographic > strength of the strongest one (which seems to be scrypt so far unless > something novel is discovered, but the assumption is that it is not known > which one is the strongest).
That assumption is incorrect. > [...] > So basically the 3 kdfs are applied in parallel, and the resulting keys are > concatenated and then hashed together. What do you guys think about this one? > Is this obviously superior to just applying the multiple kdf "in series"? Computing several KDF functions in parallel or in series and combining them makes no difference to an attacker; parallel may be more convenient for real users since it may produce results faster by using multiple CPUs. Either way is weaker than making a single scrypt call with larger parameters. > Also, I haven't looked at the sources of the scrypt utility yet, is it > straightforward to take the source files from there to use scrypt as a > function call from another program? Or is there a scrypt library specifically > for that? It's straightforward to extract the source code files you need. I think someone was working on libraryizing scrypt but I can't remember if it was ever finished; and for such a small amount of code I would just import the source code into your program anyway. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
