I only know some basics about SSL, symmetric keys and asymmetric keys,
and I'd greatly appreciate anyone who can shed some light on this question!

My understanding (and feel free to correct anything below here!) is that
SSL transactions between a web browser and a web server involve first a
handshake, then the actual data transmission. The handshake is handled
by a public/private key pair, then switches over to the symmetric key
(256-bit AES, 162-bit 3DES, or whatever) for the bulk of the data
transmission.

Now, it seems from what I've read that 128-bit symmetric keys are still
considered secure given the current state of computing power, and may
stay that way for a long time. But for asymmetric keys, 1024 bits is
considered by at least some to be getting into the realms of being
feasibly crackable. Longer keys (2048 bit, 3072 bit) are recommended
for data that needs to be protected for years to come.

Now here's where my understanding gets murkier. I can understand what
Firefox tells me when I double-click the "lock" icon on an SSL website
and see that it's offering "High Grade Encryption (RC4 128 bit)" or
"(AES 256 bit)". But what about the public/private key pair that's used
to do the handshaking? Sites like Verisign still recommend that OpenSSL
users use a command similar to this:

> openssl genrsa -des3 -rand file1:file2:...:file5 -out
www.virtualhost.com.key 1024

and old documentation for Apache's mod_ssl seem to indicate that
2048-bit keys aren't (or at least weren't) even supported.
(http://www.modssl.org/docs/2.8/ssl_faq.html#ToC34)

In fact, when I use MSIE to go to big-name sites (Chase Bank, Citi Bank,
RBC Centura), double-click the lock icon, look at the "Details" tab, I
invariably see "Public key: RSA (1024 bits).

So, my questions are:

1) Why isn't everyone using stronger public/private key pairs? Nobody
who seems to offer SSL certs (Verisign, Thawte, GoDaddy, Comodo) tells
their customers to generate 2048-bit keys with OpenSSL. Obviously
they're not worried - why not?

2) Related to that, should I be worried that I'm generating a
public/private keypair for my Apache2/mod_ssl server that's only
1024-bits? Do I even have the OPTION of having a larger/stronger key,
or am I going to hit some weird compatibility problems with modern-day
browsers?

Thanks to anyone who can set me straight!

George Adams wrote:
> Now here's where my understanding gets murkier. I can understand what
> Firefox tells me when I double-click the "lock" icon on an SSL website
> and see that it's offering "High Grade Encryption (RC4 128 bit)" or
> "(AES 256 bit)". But what about the public/private key pair that's used
> to do the handshaking?

It doesnt.
I have reported this issue to Mozilla maybe 8 years ago. Re-reported it
back few years ago and again reported it couple years ago. The people in
Mozilla team are morons who have know understanding about crypto since
they havent bothered to fix this issue.

Currently, you might be going to site which has 256bit AES and 512bit
RSA and you would know the difference since Firefox doesnt tell you the
asymmetric key size. Major bug. Major, major bug indeed.


--
My computer security & privacy related homepage
http://www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email
before sending it to me to protect our privacy.

George Adams wrote:
> I only know some basics about SSL, symmetric keys and asymmetric keys,
> and I'd greatly appreciate anyone who can shed some light on this question!
>
> My understanding (and feel free to correct anything below here!) is that
> SSL transactions between a web browser and a web server involve first a
> handshake, then the actual data transmission. The handshake is handled
> by a public/private key pair, then switches over to the symmetric key
> (256-bit AES, 162-bit 3DES, or whatever) for the bulk of the data
> transmission.
>
> Now, it seems from what I've read that 128-bit symmetric keys are still
> considered secure given the current state of computing power, and may
> stay that way for a long time. But for asymmetric keys, 1024 bits is
> considered by at least some to be getting into the realms of being
> feasibly crackable. Longer keys (2048 bit, 3072 bit) are recommended
> for data that needs to be protected for years to come.

NIST publishes a table of equivalent key strengths for different algorithms.
It is published in various NIST documents, including page 21 of this:
http://csrc.nist.gov/CryptoToolkit/k...es%20(b-w).pdf

It shows that (among other values) 128-bit AES is equivalent to 3k bit RSA
and 256-bit ECC. It also shows that 1k bit RSA is equivalent to 80 bit
symmetric algorithms (such as SkipJack). It predicts that 1k bit RSA
will become "too weak" long before 128-bit AES does.

> Now here's where my understanding gets murkier. [snip]

> In fact, when I use MSIE to go to big-name sites (Chase Bank, Citi Bank,
> RBC Centura), double-click the lock icon, look at the "Details" tab, I
> invariably see "Public key: RSA (1024 bits).
>
> So, my questions are:
>
> 1) Why isn't everyone using stronger public/private key pairs?

Transaction cost.

Doubling the key size increases the computation time by roughly 4x or more.

The cost per transaction is proportional to the system (CPU) time required
to do the transaction, and the system transaction rate capacity (e.g. in
number of transactions per second) is inversely proportional to transaction
time. So, an RSA computation that takes 4x longer to compute costs 4x more
and reduces RSA transaction throughput to x/4.

The single largest impediment to increased use of SSL has been increased
transaction cost (or equivalently, reduced transaction rate per system,
reduced transaction rate per dollar of system cost) as compared to cost
of non-SSL transactions. SSL server owners want maximum transaction rate
capacity for maximum cost efficiency.

> Nobody who seems to offer SSL certs (Verisign, Thawte, GoDaddy, Comodo)
> tells their customers to generate 2048-bit keys with OpenSSL.
> Obviously they're not worried - why not?

If they raise their minimum key sizes, they will lose business, because
some prospective customers will decide the resultant SSL transaction cost
is too high.

And when the public finally perceives that 1024 bit RSA keys are too weak,
the Certificate Authorities will be happy to sell new certificates to the
server operators that want them.

Most certificates issued now have a maximum validity period of just a year
or two, meaning that new certs will be issued every year or two. So there
will be plenty of opportunity to issue certs with larger keys in due course.

> 2) Related to that, should I be worried that I'm generating a
> public/private keypair for my Apache2/mod_ssl server that's only
> 1024-bits?

Depends on the lifetime of the value of the information you're protecting.
You may also want to consider using SSL/TLS's Ephemeral Diffie-Hellman
cipher suites for "perfect forward secrecy".

> Do I even have the OPTION of having a larger/stronger key,
> or am I going to hit some weird compatibility problems with modern-day
> browsers?

Modern browsers can handle much larger keys than they typically do.

Also, the browser vendors are (nearly) all working on implementing and
interoperability testing of ECC cryptography for SSL/TLS, ala RFC 4492.
This is predicted to eventually supplant RSA, as much smaller ECC keys
have equivalent strength to larger RSA keys, and should have lower
computational costs. So, before the time that people shift to 3K bit
RSA keys, I expect they will shift to 256-bit ECC keys.

> Thanks to anyone who can set me straight!

Hope this answer s.
--
Nelson B (co-author: RFC 4492 and mozilla's crypto libraries)

Nelson B wrote:

> You may also want to consider using SSL/TLS's Ephemeral Diffie-Hellman
> cipher suites for "perfect forward secrecy".

Eh???


--
Peter Fairbrother

Nelson B <NOnelsonSPAM@NObolyardSPAM.com> writes:
> The single largest impediment to increased use of SSL has been increased
> transaction cost (or equivalently, reduced transaction rate per system,
> reduced transaction rate per dollar of system cost) as compared to cost
> of non-SSL transactions. SSL server owners want maximum transaction rate
> capacity for maximum cost efficiency.

SSL domain name certificates were to provide that the server domain
name in the URL you typed in matched the domain name in the digital
certificate provided by the server (i.e. the server you thot you were
talking to was actually the server you were talking to) ... basically
the browser verified the certificate and then compared the domain name
from the URL you typed/provided with the domain name in the
certificate.

original e-commerce scenario was that SSL bracketed your whole session
with the server ... from the initial connection, thru shopping and
checkout. however, most e-commerce servers quickly found out that
running SSL for the whole shopping experience dropped thru thruput by
80-90 percent ... and so most of them dropped SSL back to just being
used for the payment process. Now you typically click on a payment
button ... where the server provides the SSL URL ... and then the
browser checks the domain name in the URL provided by the server
against the URL in the certificate provided by the server (no longer
is the process verifying that the server is the server you thot it
was, but SSL is now verifying that the domain name that the server
claims to be is the domain name that the server claims to be).

the original theory of digital certificates is that domain name that
you provided matches the domain name in the provided digital
certificate as a countermeasure to things like man-in-the-middle
attacks. however, if the server is providing both the URL (and
therefor the domain name) as well as the digital certificate ... it is
no longer a countermeasure to man-in-the-middle attacks ... and
therefor becomes redundant and superfluous. the server might just as
well as be directly transmitting its public key ... with none of the
PKI and digital certificate armoring. misc. past posts mentioning
MITM-attacks
http://www.garlic.com/~lynn/subpubkey.html#mitm

i claim to be some arbitrary entity ... and then provide a digital
certificate that confirms that i'm whoever it is that i claim to be.
the current browser and end-user don't typically look at whoever it is
that I claim to be ... the infrastructure is just relying on the
browser to confirm that I have any digital certificate that supports
whatever claim that i happen to be making.

misc. past posts mentioning various ssl certificate subjects
http://www.garlic.com/~lynn/subpubkey.html#sslcert

past mention of being asked to consult with this small client/server
startup that wanted to do payments on their server ... and wanted to
have something that came to be called a payment gateway ... and had
this technology called ssl
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

so another issue related to ssl domain name certificates was that when
an entity applies to a certification authority for a ssl domain name
certificate ... the certification authority requires a lot of
identification information. they then check with the authoritative
agency responsible for domain name owners ... the domain name
infrastructure ... for identification information about the domain
name owner. they then try and determine if the identification
information on file with the domain name infrastructure appears to map
to the same entity as the identification informaton provided by the
ssl domain name certificate applicant.

there has been some concern as to possible compromises in the identity
information on file with the trust root for domain name ownership
.... the domain name infrastructure. so a proposal somewhat backed by
the certification authority industry is to have domain name owners
register a public key at the same time as they register their domain
name. then the certification authority industry can request that ssl
domain name certificate applications be digitally signed. then the
certification authority can change from an expensive, time-consuming
and error-prone identification process to a much less expensive and
efficient authentication process by retrieving the public key from the
domain name infrastructure to verify the digital signature on the ssl
domain name certificate application.

the problem is that this then represents something of a catch22 for
the certification authority industry, if they can directly retrieve
the onfile public key from the domain name trust root for
authentication purposes ... then it is possible that others could
also.

a radically simplified ssl setup protocol could involve DNS requests
(for domain name to ip-address translation) to piggy back (in the
response) any available public key and any crypto options. then the
client-to-server connection could have the client initially generating
a random ssl session key, encrypting the data with the session key,
and encrypting the session key with the (servers) public key. the
server demonstrates that they have the corresponding private key by a
correct encrypted response (eliminating all the ssl domain name
certificate operations and all the ssl protocol setup chatter)

recent thread in some crypto mailing list discussing radically simplified
SSL based on using onfile public keys at the domain name infrastructure
http://www.garlic.com/~lynn/aadsm25.htm#17
http://www.garlic.com/~lynn/aadsm25.htm#19
http://www.garlic.com/~lynn/aadsm25.htm#22

w/o needing digital certificates ... misc. past posts mentioning
various public key operations w/o requiring digital certificates
.... including real-time, onfile public key implementations:
http://www.garlic.com/~lynn/subpubkey.html#certless

Anne & Lynn Wheeler <lynn@garlic.com> writes:
> past mention of being asked to consult with this small client/server
> startup that wanted to do payments on their server ... and wanted to
> have something that came to be called a payment gateway ... and had
> this technology called ssl
> http://www.garlic.com/~lynn/aadsm5.htm#asrn2
> http://www.garlic.com/~lynn/aadsm5.htm#asrn3

during this period we had coined the term certificate manufacturing to
distinguish the majority of ssl domain name certificate operation
(primarily supporting e-commerce operations) ... from what was
typically defined as PKI.

shortly after the work this payment gateway and e-commerce work in the
mid-90s ... we also got involved in the x9a10 financial standard
working group. the primary purpose of the dominate use of ssl
e-commerce is hiding account numbers ... since just having knowledge
of the account number can enable fraudulent transactions.

the x9a10 financial standard working group had been given the
requirement to preserve the integrity of the financial infrastructure
for all retail payments (debit, credit, stored-value, internet,
point-of-sale, etc ... i.e. ALL). this was when we started to observe
that account numbers were required in scores of business processes and
even if the planet was be buried under miles of crypto used to hide
account numbers, it still wouldn't prevent account number leakage (and
the resulting account fraud).

so the resulting x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

specified authenticating the transaction (on end-to-end basis) along
with a business rule that account numbers used in x9.59 transactions
couldn't be used in non-authenticated transactions. this was
countermeasure to account fraud replay attacks ... where simple
knowledge of the account number could result in fraudulent
transactions. past post discussing some of the issues of protecting
account number used in scores of business processes
http://www.garlic.com/~lynn/2001h.html#61

with countermeasure to fraudulent transactions based on simply knowing
the account number ... it is no longer required to hide the account
number (in order to prevent such fraudulent transactions).

so while the previous post
http://www.garlic.com/~lynn/2006p.html#7 SSL, Apache 2 and RSA key sizes

discusses a drastically simplified SSL protocol ... while x9.59
eliminates the requirement for the dominate use of SSL protocol for
e-commerce purposes ... the hiding of account numbers as a
countermeasure to fraudulent transactions (i.e. hiding the account
number was no longer necessary as a countermeasure to account fraud).

somewhat related recent blog thread discussing issues of having
limited scope hiding paradigms as a countermeasure to account fraud
.... as opposed to strongly authenticated end-to-end transaction as a
countermeasure to account fraud.
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked

http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers

Nelson, thanks for the useful information. I guess that more or less
confirms what I thought - the continued use of 1024-bit keys isn't
because it's more secure than I thought (it's really reaching
end-of-life according to that NIST documentation), but that there are
other factors that have prevented a wholesale switchover to, say,
2048-bit RSA keys.

One followup question, though, related to this:

>> 1) Why isn't everyone using stronger public/private key pairs?
>
> Transaction cost.
>
> Doubling the key size increases the computation
> time by roughly 4x or more.

I could be wrong, but I thought that the public-key portion of SSL was
only used at the beginning of the session, and only long enough for the
client and server to agree on a symmetric key to use for the session.
Once that was done, I thought that any remaining SSL activity took place
using the (much faster) symmetric key.

If that's true, then shouldn't the performance hit that results from
using a bigger public key only happen ONCE, right at the beginning of
the session? And once that's done, shouldn't the rest of the SSL
session be just as fast as usual? I guess I didn't think it would be
all that inconvenient to have a brief slowdown just for a second or two
at the start of the SSL connection, as long as everything else sped
along nicely after that.

> Depends on the lifetime of the value of the information you're
> protecting. You may also want to consider using SSL/TLS's Ephemeral
> Diffie-Hellman cipher suites for "perfect forward secrecy".

Can you explain that a bit more? I'm not familiar with how that would
be implemented.

Thanks again.


Nelson B wrote:
> George Adams wrote:
>> I only know some basics about SSL, symmetric keys and asymmetric keys,
>> and I'd greatly appreciate anyone who can shed some light on this question!
>>
>> My understanding (and feel free to correct anything below here!) is that
>> SSL transactions between a web browser and a web server involve first a
>> handshake, then the actual data transmission. The handshake is handled
>> by a public/private key pair, then switches over to the symmetric key
>> (256-bit AES, 162-bit 3DES, or whatever) for the bulk of the data
>> transmission.
>>
>> Now, it seems from what I've read that 128-bit symmetric keys are still
>> considered secure given the current state of computing power, and may
>> stay that way for a long time. But for asymmetric keys, 1024 bits is
>> considered by at least some to be getting into the realms of being
>> feasibly crackable. Longer keys (2048 bit, 3072 bit) are recommended
>> for data that needs to be protected for years to come.
>
> NIST publishes a table of equivalent key strengths for different algorithms.
> It is published in various NIST documents, including page 21 of this:
> http://csrc.nist.gov/CryptoToolkit/k...es%20(b-w).pdf
>
> It shows that (among other values) 128-bit AES is equivalent to 3k bit RSA
> and 256-bit ECC. It also shows that 1k bit RSA is equivalent to 80 bit
> symmetric algorithms (such as SkipJack). It predicts that 1k bit RSA
> will become "too weak" long before 128-bit AES does.
>
>> Now here's where my understanding gets murkier. [snip]
>
>> In fact, when I use MSIE to go to big-name sites (Chase Bank, Citi Bank,
>> RBC Centura), double-click the lock icon, look at the "Details" tab, I
>> invariably see "Public key: RSA (1024 bits).
>>
>> So, my questions are:
>>

>
> The cost per transaction is proportional to the system (CPU) time required
> to do the transaction, and the system transaction rate capacity (e.g. in
> number of transactions per second) is inversely proportional to transaction
> time. So, an RSA computation that takes 4x longer to compute costs 4x more
> and reduces RSA transaction throughput to x/4.
>
> The single largest impediment to increased use of SSL has been increased
> transaction cost (or equivalently, reduced transaction rate per system,
> reduced transaction rate per dollar of system cost) as compared to cost
> of non-SSL transactions. SSL server owners want maximum transaction rate
> capacity for maximum cost efficiency.
>
>> Nobody who seems to offer SSL certs (Verisign, Thawte, GoDaddy, Comodo)
>> tells their customers to generate 2048-bit keys with OpenSSL.
>> Obviously they're not worried - why not?
>
> If they raise their minimum key sizes, they will lose business, because
> some prospective customers will decide the resultant SSL transaction cost
> is too high.
>
> And when the public finally perceives that 1024 bit RSA keys are too weak,
> the Certificate Authorities will be happy to sell new certificates to the
> server operators that want them.
>
> Most certificates issued now have a maximum validity period of just a year
> or two, meaning that new certs will be issued every year or two. So there
> will be plenty of opportunity to issue certs with larger keys in due course.
>
>> 2) Related to that, should I be worried that I'm generating a
>> public/private keypair for my Apache2/mod_ssl server that's only
>> 1024-bits?
>
> Depends on the lifetime of the value of the information you're protecting.
> You may also want to consider using SSL/TLS's Ephemeral Diffie-Hellman
> cipher suites for "perfect forward secrecy".
>
>> Do I even have the OPTION of having a larger/stronger key,
>> or am I going to hit some weird compatibility problems with modern-day
>> browsers?
>
> Modern browsers can handle much larger keys than they typically do.
>
> Also, the browser vendors are (nearly) all working on implementing and
> interoperability testing of ECC cryptography for SSL/TLS, ala RFC 4492.
> This is predicted to eventually supplant RSA, as much smaller ECC keys
> have equivalent strength to larger RSA keys, and should have lower
> computational costs. So, before the time that people shift to 3K bit
> RSA keys, I expect they will shift to 256-bit ECC keys.
>
>> Thanks to anyone who can set me straight!
>
> Hope this answer s.

George Adams wrote:

>>> 1) Why isn't everyone using stronger public/private key pairs?
>>
>> Transaction cost.
>>
>> Doubling the key size increases the computation
>> time by roughly 4x or more.
>
> I could be wrong, but I thought that the public-key portion of SSL was
> only used at the beginning of the session, and only long enough for the
> client and server to agree on a symmetric key to use for the session.
> Once that was done, I thought that any remaining SSL activity took place
> using the (much faster) symmetric key.
>
> If that's true, then shouldn't the performance hit that results from
> using a bigger public key only happen ONCE, right at the beginning of
> the session? And once that's done, shouldn't the rest of the SSL
> session be just as fast as usual? I guess I didn't think it would be
> all that inconvenient to have a brief slowdown just for a second or two
> at the start of the SSL connection, as long as everything else sped
> along nicely after that.

Yes.

The bottleneck is in the server doing lots of RSA calculations though, not
in the user's computer.

>> Depends on the lifetime of the value of the information you're
>> protecting. You may also want to consider using SSL/TLS's Ephemeral
>> Diffie-Hellman cipher suites for "perfect forward secrecy".
>
> Can you explain that a bit more? I'm not familiar with how that would
> be implemented.

In the typical authenticated-server/unauthenticated-client mode used in 'net
commerce, SSL/TLS usually does "RSA key exchange". Very much simplified, the
client sends the server a randomly generated key encrypted with the server's
RSA key, which is then hashed to give the session key for the symmetric
cipher, almost invariably RC4.

Sometimes servers use RSA key-exchange keys only once and then discard them,
signing each new RSA key-exchange key with their RSA signature key, but not
often. They will typically reuse the same RSA key-exchange key a lot,
sometimes even using the same RSA key for both key-exchange and signature
functions (bad).

Anyone who gets the secret RSA key-exchange key can read earlier exchanges
where the same key has been used.



TLS/SSL can instead do a "DH key exchange" to create an ephemeral session
key. The server side of the exchange is typically authenticated by an RSA
signature.

DSA can also be used to authenticate the server instead of RSA, in which
case DH is always done. Some implementations, eg OpenSSL, default to DH only
operation, but while DH is used it is not all that common. Also the primes
used are often too small for real security.



In DH the math etc is all done mod p, a large publicly-known prime:

Alice and Bob create random secrets, A and B. They exponentiate a
publicly-known generator g of Zp* to their own secret value, and exchange
the calculated values g^A and g^B.

The key is created by exponentiating the received value to the secret value
- eg Alice gets g^B from Bob and calculates (g^B)^A using her previously
generated secret A.

By a bit of math magic both parties come up with the same number, as (g^A)^B
= (g^B)^A.



As you can see DH is not strictly an exchange of a key, rather a mutual
secret generation of a sort-of-random shared key. Another property of DH is
that properly done neither party (or even two colluding parties) can force
any property on what the eventual key will be.

An observer can't calculate what the key generated is, as he sees only p, g,
g^A and g^B, not the secrets A and B - the exponentiation operation cannot
be easily reversed to give A or B in order for an attacker to calculate the
key (the reverse operation is known as finding discreet logarithms, and is
thought to be a hard problem).

Done right with a large enough safe prime p, once the secrets and the key
are deleted, that's it - from that point in time the key cannot be recovered
even if everybody involved wants to recover it, giving forward secrecy -
past communications cannot be read even if eg the RSA keys used to sign are
available.



It isn't "perfect" forward secrecy though, that's slightly different, only a
one-time-pad gives that.




--
Peter Fairbrother