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
signature.asc
Description: OpenPGP digital signature
