Timeline for How to stop an attacker from repeating the same ciphertext?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 9, 2017 at 19:22 | comment | added | poncho | @Chi: absolutely; the only thing you really need is that the value never (well, hardly ever) repeats. You could even use a sequence number (and use the hardware rng to initialize it at bootup), if you wanted... | |
| Sep 9, 2017 at 19:20 | comment | added | Chi | Time to transmit is not an issue, but the time required to generate a truly random number that big can be quite high, seconds even. Would it be feasible to generate a pseudo-random number from the messages being received without compromising security? | |
| Sep 9, 2017 at 18:58 | comment | added | poncho | @Chi: yes, that's why the value needs to be long enough that, effectively speaking, it never repeats (cryptography term: it's a nonce). You said that the device has a hw random number generator; if you make the value 32 bytes of randomness, that'd make darn sure that the attacker will never see a repeat. That might be a bit of overkill; however, unless the time to transmit the value is an issue, I'd suggest you go with overkill here... | |
| Sep 9, 2017 at 18:53 | comment | added | Chi | Thank you for the effort you put into answering my newbie question. For the antireplay challenge/response protocol, what happens if an attacker can somehow manipulate the value that the device generates (say, by modifying the device)? Wouldn't the PC generate an encrypted text that an attacker can just replay anytime the device sends that specific number? | |
| Sep 9, 2017 at 18:39 | vote | accept | Chi | ||
| Sep 9, 2017 at 13:08 | history | edited | e-sushi | CC BY-SA 3.0 |
added 3 characters in body
|
| Sep 9, 2017 at 12:48 | history | answered | poncho | CC BY-SA 3.0 |