Timeline for Why expand keys? Why not rather generate a longer key?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 18, 2022 at 12:46 | vote | accept | Chris Morgan | ||
| Jun 17, 2022 at 6:00 | history | tweeted | twitter.com/StackCrypto/status/1537676414903898112 | ||
| Jun 17, 2022 at 3:20 | vote | accept | Chris Morgan | ||
| Jun 17, 2022 at 7:42 | |||||
| Jun 17, 2022 at 0:49 | history | became hot network question | |||
| Jun 16, 2022 at 23:30 | answer | added | forest | timeline score: 18 | |
| Jun 16, 2022 at 17:15 | comment | added | kelalaka | ( more memory, more time, more electricity) = more money. More DHKE round, that is again more time and calculation. Intel will hate it on AES-NI. Also, see What are the requirements of a key schedule? | |
| Jun 16, 2022 at 17:11 | comment | added | Chris Morgan | @kelalaka: hmm, I wasn’t thinking about those cases, but assuming fully random keys generated ahead of time in controlled environments (since that’s the situation I’m dealing with and I haven’t had to deal with situations like you describe); in that situation, generating and storing more randomness isn’t an issue. As for key exchange, doesn’t seem to me like that’d be a problem—you could split the key up into chunks. | |
| Jun 16, 2022 at 17:09 | comment | added | poncho | In addition, hardware AES implementations hate long keys, and would prefer expanding keys as needed (potentially on the fly) | |
| Jun 16, 2022 at 16:52 | comment | added | kelalaka | This means you have to generate more random, store, and transfer it. You need very long passwords for a password-based key generation or ridiculously increased DHKE modulus sizes. | |
| Jun 16, 2022 at 16:46 | history | asked | Chris Morgan | CC BY-SA 4.0 |