Timeline for What's wrong with XOR encryption with hash and an iterated salt
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:48 | history | edited | CommunityBot |
replaced http://crypto.stackexchange.com/ with https://crypto.stackexchange.com/
|
|
| Jun 3, 2016 at 13:55 | comment | added | Ilmari Karonen | @sigsve: If $k + s$ means addition, then this would make the scheme vulnerable to related-key attacks: the keystreams generated by two different keys could overlap, if their numerical difference was small enough. Appending a nonce could indeed fix this, but only if the nonces were guaranteed to be globally unique, not just unique for each key. This should be OK if you were using long random nonces, but could be bad if you were e.g. using a sequential message number as the nonce. | |
| Jun 3, 2016 at 13:15 | vote | accept | SomeNorwegianGuy | ||
| Jun 3, 2016 at 12:23 | comment | added | SomeNorwegianGuy | By $k + s$ i meant addition actually, which I guess is potentially even more ambiguous. But $(k + s) . n$ where $.$ is concatenation would unambiguous, right? Assuming that $s$ would realistically be quite small ($<2^32$), and the nounce is huge in comparison(like 128 bytes). | |
| Jun 3, 2016 at 12:11 | comment | added | Ilmari Karonen | Ps. I'm assuming that the $+$ in ${\rm hash}(k + s)$ denotes string concatenation. If you mean something else by that (e.g. XOR), then some of the conclusions might change. In any case, the safest thing would still be to replace it with some completely unambiguous encoding. | |
| Jun 3, 2016 at 12:10 | history | answered | Ilmari Karonen | CC BY-SA 3.0 |