Minimum RSA Key length ?
Asad Ali
Hi,
I am experimenting with the minumum RSA key lenght allowed
by TLS 1.0. What I gather from reading the specification is
that it is left to applications to enforce minimum/maximum
lenghts - please correct me if this is not the case.
Assuming that TLS 1.0 spec does not place any restriction on
the RSA key size in a server certificate, does OpenSSL have
any such restriction. e.g. will it allow creation of a server
certificate with only 128 bit RSA key? I know it is very
insecure, but I want to ignore that part for now.
Also what about the browsers? will IE or Netscape accept
such a certificate during TLS handshake?
thanks,
--- asad
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Dr. Stephen Henson
>
> Hi,
>
> I am experimenting with the minumum RSA key lenght allowed
> by TLS 1.0. What I gather from reading the specification is
> that it is left to applications to enforce minimum/maximum
> lenghts - please correct me if this is not the case.
>
There are various minimum limitations based on the protocol requirements of
TLS.
For example in static RSA ciphersuites it must be possible to encrypt the
pre-master secret using the server's public key. The PMS is 48 bytes in length
and the PKCS#1 padding overhead is 11 bytes effectively making the absolute
minimum 59 * 8 = 472 bits.
For client certificates or for ciphersuites where server certificates sign
data it must be able to contain the combined SHA1+MD5 hash and with the
overhead again this is 20+16+11 = 47 or 376 bits.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: she...@drh-consultancy.demon.co.uk, PGP key: via homepage.
Asad Ali
Does TLS support any "non-static" RSA ciphersuites. For example is
it possible to use a 128 bit key to encrypt the pre-master secret
in chunks of 16 bytes (including the padding), or use a 256 bit
key to encrypt it in 32 byte chunks.
regards,
--- asad
Dr. Stephen Henson
>
> Does TLS support any "non-static" RSA ciphersuites. For example is
> it possible to use a 128 bit key to encrypt the pre-master secret
> in chunks of 16 bytes (including the padding), or use a 256 bit
> key to encrypt it in 32 byte chunks.
>
No, the standards expect it to be handled in one chunk.
John....@rnib.org.uk
> From: Asad Ali [mailto:am...@austin.apc.slb.com]
> Sent: 26 March 2003 16:36
> To: openss...@openssl.org
> Subject: Minimum RSA Key length ?
>
>
>
> Hi,
>
> I am experimenting with the minumum RSA key lenght allowed
> by TLS 1.0. What I gather from reading the specification is
> that it is left to applications to enforce minimum/maximum
> lenghts - please correct me if this is not the case.
>
> the RSA key size in a server certificate, does OpenSSL have
> any such restriction. e.g. will it allow creation of a server
> certificate with only 128 bit RSA key? I know it is very
> insecure, but I want to ignore that part for now.
>
> Also what about the browsers? will IE or Netscape accept
> such a certificate during TLS handshake?
>
> thanks,
> --- asad
To answer your other question, I don't believe there are any browsers that
can accept a RSA key > 1024 bits. I did look into this last year as I was
creating a new SSL key but was advised by the Thawte representative that
although I could create a certificate with this size key, it wouldn't work.
I tried it out on a test certificate, and they were right!
-
John Airey, BSc (Jt Hons), CNA, RHCE
Internet systems support officer, ITCSD, Royal National Institute of the
Blind,
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John....@rnib.org.uk
Anyone who believes in Evolution as fact just because they were told so at
school seems to have missed the relevance of the renaissance.
-
NOTICE: The information contained in this email and any attachments is
confidential and may be legally privileged. If you are not the
intended recipient you are hereby notified that you must not use,
disclose, distribute, copy, print or rely on this email's content. If
you are not the intended recipient, please notify the sender
immediately and then delete the email and any attachments from your
system.
RNIB has made strenuous efforts to ensure that emails and any
attachments generated by its staff are free from viruses. However, it
cannot accept any responsibility for any viruses which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent those of RNIB.
RNIB Registered Charity Number: 226227
Website: http://www.rnib.org.uk
Dilkie, Lee
With such a small RSA key, would that restrict the length of the session key you would encrypt? Ie, a 128 bit RSA key cannot encrypt a 128 bit session key and perhaps you'd run into problems when the code tries to make thing fit and they don't. Just a heads-up.
-lee
Dr. Stephen Henson
>
> To answer your other question, I don't believe there are any browsers that
> can accept a RSA key > 1024 bits. I did look into this last year as I was
> creating a new SSL key but was advised by the Thawte representative that
> although I could create a certificate with this size key, it wouldn't work.
> I tried it out on a test certificate, and they were right!
>
What software did you try this on? I've been using 2048 bit RSA keys for some
time with no problems. Many of the root CAs in Netscape and IE use keys > 1024
bits.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: she...@drh-consultancy.demon.co.uk, PGP key: via homepage.
Dr. Stephen Henson
> Also,
>
> With such a small RSA key, would that restrict the length of the session key you would encrypt? Ie, a 128 bit RSA key cannot encrypt a 128 bit session key and perhaps you'd run into problems when the code tries to make thing fit and they don't. Just a heads-up.
>
The session key isn't directly encrypted using SSL/TLS. For the normal RSA
browser suites, including those which use 40 bit keys, a 48 byte pre master
secret is encrypted using the servers key. So if that can't be sent SSL/TLS
wont work.
John....@rnib.org.uk
> From: Dr. Stephen Henson [mailto:st...@openssl.org]
> Sent: 27 March 2003 12:12
> To: openss...@openssl.org
> Subject: Re: Minimum RSA Key length ?
>
>
> On Thu, Mar 27, 2003, John....@rnib.org.uk wrote:
>
> >
> > To answer your other question, I don't believe there are
> any browsers that
> > can accept a RSA key > 1024 bits. I did look into this last
> year as I was
> > creating a new SSL key but was advised by the Thawte
> representative that
> > although I could create a certificate with this size key,
> it wouldn't work.
> > I tried it out on a test certificate, and they were right!
> >
>
> What software did you try this on? I've been using 2048 bit
> RSA keys for some
> time with no problems. Many of the root CAs in Netscape and
> IE use keys > 1024
> bits.
That's a surprise to me then! I think I tried with IE 5.01 and maybe 5.5. At
the time I don't think IE 6 was out (or XP). Looks like I'll have to look
into this again. Thanks for the information.
-
Website: http://www.rnib.org.uk
Charles B Cranston
> ... I don't believe there are any browsers that can accept
> a RSA key > 1024 bits.
Late 2002 I was making the technical decision whether to step up
from our current 1024 bit root to a 2048 bit root. I made such a
root and did some testing. I did not write the results down,
but the best of my memory is that things worked fine back to the
earliest 4.x Netscape we could find, and we decided that support
for Netscape 3 and earlier was not a high priority. I also think
I remember that it worked fine on IE 5 but I don't remember if we
could ever find an IE 4 to test with. (I used to have a 4 on one
of my laptops but one day the innocent act of installing a CD
burner gratuitously "upgraded" it to 5. I hate Windows.)
Oh, and don't forget, the export status (56 vs 128 bit?) of the
browser is an important variable. Seems to me that introducing
a 2048 bit root for a 56 bit browser triggered some extra need for
randomness in the Apache servers, so the ones that did not have
explicit extra randomness (e.g. /dev/urandom) failed to connect
and left log entries saying not enough randomness. If you do get
failures in your testing, please control this variable. I have
this vague memory that Steve straightened this out for me, and I
might be able to find the email somewhere in my 4863 back emails...
===
You might think these are ancient history versions, but the sad
fact is that we in the (second tier?) academic world have a very
long food chain, that is, a single machine is passed from a full
professor to an associate professor to an assistant professor to
a graduate student, and then it passes to an on-campus surplus
unit, from which it can be repurchased by an undergraduate student
organization etc. And, of course, at NO TIME during this process
does any system software ever get upgraded...
This message is being typed on Netscape 4.72 running on a Power
Macintosh 7500/100 with 48MB of main memory.
--
Charles B. (Ben) Cranston
mailto:zb...@umd.edu
http://www.wam.umd.edu/~zben
Dr. Stephen Henson
> John....@rnib.org.uk wrote:
>
> > ... I don't believe there are any browsers that can accept
> > a RSA key > 1024 bits.
>
> Late 2002 I was making the technical decision whether to step up
> from our current 1024 bit root to a 2048 bit root. I made such a
> root and did some testing. I did not write the results down,
> but the best of my memory is that things worked fine back to the
> earliest 4.x Netscape we could find, and we decided that support
> for Netscape 3 and earlier was not a high priority. I also think
> I remember that it worked fine on IE 5 but I don't remember if we
> could ever find an IE 4 to test with. (I used to have a 4 on one
> of my laptops but one day the innocent act of installing a CD
> burner gratuitously "upgraded" it to 5. I hate Windows.)
>
> Oh, and don't forget, the export status (56 vs 128 bit?) of the
> browser is an important variable. Seems to me that introducing
> a 2048 bit root for a 56 bit browser triggered some extra need for
> randomness in the Apache servers, so the ones that did not have
> explicit extra randomness (e.g. /dev/urandom) failed to connect
> and left log entries saying not enough randomness. If you do get
> failures in your testing, please control this variable. I have
> this vague memory that Steve straightened this out for me, and I
> might be able to find the email somewhere in my 4863 back emails...
>
The export status will indeed have some influence on this though. IIRC the
various rules made a distinction between use of RSA for signing and
encryption (key exchange). Larger key lengths were permitted for signing only
but restrictions were in place for those used for encrypt.
MSIE (or more specifically CryptoAPI) has always allowed the use of larger key
lengths for signing only. That might well mean that CA keys > 1024 bits were
OK. However when used for encrypt (e.g. server certs) various restrictions
would force the use of export cipher suites with temporary keys.
There were also two sets of regulations, initially 40bit symmetric and 512 bit
RSA which was later relaxed to 56 bit symmetric and 1024 bit RSA. So an
'export grade' browser might handle 512 bit keys initially then 1024 bit keys
for encryption.
The use of SSLv3 and TLS RSA export cipher suites with a server key above the
limit would require the generation of a temporary RSA key. This would require
a properly seeded PRNG, so this could indeed produce PRNG not seeded errrors
for >512 bit or >1024 bit server keys and export cipher suites.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: she...@drh-consultancy.demon.co.uk, PGP key: via homepage.