[Cryptography] Zoom publishes draft cryptographic design for end-to-end encryption

[Ralf Senderek]

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.
>
> Peter.

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
exponent d.

But in a 2012 paper "Ron was wrong, Whit is right" [1] 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 [12], 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.

     --ralf



[1] https://eprint.iacr.org/2012/064.pdf