Timeline for Is there something wrong with using a hash function as a PRG?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 28, 2019 at 19:15 | comment | added | Squeamish Ossifrage | @UTF-8 That's why I said SHA-256 specifically, and not ‘a collision-resistant hash function’ generally. (See crypto.stackexchange.com/a/70709 for a more nuanced discussion.) Use of the entire value space is actually part of what weakens the security of, e.g., AES-CTR in contrast to ‘SHA256-CTR’ and why safe data volume limits are something you actually have to worry about for AES-CTR, unlike SHA256-CTR. | |
| Aug 28, 2019 at 19:08 | comment | added | UTF-8 | @SqueamishOssifrage I can see that a random oracle would be better than an ideal cipher. But real hash functions might only produce multiples of 7 w/o violating the criteria of collision-resistant hash functions, or they might have other characteristics. Furthermore, ciphers are guaranteed to use the entire value space. | |
| Aug 28, 2019 at 14:41 | comment | added | Squeamish Ossifrage | Actually you'll get better security with essentially no limits on the volume of data you can process if you use SHA-256, and less complexity of code to hash structured inputs like your purpose and usage index (as long as the inputs are uniquely encoded and prefix-free), and you won't invite the standard timing side channel attacks that AES invites. The performance may not be as good but that's probably not going to be your bottleneck here. | |
| Aug 28, 2019 at 11:53 | comment | added | UTF-8 | This seems like a better idea than using a hash function. Thank you! | |
| Aug 28, 2019 at 11:52 | vote | accept | UTF-8 | ||
| Aug 28, 2019 at 21:39 | |||||
| Aug 28, 2019 at 6:04 | history | answered | Mark Schultz-Wu♦ | CC BY-SA 4.0 |