Repository navigation
Compare secret strings in constant time #9
Description
Activity
I'm a little late replying to any of these issues, but:
- will be application-dependent, depending on whether the secret is supposed to be recovered at some point or not.
- I don't really understand the second scheme. If you have a link to relevant literature then please reply with it. If this is an idea of yours, then I'd suggest writing it up and submitting it somewhere for discussion, to see if there are any issues with it. There is a fairly extensive set of publications on SCA at for example CHES, so it might be worth checking whether it has been discussed before. You could also consider e.g. crypto stackexchange or various other internet forums.
@veorq recommend closure for the moment. We can add specific recommendations if needs be at a later date.
I have a (1)suggestion and a (2)question about the "Compare secret strings in constant time".
(1) I guess the Cryptocoding resource is supposed to be an introduction beside giving expertise.
For the first group an advise to only use hashes of plain text for (database storage and) comparison of secrets might be helpful. Furthermore the comparison algorithms might be tailored and optimized for fixed length of hashes. Mentioning this might be helpful.
(2) I know, constant time comparison is kind of a mantra in security, but what about a randomized shuffled index test with the time variant code (using hashes, of course)?
Why? From a perspective of practical attack costs a randomly shuffled first-fault-breaks-comparison attempt makes timing attacks equally hard but might result in automated or ai based attacks going for it anyways and therefore waisting time on it. There is additional processing cost on side of the defender to shuffle the indices. Anyway this might be outweight by the tactical advantage of luring the attacker into investing resources.
Thanks for reading
Andreas