Minor documentation improvements:
*Standardized file brief description.
*Separated return statements.
*Reordered tags within documentation blocks so that params and returns are last in block.
*p_rng descriptions changed from "parameter" to "context".
*Suggest to specify issue for each return code, where multiple failure return codes are listed, or generalize.
*Minor improvements to parameter documentation proposed by eng.
1. Add 3des context to be allowed for alternative defintion
2. Move some ecp structs, to disallow alternative definition of them,
as other modules rely on them
The specification requires that P and Q are not too close. The specification
also requires that you generate a P and stick with it, generating new Qs until
you have found a pair that works. In practice, it turns out that sometimes a
particular P results in it being very unlikely a Q can be found matching all
the constraints. So we keep the original behavior where a new P and Q are
generated every round.
The specification requires that numbers are the raw entropy (except for odd/
even) and at least 2^(nbits-0.5). If not, new random bits need to be used for
the next number. Similarly, if the number is not prime new random bits need to
be used.
Attacks against RSA exist for small D. [Wiener] established this for
D < N^0.25. [Boneh] suggests the bound should be N^0.5.
Multiple possible values of D might exist for the same set of E, P, Q. The
attack works when there exists any possible D that is small. To make sure that
the generated key is not susceptible to attack, we need to make sure we have
found the smallest possible D, and then check that D is big enough. The
Carmichael function λ of p*q is lcm(p-1, q-1), so we can apply Carmichael's
theorem to show that D = d mod λ(n) is the smallest.
[Wiener] Michael J. Wiener, "Cryptanalysis of Short RSA Secret Exponents"
[Boneh] Dan Boneh and Glenn Durfee, "Cryptanalysis of RSA with Private Key d Less than N^0.292"
Clang-Msan is known to report spurious errors when MBEDTLS_AESNI_C is
enabled, due to the use of assembly code. The error reports don't
mention AES, so they can be difficult to trace back to the use of
AES-NI. Warn about this potential problem at compile time.
Zeroing out an fd_set before calling FD_ZERO on it is in principle
useless, but without it some memory sanitizers think the fd_set is
still uninitialized after FD_ZERO (e.g. clang-msan/Glibc/x86_64 where
FD_ZERO is implemented in assembly). Make the zeroing conditional on
using a memory sanitizer.
The initialization via FD_SET is not seen by memory sanitizers if
FD_SET is implemented through assembly. Additionally zeroizing the
respective fd_set's before calling FD_SET contents the sanitizers
and comes at a negligible computational overhead.
