Skip to content
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

Open
defuse opened this issue Apr 21, 2014 · 5 comments
Open

Side Channel Attacks #14

defuse opened this issue Apr 21, 2014 · 5 comments

Comments

@defuse
Copy link
Owner

defuse commented Apr 21, 2014

passgen appears vulnerable to cache side channel attacks. For example, when generating a standard character password:

// Discard the random byte if it isn't in range.
if(c < setLength) {
    password[i] = set[c];
    i++;
}

And when generating a random word password:

printf("%s", words[random]);

These should be replaced with constant-time lookups.

@defuse
Copy link
Owner Author

defuse commented Apr 21, 2014

Also, do another pass checking for other side channels (keep FLUSH+RELOAD etc. in mind).

@defuse
Copy link
Owner Author

defuse commented Apr 21, 2014

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.

@defuse defuse mentioned this issue Apr 21, 2014
@defuse
Copy link
Owner Author

defuse commented Apr 25, 2014

Fixed the cache side channels for characer-based passwords in 212a623 onward. Fixed cache side channels for word-based passwords in 2237ad2.

@defuse
Copy link
Owner Author

defuse commented Apr 25, 2014

Left to do:

  • Explain in the help output why word passwords end with dots (I like dots because it's obvious that they're there).
  • Look for other side channels.
  • Verify fixes for side channels.

@defuse
Copy link
Owner Author

defuse commented Apr 25, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant