Related, not a duplicate: Timing Safe String Comparison - Avoiding Length Leak
- I know about cache misses, let's assume we fit in a cache line swimmingly.
- Thomas' excellent answer doesn't talk about jitter except that introduced by GC, nor does it touch upon asynchronous execution.
- We can assume a low-level implementation (assembler, C, F77, Forth) that can be used in any higher-level language (e.g. Python)
Please correct me if I'm mistaken:
- We are talking about comparing two strings of unequal length. The first one is chosen by Eve, the second belongs to Alice. Alice wants to prevent Eve from learning length and/or content of the second string.
No existing mainstream programming language has constant-time string comparison routines in its standard library.
To avoid leaking length information, do we
- precompute hash of
Victoria'sAlice's secret (hash function itself must be not vulnerable to timing attacks) - compute hash of Eve's evil string
- compare hashes (equal-length strings by definition of the hash function) in constant time
or
- simply compare Eve's string byte by byte to Alice's secret, incrementing a counter (or two counters, one each for matching and not matching bytes?) until the end of Eve's string?
- precompute hash of
Is introduction of cryptographically random jitter a valid defense-in-depth measure? (Please assume this happens across a LAN at a quiet time when natural timing noise is at a minimum).
Is asynchronous execution of comparisons (with some hard realtime guarantees) a viable defense? (Yeah, I know another side channel may be leaking)
What I'm not soliciting:
- language/product recommendations
- answers 'it depends on your threat model' (my threat is hiding in another server across the room, with an unlimited number of tries)