Re: gnupg rsa question // why use e of 41 ?

daniel bleichenbacher wrote:
David Wagner wrote:
daniel bleichenbacher wrote:
If you use appropriate padding, I'm not aware of any attack that works
against e=3 but fails against e=65537.

Coppersmiths short padding attack is just one example.

I feel like I'm repeating myself, so maybe this is obvious, but I'll say
again that if you use appropriate padding, Coppersmith's attack is not
a danger, no matter what value of e you use. I feel like maybe we're
talking in circles here.

Anyway, ok, I hear your point that if you're worried about implementation
errors, maybe using a large e is justifiable as a robustness measure.
I still find large-e rather questionable; I'm not convinced this would
be among my top-10 list of best ways to improve robustness, but I won't
argue this any further.

Too bad you can't share your examples, but I understand the restrictions.
I hope you'll be able to publish them someday -- I'd look forward to that.
I think they might be eye-opening.

I still wonder whether this is what the gpg authors were thinking
when they wrote that comment. If they were thinking about robustness
against implementation errors, I would have figured they might write a
comment saying that e=65537 is more robust, and maybe even explain why.
It seems less natural to claim without elaboration that e=65537 is more
secure, if the real intent was robustness against implementation errors.
There is a widespread misconception that e=3 is insecure or less secure,
and it sounded like maybe that's what the implementor was thinking of.
But maybe I'm misreading the intent based on a very brief comment in
the code.

All he needed to know is that smaller exponents might be more risky
than bigger ones. I prefer developers that try to be on the safe side
to the ones that spend most of their time optimizing the running time
of their implementation.


Relevant Pages

  • new SSH vulnerability?
    ... Not being an expert on SSH protocol implementations myself, ... HOW THE ATTACK WORKS ... and attempt to interpret the results as PKCS-5 ... padding, and perhaps respond. ...
  • Re: new SSH vulnerability?
    ... > that use CBC chaining and PKCS-5 padding (a pretty common ... > this woudl be a good place to find out if SSH ... > HOW THE ATTACK WORKS ... > padding, and perhaps respond. ...
  • Re: new SSH vulnerability?
    ... That would avoid this particular attack, ... is called with a message that is returned to the sender of the message ... Since the padding check occurs before the CRC check, ... That would be a big problem if PKCS-5 padding ...
  • Re: SSL Attack
    ... > padding check and the MAC verification, even if the padding is invalid. ... except that to deal with the attack you have to do ...
  • Re: Steal This Film (Sweden) 2006
    ... File sharing is exactly what the internet was created for. ... And robustness against attack. ...