RE: [PATCH] User can choose the public exponent in genrsa
From: owner-openssl-...@openssl.org On Behalf Of Stephan Mueller Sent: Friday, November 14, 2014 15:00 snip I agree allowing to choose an arbitrary e is not so good. However, what kind of threats do you see when we would: - use 2**16+1 per default - allow 17 (-F4) as a legacy F4 is 2**16+1=65535. 2**4+1=17 is F4 and is not currently supported in genrsa (but see next) - allow arbitrary e as long as they are odd and larger than 2**16-1 - disallow anything else. Note genpkey already supports setting rsa_keygen_pubexp and is recommended for new uses over legacy genrsa as well as gendsa and ecparam -genkey . __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[PATCH] User can choose the public exponent in genrsa
The user can call RSA key generation and specify the public
exponent exp in a hexadecimal format.
Example: openssl genrsa -choose 72bdf -out key.pem 4096
Signed-off-by: Quentin quentin.gouc...@gmail.com quentin.gouc...@gmail.com
---
apps/genrsa.c | 47 +++
crypto/objects/obj_xref.h | 2 +-
2 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/apps/genrsa.c b/apps/genrsa.c
index 6b835c0..fd4bb63 100644
--- a/apps/genrsa.c
+++ b/apps/genrsa.c
@@ -98,6 +98,7 @@ int MAIN(int argc, char **argv)
long l;
const EVP_CIPHER *enc=NULL;
unsigned long f4=RSA_F4;
+ char *exp = NULL;
char *outfile=NULL;
char *passargout = NULL, *passout = NULL;
#ifndef OPENSSL_NO_ENGINE
@@ -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)
{
@@ -218,6 +235,7 @@ bad:
BIO_printf(bio_err, -passout argoutput file pass phrase
source\n);
BIO_printf(bio_err, -f4 use F4 (0x10001) for the E
value\n);
BIO_printf(bio_err, -3 use 3 for the E value\n);
+ BIO_printf(bio_err, -choose exp use exp hexadecimal string
as
public exponent\n);
#ifndef OPENSSL_NO_ENGINE
BIO_printf(bio_err, -engine e use engine e, possibly a
hardware device.\n);
#endif
@@ -273,29 +291,42 @@ bad:
#else
rsa = RSA_new_method(e);
#endif
+
if (!rsa)
goto err;
if (non_fips_allow)
rsa-flags |= RSA_FLAG_NON_FIPS_ALLOW;
- if(!BN_set_word(bn, f4) || !RSA_generate_key_ex(rsa, num, bn, cb))
+ if (exp != NULL)
+ {
+ if (!RSA_generate_key_ex(rsa, num, bn, cb))
+ goto err;
+ }
+ else if(!BN_set_word(bn, f4) || !RSA_generate_key_ex(rsa, num, bn, cb))
goto err;
-
+
app_RAND_write_file(NULL, bio_err);
/* We need to do the following for when the base number size is
* long, esp windows 3.1 . */
- l=0L;
- for (i=0; irsa-e-top; i++)
+ if (exp == NULL || strlen(exp) = 16)
{
+ l=0L;
+ for (i=0; irsa-e-top; i++)
+ {
#ifndef SIXTY_FOUR_BIT
- l=BN_BITS4;
- l=BN_BITS4;
+ l=BN_BITS4;
+ l=BN_BITS4;
#endif
- l+=rsa-e-d[i];
+ l+=rsa-e-d[i];
+ }
+ BIO_printf(bio_err,e is %ld (0x%lX)\n,l,l);
+ }
+ else if (exp != NULL)
+ {
+ BIO_printf(bio_err,e is 0x%s\n,exp);
}
- BIO_printf(bio_err,e is %ld (0x%lX)\n,l,l);
{
PW_CB_DATA cb_data;
cb_data.password = passout;
diff --git a/crypto/objects/obj_xref.h b/crypto/objects/obj_xref.h
index cfd628a..2b3dc6d 100644
--- a/crypto/objects/obj_xref.h
+++ b/crypto/objects/obj_xref.h
@@ -54,8 +54,8 @@ static const nid_triple sigoid_srt[] =
static const nid_triple * const sigoid_srt_xref[] =
{
sigoid_srt[29],
- sigoid_srt[17],
sigoid_srt[18],
+ sigoid_srt[17],
sigoid_srt[0],
sigoid_srt[1],
sigoid_srt[7],
--
2.1.0
Re: [PATCH] User can choose the public exponent in genrsa
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.
--
Viktor.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [PATCH] User can choose the public exponent in genrsa
On 11/14/2014 07:47 AM, Quentin Gouchet wrote: The user can call RSA key generation and specify the public exponent exp in a hexadecimal format. Example: openssl genrsa -choose 72bdf -out key.pem 4096 Signed-off-by: Quentin quentin.gouc...@gmail.com quentin.gouc...@gmail.com This is an interesting proposal, but i don't think it's a good idea. + /* 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 + */ This strikes me as dangerously misguided. See section 4 of Twenty years of attacks on the RSA cryptosystem by Dan Boneh for a description of several attacks on low public exponents: https://crypto.stanford.edu/~dabo/pubs/papers/RSA-survey.pdf And afaict, e = 1 is a complete disaster. There are also more mundane problems with this patch (note that resolving these easy problems doesn't fix the serious concerns described above). * if it's going to be done, the argument should be better than -choose -- something like -exponent would be clearer. * there is no patch to the genrsa manpage included * the value is interpreted as hexadecimal, even though other values passed by the user to genrsa (like the number of bits) is interpreted as decimal --dkg signature.asc Description: OpenPGP digital signature
Re: [PATCH] User can choose the public exponent in genrsa
Am Freitag, 14. November 2014, 08:08:00 schrieb Daniel Kahn Gillmor: Hi Daniel, On 11/14/2014 07:47 AM, Quentin Gouchet wrote: The user can call RSA key generation and specify the public exponent exp in a hexadecimal format. Example: openssl genrsa -choose 72bdf -out key.pem 4096 Signed-off-by: Quentin quentin.gouc...@gmail.com quentin.gouc...@gmail.com This is an interesting proposal, but i don't think it's a good idea. I agree allowing to choose an arbitrary e is not so good. However, what kind of threats do you see when we would: - use 2**16+1 per default - allow 17 (-F4) as a legacy - allow arbitrary e as long as they are odd and larger than 2**16-1 - disallow anything else. I see that this patch does not enforce such restrictions. I suggest to update the patch to cover the mentioned restrictions. This should be harmless and give a user more flexibility without giving him a gun to shoot himself. -- Ciao Stephan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] User can choose the public exponent in genrsa
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
Re: [PATCH] User can choose the public exponent in genrsa
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
