Closed tobycmurray closed 1 year ago
My writing is probably suboptimal. The documentation (comments in cttk.h) says:
* Constant-time behaviour: the values of hex digits are protected, but
* not their number or location. Side channels may leak the total number
* of hex digits, and the position of whitespace characters (if skipped).
The parsing stops at the first error. If whitespace characters are allowed (and skipped) then they do not trigger any error, but their position may leak. If whitespace characters are not allowed then the first encountered non-hex character, be it whitespace or not, triggers an error, which is also nominally observable through side-channels and is covered by "the total number of hex digits".
In general it is quite hard to hide which source characters contain actual hex data, because the writing of output bytes (a part of the memory access pattern) depends on when such bytes become available. Thus, the total number of considered characters, and also the position of non-hex characters encountered before giving up, will leak.
Against commit 1d592024398f06c8eda1d325bdbd105ac32d92b3
The conditional test
if (d < 0)
on line 129 of hex.c may leak information, in particular information on non-hex characters contained in the input.Specifically, my understanding from reading the comment in cttk.h is that this function is allowed to leak the location of whitespace characters if they are skipped. But this if branch occurs before testing the flags for skipping whitespace. Perhaps I am misunderstanding the intention here, but to me this seems to be leaking whenever a non-hex character is encountered in the input.
This potential issue was discovered with the aid of Underflow (https://bitbucket.org/covern/underflow/)