Hi Ben,
I will add the proper validation for the exponent to be chosen by the user
then, taking in account everybody's comments.
Best,
Quentin
Quentin Gouchet
-----------------------------------------
Mobile: +46(0)723-843256
2014-11-14 14:10 GMT-06:00 Benny Baumann <be...@geshi.org>:
> Hi,
>
> Am 14.11.2014 um 19:07 schrieb Viktor Dukhovni:
> > On Fri, Nov 14, 2014 at 11:47:11AM -0600, Quentin Gouchet wrote:
> >> @@ -139,6 +140,22 @@ int MAIN(int argc, char **argv)
> >> f4=3;
> >> else if (strcmp(*argv,"-F4") == 0 || strcmp(*argv,"-f4")
> == 0)
> >> f4=RSA_F4;
> >> + else if (strcmp(*argv,"-choose") == 0)
> >> + {
> >> + if (--argc < 1) goto bad;
> >> + exp = *(++argv);
> >> + /* Not checking whether exp >= 2**16+1 since there
> is
> >> + * no proof that small
> >> + * public exponent is a threat.
> >> + * Choosing e = 1 or e = 3 is thus possible
> >> + */
> >> + if(!BN_hex2bn(&bn,exp)) goto err;
> >> + if(!BN_is_odd(bn))
> >> + {
> >> + BIO_printf(bio_err,"Public exponent e has
> to be odd\n");
> >> + goto err;
> >> + }
> >> + }
> >> #ifndef OPENSSL_NO_ENGINE
> >> else if (strcmp(*argv,"-engine") == 0)
> >> {
> >
> > * The "-choose" option is too vague. Every option is a choice,
> > Better would be "-public_exponent".
> >
> > * Small public exponets ARE a threat, and in particular "e=3"
> > MUST be avoided. While "e=5" or "e="17" are somewhat less
> > risky, I'd steer clear of these also.
> >
> > Fielded system with "e" set to something other than "3" or "65537"
> > are rare. Are custom public exponents really a good idea? Seems
> > like unnecessary flexibility for the user to mess up. I'd bolt it
> > down at 65537 and remove all other options.
> >
> Please don't bolt down at a fixed value, but instead only check sanity
> of the choosen values. I use non-standard value for e in several places
> and bolting things down on one value will cause trouble should we
> someday discover that even 65537 is a bad choice, but an even bigger
> exponent needs to be used instead.
>
> Already now we have a problem with being limited to about 192 bit
> effective security due to arbitrary limitations in the code[1]. As
> explained there when using client certificates you are bound to 128 bit
> as your certificate (if not ECC) becomes the limiting factor. Overcoming
> those limits is hard enough as it stands. Let alone that the library
> claims to be written without artificial restrictions.
>
> Using non-standard exponents should be hard (and AFAIK there is a way
> currently implemented already, it's just hardly documented anywhere),
> such that you cannot plausibly deny you didn't know what you were doing,
> but the library shouldn't throw rocks in your way either when you do.
>
> Thus I'd prefer to skip this patch (for the reasons mentioned already by
> others) and either do no change OR just add proper validations for the
> exponent chosen by the user.
>
> Kind regards,
> BenBE.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747453
>
>
