feat: Configurable blinding #4562
Conversation
tls/s2n_connection.c
Outdated
| * hypothetical timing difference of 1us, the number of attempts necessary to recover a byte is | ||
| * (((30 - 10) * 10 ^6)^2)/12 ~= 3.3 trillion (note that we first have to convert from seconds to |
There was a problem hiding this comment.
What does recovering a byte mean here? I would have assumed the calculation would be in terms of number of samples required to observe a timing difference. Or is this description specifically related to lucky 13?
There was a problem hiding this comment.
It's the number of samples required to distinguish the timing distributions from a correctly guessed byte versus incorrectly guessed bytes. In lucky13 in particular, if you've correctly guessed the last byte of padding, the timing distribution that is created from sampling that byte would be slightly different than the timing distributions of an incorrect byte.
😮💨 So hard to describe this.
There was a problem hiding this comment.
Do you think I could add something to make this paragraph more clear?
There was a problem hiding this comment.
No I think it makes sense. I guess I just wasn't sure if this same description could be applied to all sidechannels or just lucky 13. Like, could there be a timing difference that could be exploited without the goal of differentiating a correct byte from an incorrect byte? If so, then it might help to clarify that this example of recovering bytes is specific to lucky 13.
| #define S2N_DEFAULT_BLINDING_MAX 30 | ||
| #define S2N_DEFAULT_BLINDING_MIN 10 |
There was a problem hiding this comment.
Would it be simpler to only keep track of the max and just always / 3 for the min? Or is it better to state the default values explicitly?
There was a problem hiding this comment.
I like having them called out explicitly for this particular feature. The min and max are really important for understanding the fixed versus variable part of blinding.
tls/s2n_connection.c
Outdated
| * hypothetical timing difference of 1us, the number of attempts necessary to recover a byte is | ||
| * (((30 - 10) * 10 ^6)^2)/12 ~= 3.3 trillion (note that we first have to convert from seconds to |
There was a problem hiding this comment.
No I think it makes sense. I guess I just wasn't sure if this same description could be applied to all sidechannels or just lucky 13. Like, could there be a timing difference that could be exploited without the goal of differentiating a correct byte from an incorrect byte? If so, then it might help to clarify that this example of recovering bytes is specific to lucky 13.
Resolved issues:
Resolves #4508
Description of changes:
Adds an option to set a configurable blinding timeout instead of going with the default of 10-30 seconds. This is to encourage applications that turn off blinding completely to instead opt-in to an amount of blinding that they can handle.
Call-outs:
Note that I offer an in-depth comment for developers rather than one for users. I don't think most users need to know about our blinding rational. They just need to know that the best blinding is the default, and anything less will lower the security bar. However, if we want my more in-depth discussion about how blinding mitigates Lucky 13, I could add that discussion to the user guide. It just seemed too detailed for normal users.
Testing:
Includes tests to make sure that blinding range is calculated as expected.
Is this a refactor change? If so, how have you proved that the intended behavior hasn't changed?
Should be no behavior change.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.