Timeline for Encryption that purposefully take hours to decrypt
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 20, 2020 at 20:06 | comment | added | Nat | Yeah, for many standard cryptographic hash functions, collisions wouldn't be expected to be too common. The problem can be avoided entirely by using an algorithm that is guaranteed to avoid collisions over the password space. | |
| Apr 20, 2020 at 19:40 | comment | added | 8n8 | @Nat Could (3) be dealt with by using a cryptographic hash function like SHA256? Wikipedia says "it is infeasible to find two different messages with the same hash value" in that case. | |
| Apr 20, 2020 at 18:35 | comment | added | Nat | This strategy has a few downsides: (1) It results in a pretty uniform distribution of times to decrypt, where a brute-forcer may get lucky and solve it far quicker than they'd intended with significant likelihood. For example, if they want 2-to-8 hours, and so tune it to take up-to 8-hours, then a brute-forcer has a 25% chance of getting it in less than 2-hours, which is significant. (2) This is highly parallelizable, e.g. allowing someone to cut the time in half by getting a second worker. (3) Hash-collisions may yield false solutions, which isn't a desired property here. | |
| Apr 20, 2020 at 15:04 | review | First posts | |||
| Apr 20, 2020 at 15:53 | |||||
| Apr 20, 2020 at 14:59 | history | answered | 8n8 | CC BY-SA 4.0 |