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

Is this library constant time? #30

Open
FredericJacobs opened this issue Mar 8, 2014 · 9 comments
Open

Is this library constant time? #30

FredericJacobs opened this issue Mar 8, 2014 · 9 comments

Comments

@FredericJacobs
Copy link

No description provided.

@tonyg
Copy link
Owner

tonyg commented Mar 8, 2014

If nacl is (which I think it is), and emscripten preserves that property (which I think it should), then this library will be. But I don't know for sure one way or the other.

@tonyg tonyg closed this as completed Mar 8, 2014
@FredericJacobs
Copy link
Author

Isn't this something that should be investigated and tested?

@tonyg
Copy link
Owner

tonyg commented Mar 8, 2014

Yes please :-)

@FredericJacobs
Copy link
Author

What I meant by that is that the issue shouldn't be closed on a simple "I think it is/should" note.

@tonyg
Copy link
Owner

tonyg commented Mar 8, 2014

Ah, I see. I'll reopen it, as the question still stands. I'm afraid I don't have the bandwidth to look into it myself at the moment; if you can help, I'd appreciate it.

@cwillu
Copy link

cwillu commented Aug 10, 2014

The library should carry a prominent warning until this has been checked. It's a critical property, and usually requires special handling for a given compiler.

@3nsoft
Copy link

3nsoft commented Aug 10, 2014

When saying "constant time library", what do you mean?

  1. If meaning is "constant time check when authenticating message" in Poly code. Then answer is yes, NaCl's comparison of vectors goes exactly the same time (constant time) irrespective of where incorrect bit is encounted.

  2. If meaning is "(de)encryption time not dependent of message content" in Salsa code. Then answer is yes. (De)Encryption time depends only on message length.

  3. If meaning is "immune to timing attack", then it is the same as meaning (1), and answer is, therefore, yes.

Please notice that this is all due to C code, written by original authors.

@tonyg close this issue.

@tonyg
Copy link
Owner

tonyg commented Aug 11, 2014

@3nsoft agreed that the C code takes particular care to ensure these properties -- however, because I haven't actually tested it yet, I can't be sure that emscripten (or, for that matter, the javascript JIT) doesn't take liberties. I'd be surprised if there was a problem, but until it has been tested, I can't be sure.

If anyone feels able to contribute a test-case showing (with high probability) that we really do enjoy constant-time bytevector comparisons, I'd love to include it.

@elimisteve
Copy link

Yes, please include a prominent warning in the README that says that this crypto has not been thoroughly audited; that's exactly what I came here to check because it's necessary for building systems that are secure!

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

4 participants