Make bin2hex() and hex2bin() timing safe #1453
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See also: http://markmail.org/message/4wwjnqr3sz6cqaxh
bin2hex()
is using a lookup table; there is potential for a cache timing attack if not aligned on 16 byte boundary.Solved via explicit alignment. (No perf change)
hex2bin()
is using branches to differ between 0-9 and a-f/A-F. Simple timing attack potential.Using a branchless construct solves this [The only branch is early abort on malformed hex, which is not an issue]. (Performance in best-case is worse, but better than average-case [at least locally]. Currently average case has about 20% mispredictions (tested on just normal text), which makes it slower than the branchless code.)
That way
hex2bin()
even has a slight performance benefit in addition to time safety.