-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Side Channel Attacks #14
Comments
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. |
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.
The text was updated successfully, but these errors were encountered: