Open defuse opened 10 years ago
Also, do another pass checking for other side channels (keep FLUSH+RELOAD etc. in mind).
FLUSH+RELOAD would leak what type of password is being generated (hex, ascii, alpha, word, etc). I don't see an easy way to defend against that.
Fixed the cache side channels for characer-based passwords in 212a623b81dce49b8b15852dff21387f2795b5aa onward. Fixed cache side channels for word-based passwords in 2237ad267d5385731a116b0b0f48c7d9e1b13223.
Left to do:
We can probably make a script that outputs all of the branch (if, while, etc.) conditions and all of the array accesses, (and maybe even non-constant-time operations like shifts) and we can go over each one and give a reason why it doesn't leak useful information.
Actually, something like that could be a useful tool on its own.
Edit: More thoughts: It could be a simple C parser, that just spits out all of the variables of which information is leaked. We could also define a macro like safe(variable) which would whitelist that variable as being non-sensitive information that's OK to leak and could be automatically excluded from the output. Then, if all of the code is good, the output should be empty.
passgen
appears vulnerable to cache side channel attacks. For example, when generating a standard character password:And when generating a random word password:
These should be replaced with constant-time lookups.