Timeline for Why improvising your own Hash function out of existing hash functions is so bad
Current License: CC BY-SA 3.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 8, 2022 at 15:51 | comment | added | mtraceur | I think the most compelling argument against combining/nesting these algorithms yourself, is that if it was a good idea, then the existing algorithms would have already done it, or new algorithms will soon, so just use the best well-established stuff that lots of cryptographers endorse. I don't worry if I should scrypt(Argon2id(...)), because I trust that whatever benefit scrypt provides, it is probably already included in Argon2, in a much more optimal way than a naive wrapping. | |
| Jan 9, 2019 at 7:20 | comment | added | forest | @SolomonUcko Then it becomes highly vulnerable to partial preimage attacks. | |
| Jan 6, 2019 at 14:30 | comment | added | Solomon Ucko | What if you just use the combined hash string? | |
| May 28, 2018 at 9:23 | comment | added | gaazkam | crypto.stackexchange.com/questions/59583/… | |
| Dec 29, 2017 at 5:52 | comment | added | forest | A bigger problem is that sha1(md5(m)) for any values of m decreases the possible outcomes to 128 bits, despite SHA-1 providing a 160 bit digest. While that's probably not a big deal because 128 is still plenty, you are unnecessarily reducing the digest size. Consider an extreme example, where you have sha1(crc8(m)). Despite a SHA-1 digest being 128 bits, there will only be 256 possible outcomes due to the 8 bit CRC in the middle. By creating a bottleneck, you are reducing security by limiting the keysize. | |
| Mar 15, 2017 at 15:28 | history | edited | CommunityBot | replaced http://meta.security.stackexchange.com/ with https://security.meta.stackexchange.com/ | |
| Sep 10, 2016 at 2:43 | comment | added | Pacerier | @Brilliand, Splitting the percentage of hash over different breeds of algorithm is actually an advantage because of economies of scale. An attacker that could mass produce bcrypt-optimized breakers might not at the same time be able to mass produce scrypt-optimized breakers. The same logic applies to all hashes of different breeds. | |
| Sep 10, 2016 at 2:39 | comment | added | Pacerier | @Ricky, ?? I don't think anyone understood what you are trying to say. | |
| Sep 10, 2016 at 2:30 | comment | added | Pacerier | @Polynomial, m^k^k is not a good analogy. What about m^k^k2? I don't see how that would be less secure. | |
| Apr 14, 2016 at 18:37 | comment | added | user49075 | @root : That will give them something such that scrypt(bcrypt(what_attacker_has)) = scrypt(bcrypt(real_password)) , but not necessarily such that bcrypt(what_attacker_has) = scrypt(real_password) . | |
| Apr 13, 2016 at 2:11 | comment | added | lepe | @Polynomial : I posted a simplified answer (kind of a summary). Not sure if my logic is correct, so if you have few minutes, could you check it / edit it please? I believe it can be useful. Thanks in advance! | |
| Oct 19, 2014 at 22:39 | comment | added | supercat | @Brilliand: Attackers will almost certainly find ways of speeding up both algorithms at least somewhat--probably by different amounts. If it turns out attackers find a 100:1 speedup for one algorithm and 2:1 for the other, the attackers would net about a 4:1 speedup against a system that used each algorithm for half as many rounds as could have used in the absence of the other. Unless one knows which system attackers would have "better luck" with, hedging bets hardly seems unreasonable. | |
| Aug 18, 2014 at 22:16 | comment | added | Brilliand | Using scrypt and bcrypt together has the problem that they both take time to run - you'll probably wind up halving the number of rounds on each to compensate for having to run both, which is more likely to be insecure than a "full" scrypt on top of a "full" bcrypt is. | |
| Apr 2, 2013 at 14:59 | comment | added | Polynomial | The primary issue is that you have to introduce more code to parse the encoded output of scrypt / bcrypt so that the salt and round count can be stored separately. Plus it doesn't really offer any increased security - scrypt is more than enough for 99.9% of situations. | |
| Apr 2, 2013 at 14:58 | history | edited | Polynomial | CC BY-SA 3.0 | dave link |
| Apr 2, 2013 at 9:46 | comment | added | root | I still don't see why the scrypt(bcrypt(x)) thing could be a problem. If the two interact weirdly, just using bcrypt doesn't make it more secure- an attacker can simply scrypt() what you've bcrypt()'d. Additionally, if someone figures out a more intelligent way to guess the original plaintext for one hashing algorithm, they probably won't simultaneously have a faster way for the other algorithm. Say people legitimately thought ROT13 was a good hashing mechanism. If I used ROT13(bcrypt(x)), wouldn't I still be better off when people 'cracked' ROT13? | |
| Apr 1, 2013 at 20:24 | comment | added | Polynomial | @thejh It was an example of how ignorance of the internals of an operation can lead to security vulnerabilities. It was not meant to be a direct analogy, hence why I said "Obviously it's more complicated in the case of KDFs, but the same principle applies." | |
| Apr 1, 2013 at 20:20 | comment | added | thejh | "Another potential issue with combining bcrypt and scrypt like this is that there has been very little study into how the two interact. As such, we don't know if there are any weird cases that can cause problems. As a more obvious example, take the one time pad. We compute c=m^k for some message m and some equally long perfectly random key k, and we get perfect security. So let's do it twice, for even more security!" You're doing it wrong. The bcrypt(scrypt(x)) stuff is ok while xor(xor(x,k),k) isn't because an extra bcrypt is something an attacker could do, too. | |
| Apr 1, 2013 at 15:26 | comment | added | Polynomial | @Phil Done. Hopefully it makes sense. | |
| Apr 1, 2013 at 15:26 | history | edited | Polynomial | CC BY-SA 3.0 | Added a paragraph about combining KDFs. |
| Apr 1, 2013 at 14:02 | comment | added | Phil | @Polynomial +1 Great answer. However I wasn't convinced about the bcrypt/scrypt part of your answer until I read your comment about one-time pads. Might consider adding that comment to your answer. | |
| Apr 1, 2013 at 13:10 | comment | added | Polynomial | My point is that since we don't know what potential problems might exist, why not go with the known safe route and just use scrypt with a decent work factor? It's more than secure enough for almost every purpose. | |
| Apr 1, 2013 at 13:09 | comment | added | Polynomial | The interaction between the two is undefined, because nobody has studied it. Combining the two might provide more security, but it also might lead to unusual interactions between the internals of those hashes. A good example of this is the one time pad. Computing c=m^k gives you a perfect level of security when k is truly random and unknown to the attacker. So let's do it twice, for more security! So we end up with c=m^k^k, which results in m. Oh, whoops. Obviously the interactions are more complex in hashes, but the principle still stands. | |
| Apr 1, 2013 at 12:16 | history | edited | Polynomial | CC BY-SA 3.0 | added 7 characters in body |
| Apr 1, 2013 at 12:16 | vote | accept | George Powell | ||
| Apr 18, 2016 at 11:48 | |||||
| Apr 1, 2013 at 12:10 | comment | added | George Powell | Nice answer. I'd not really thought about the first and the last example of stacked hash. They kinda ruined my argument a little for no reason. I was more interested in the bcrypt - scrypt hash and whether that could possibly be weaker than either scrypt/bcrypt on their own. | |
| Apr 1, 2013 at 11:32 | history | answered | Polynomial | CC BY-SA 3.0 |