3 ms·
I'm not an expert at all, but from what I've read about the C standard and how compilers interpret it, it seems dangerous to implement things like this (constan
by unwind 7y ago
I'm not an expert at all, but from what I've read about the C standard and how compilers interpret it, it seems dangerous to implement things like this (constant time integer multiplication) as C macros.
It should probably be done in (inline) assembly, to avoid the compiler optimizing away the extra "pointless" bits for instance. Just because a favorite compiler doesn't do it today, doesn't mean it's safe.
I'm sure the actual authors of code like this have analyzed the resulting code and know more than I do about the safety of the operations involved, but I didn't see that covered in the article.
- tprynn 7y agoThe reason not to implement this in inline assembly is that you would have to implement unique assembly for each architecture supported, which would mean probably dozens of different implementations, especially considering that even on a given architecture there are notable processor-family differences in whether the same multiply instruction is constant time or not. In any case, I think it's safe to say that 'pornin knows more about writing safe C code (and dealing with strange compiler behavior) than almost anyone.
- andrewla 7y agoBut that's the core of the problem -- the code has to be architecture specific because the constant nature of integer multiplication depends on the processor architecture. Once you're writing a multiple for an XX-generation Intel processor, you might as well write it as assembly, rather than have a MUL_XX macro that will probably do the right thing.
- svnpenn 7y ago> I think it's safe to say that 'pornin knows more about writing safe C code > (and dealing with strange compiler behavior) than almost anyone. Yeah, I agree hehe: https://stackexchange.com/leagues/162/alltime/security https://stackexchange.com/leagues/162/alltime/security