Re: openssl-blacklist & two keys per one pid
On Wed, May 21, 2008 at 2:46 PM, Dirk-Willem van Gulik
<dirkx@webweaving.org> wrote:
> On May 21, 2008, at 12:06 PM, Bodo Moeller wrote:
>> A more elaborate explanation seems in place to make sure that
>> we avoid uninentionally incomplete blacklists.
>> I'd expect there to be some significant overlapping between the
>> blacklists, but these should still be different lists: Many RSA moduli
> Yes - there absolutely is.
>> will appear on both lists, but some will only appear on the e = 3 list
>> (option -3) and others only on the e = 65537 list (option -F4).
> Just to put a 'estimate' onto this - this does not happen all that commonly; only
> about once every many hundred keys - and, as it is not endianness/bit specific,
> I believe that only the clashes* need to be re-calculated.
So it turns out that the reason this happens rarely is that, even for
e = 3, the function used to generate primes for RSA keys tries to
avoid having any small factors in p - 1 or q - 1 other than powers
of 2. Apart from 2, none of the first 2048 primes will appear as a
factor of p - 1 or q- 1. Thus usually the initially chosen primes
will work well even for e = 3. For the deterministically
pseudorandom calculation based on 2^15 different PIDs, there should be
roughly one instance where moduli differ between the e = 3 and e =
63357 settings.
(The deterministic PRNG output should be totally different between
big-endian and little-endian scenarios and different word sizes, so
specific results from any one architecture tell you nothing about
specific results for any different architecture. Just the approximate
proportian of such differences will be similar.)
Bodo
Reply to: