[Cryptography] Zoom publishes draft cryptographic design for end-to-end encryption
crypto at senderek.ie
Fri Jun 5 04:33:07 EDT 2020
On Fri, 5 Jun 2020, Peter Gutmann wrote:
> Ralf Senderek <crypto at senderek.ie> writes:
>> On Thu, 4 Jun 2020, Florian Weimer wrote:
>>> Beside DH parameters, the other rather astonishing example is the
>>> public RSA exponent. You cannot even use a random value there anymore
>>> because some implementations do not allow an arbitrary-precision
>>> integer for it:
>> In which implementation do you think I found this?
> However, even that implementation complains about non-32-bit integers as
> exponents. That's based on the fact that in 25 years of use there's only been
> one implementation that required a bignum exponent and that was created by
> people who were cleverer than everyone else and decided sizeof( e ) must equal
> sizeof( n ). In practice virtually everyone sets e = F4, which is fine.
Well, everything can be overdone, because forcing a 2048 bit n to be used
with a 2041 bit e will give them quite a handy, small private decryption
But in a 2012 paper "Ron was wrong, Whit is right"  the researchers
found that in a collection of 11 million RSA-keys found in the wild
there were a disturbingly large number of moduli which were either
shared between different RSA-keys or which at least had ONE common prime
factor. They wrote :
"Compared to the collection of certificates considered in , where
shared RSA moduli are “not very frequent”, we found a much higher
fraction of duplicates. More worrisome is that among the 4.7 million
distinct 1024-bit RSA moduli that we had originally collected, more
than 12500 have a single prime factor in common. That this happens
may be crypto-folklore, but it was new to us, and it does not seem
to be a disappearing trend: in our current collection 3 of 7.1 million
1024-bit RSA moduli, almost 27000 are vulnerable and 2048-bit RSA
moduli are affected as well."
I don't want to re-ignite our anually randomness thread here, but I doubt
that the situation today is very different from 2012 and adding another
constant to the mix by fixing e to a commonly used sub-32-bit value does
not increase my feel-good factor much.
At least it's nice to know that it is possible to moderately incresase
the length of e if the implementation has made proper precautions.
More information about the cryptography