Added more constant-time code / removed biases in the prime number generation routines.

[cryptopathe]

This pull request brings two changes:

• I have improved the time- and flow- constantness of some parts of the code handling big integers;
• I have removed statistical biases in the prime generation routines, and implemented a rejection method instead, which is the proper way to do. Such biases might have devastating consequences in terms of security for certain public-key cryptosystems. Note that I don't claim any attack here: I am not an expert in this field of cryptanalysis. However, look at the paper of Aranha et al. GLV/GLS Decomposition, Power Analysis, and Attacks on ECDSA Signatures With Single-Bit Nonce Bias presented at ASIACRYPT'14 as well as the references therein to be convinced that biases are bad in cryptography.

[mpg]

(Edit: previous message send before it was complete, sorry.)

Thanks for your contribution!

• Regarding constantness: I know people tend to avoid equality comparisons because they might be implemented using a branch, but I checked the assembly produced for a = (b == 0) by common compilers with various optimization options for x86 and arm, and it looks constant time to me. (Which is not surprising: branches are bed for performance too.) I would like to avoid impairing readability for no good reason. Do you have an example of compiler&platform where == produces a branch? Or a solid reference for why == should be avoided?
• Regarding biases, I'm quite convinced they should be avoided, but thanks for the reference anyway. Our key generation function for ECC (including ephemeral ECDSA exponents) already uses a rejection method for this reason. I forgot to check mpi_gen_prime(), thanks.

[cryptopathe]

Regarding ...by common compilers with various optimization...: for sure, it is impossible to check every version of every compiler on every platform with every flag combination. Therefore, I tend to prefer writing flow-constant code, for security hygiene reasons, even if it is less readable. For a solid reference, see e.g. https://cryptocoding.net/index.php/Coding_rules#Compare_secret_strings_in_constant_time

[mpg]

I agree it's impossible. But for the same reason, it's impossible to guarantee that flow-constant C code will always be translated to flow-constant assembly code by every compiler on every platform with every flag combination, and the cited reference indeed gives an example when that fails to happen: uint32_t ct_select_u32(uint32_t x, uint32_t y, _Bool bit).

This reference (which I already knew) is indeed solid on the how, but IMO no so solid on the why. For constant-time string comparison, it jumps straight from the obviously bad "stop early" version to the version with only bit operations without a word about why they think a version with a constant number of iterations but using == would not be enough. What I would love to see is a comparative table that, for a reasonable set of platforms/compilers/constructs, tells which way of coding (eg with == vs only bit operations) results in branches and which doesn't. I'd like hard data rather than just making assumptions (even if those are indeed quite reasonable).

OTOH, I agree that the way of coding you recommend is indeed the accepted "best practice". I just feel chronically uncomfortable about this "best practice" being, IMHO, not that well motivated. (This probably shows in my code, which currently contains a mix of == and bit-operation equivalents.)

[mpg]

PS: just to be clear, I've been arguing about the constant-time part because I was hoping you could convince me, rather that the other way round :)

[mpg]

Ok, I finally convinced myself that replacing == by bit operations is indeed useful, by collecting some data: https://github.com/mpg/ct/blob/master/results :)

I guess I'm in for some code review and fixing (I'm sure there are other places than these, at least one in our Bleichenbacher counter-measure in ssl_srv.c, but maybe others as well).

[cryptopathe]

Thank you to provide this information: it confirms my feelings (and those of many applied cryptographers), and the strategy of being conservative regarding those aspects! Are you going to keep the link https://github.com/mpg/ct/blob/master/results alive? If yes, one might add a link to it on https://www.cryptocoding.net.

[mpg]

I fully intend to keep the data available (since having to rely on feelings rather than data was the main reason for my earlier hesitations, so I hope it will help others), but it's not entirely clear yet if this specific link will continue to work. However, I can update the link on cryptocoding.net if/when it changes.

[pjbakker]

Hi Pascal,

I'm currently busy getting a standard CLA for mbed TLS within ARM. When that is done, I'll send it to you, so we can integrate your improvements into the core codebase!

[pjbakker]

Pascal,

It is done. Can you send me your e-mail address? paul dot bakker at arm dot com