Timeline for Random padding in hash functions
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2017 at 13:14 | history | edited | CommunityBot |
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
|
|
| Sep 22, 2015 at 20:03 | comment | added | Daniel H | Alternatively, I just realized that for a hash function outputting n bits, then using more than n bits of padding would be more than enough for even theoretical uncrackability because then a wide variety of plaintexts could all hash to the same value with different paddings. This should remain valid as long as preimage attacks are infeasible. | |
| Sep 22, 2015 at 19:58 | vote | accept | Daniel H | ||
| Jul 26, 2015 at 0:51 | answer | added | thexacre | timeline score: 0 | |
| Apr 7, 2015 at 13:51 | comment | added | Daniel H | Mostly I’m asking “Why 80 bits”, but I also want to know how much this number changes between hash functions, how much it’s expected to grow with time (1 bit per 18 months in accordance with Moore’s law? Faster?), etc. I’d also be interested in anything else relevant, like not using MD5 because you could fake two different predictions with different “random” padding using prefix collision attacks, or my analysis here being wrong and something similar to bcrypt still being necessary. | |
| Apr 7, 2015 at 11:29 | history | tweeted | twitter.com/#!/StackSecurity/status/585404139506634752 | ||
| Apr 7, 2015 at 8:08 | comment | added | StackzOfZtuff | So you're asking "Why 80 bits?"? Or is this about the general idea? | |
| Apr 7, 2015 at 3:47 | review | First posts | |||
| Apr 7, 2015 at 4:17 | |||||
| Apr 7, 2015 at 3:44 | history | asked | Daniel H | CC BY-SA 3.0 |