Skip navigation.

exploreopera

| Help

Sign up | Help

Implementer's notes

What might get caught in the gears under the hood?

Posts tagged with "factorization"

(51)2-bit banks

, , , ...

It shouldn't come as a surprise to anyone who is familiar with my opinions on encryption strength that I do not hold 512 bit RSA encryption keys in high regard. To put it mildly.

Unfortunately, I continue to be disappointed by the many sites using such weak keys. But I am even more disappointed by the fact that it turns out there are banks that are still using these keys.

Recently I have become aware of two banks/financial services that are using such weak keys:



Both of these sites are, as of June 15th, 2007, still using 512 bit RSA keys, and have been doing so for about a year, at least.

I have tried to contact these banks yesterday evening and today, but have so far gotten no response (and I also had trouble submitting the comments to the Israeli bank), and to Amazon UK, who answered quickly that they would forward the information internally.

The problem with 512 bit RSA keys is that an attacker, using (almost literally) a handful of computers, can break them in a couple of weeks, at most.

And when an RSA key is broken the attacker can do a lot of things:

  • He can read all previous traffic with the site if he have recorded it (if the site uses Ephemeral Diffie-Hellman keys, then those keys must be broken instead).
  • If he is able to intercept current traffic to the site, he can pretend to be the site and read all the data passing back and forth between the site and the users.
  • If he is able to pretend to be the site, he can also change the information on the fly, if he wants too.


There is absolutely no way to detect any of these attacks through the SSL/TLS protocol, because the sanctity of the site's secret private key is the fundamental pillar of the protocol. That key is used to agree upon the encryption keys that are used to protect the rest of the
communication.

10 years ago, 512 bit RSA was the highest level of encryption the US government permitted foreign users of US manufactured servers and browsers to use, except for financial services, who could use 1024 bit RSA keys, or better. It was widely assumed that the reason for this limit was that the US government could break 512 bit RSA keys relatively fast. The restriction was lifted in 1999/2000.

The proficiency of RSA key breaking is, as I mentioned a couple of weeks ago, rapidly increasing. At present general 640 bit RSA keys can be broken in 5 months using just 100 computers. But recently a special 1020 bit number was factored (the difficulty of factoring large numbers is what provides RSA with its security) in about 11 months using the same amount of computing power. That means that 1024 bit RSA keys are fast approaching their "consume by" date, if it hasn't already been passed.

Today, I would strongly recommend that secure websites, in particular financial sites, should use 2048 bit RSA keys.

The days of 1024 bit RSA keys are numbered: 1296 days, at most. (See the countdown for the up to date number, on the frontpage).



Update, June 18: Halifax has responded that they are in the process of upgrading the server certificate.

1020 bit special number factored

, , , ...

Earlier this week news arrived about the successful factoring of a 1020 bit (307 digit) number using just 11 months and about 100 computers to perform the necessary calculations.

The number that was factored is a specially structured number, meaning that it was much easier to factor than a general number of the same size. The largest general factorings accomplished so far are 640 and 663 bits. Both were announced last year.

This is important because the difficulty of factoring a large number determines the security of the RSA encryption method, one of the primary supporting pillars of SSL/TLS, as well as PGP and S/MIME, as they are used today. If the RSA key used by a site is broken, an attacker can not just read all communcation with the site protected by that key, he can also impersonate the site from then on, and he would be able to read all communication with the site that was ever protected by that key, assuming he had archived them.

At present there is no immediate danger that an attacker can break a 1024 bit key, the keylength used by most website certificates (and also CAs) at present. However, like what has been happening to SHA-1 which is another cornerstone of SSL/TLS, this is a warning shot across the bow of the world's 1024 bit RSA keys. Within a few years (it could be 3-4 years, or it could be 10 or more) it is quite likely that the methods used will dramatically reduce the security of 1024 bit RSA keys.

There is currently no indication that RSA itself is broken, but as computation power increases and factorization methods improve this will change the properties of which RSA keys can be considered secure. 10 years ago 768 bits were considered reasonably secure, that limit was later raised to 1024 bits, now it is time to raise the limit even further.

Effects for Opera

I have already taken steps to increase the default length of client certificate keys generated by Opera to 1536 bits.

We are also considering changing the default value of opera:config#SecurityPrefs|MinimumSecurityLevel from "0" to "1". This would raise the lower limit of what is Level 3 (L3) security for RSA from 1000 bits to at least 1020 bits (For settings "0"-"3" Level 1 security is everything below 900 bits).

The consequence of such a change is that sites using certificates issued by at least one root (that was issued with a 1000 bit key) would lose the padlock, as they would be classified as having Level 2 security. We haven't made a decision on this yet, because we first need to find out how problematic the change would be.

Within a few years, probably between 2009 and 2012 (depending on what happens on the factorization front), it is likely that this preference will be raised to "2" (L3 = 1100 bits) or "3" (L3 = 1200 bits).

And before somebody asks: Yes, I am investigating Elliptic Curve Cryptography (ECC). But before it can be implemented and released in a public version, there are still several legal requirements that have to be met.

Last week I also suggested to the W3C's Web Security Context (WSC) group that browsers should not consider a connection secure (and show a padlock) unless the encryption keys used to protect the communication was 232 (4 billion) times more difficult to break than what can reasonably be broken in one year using currently known methods and technology. The other members of WSC has not yet considered my suggestions.

Such a rule will ensure that, short of revolutionary leaps in technology and/or methods (such as a complete solution of the factoring problem), not even enormous amounts of money can compromise the keys by brute-force computation (if somebody is that interested in some piece of informaiton there are other, less expensive, ways to get hold of the key, such as "buying" it, although that would reveal the interest).

Given the current state of the art, this proposed rule puts 1024 bit RSA in the unsafe zone.

General effects

My recommendation to the world's RSA users would be to use longer keys, at least 1536 bits ( only if performance is an issue), but preferably 2048 bits, and get their certificates issued from Certificate Authorities (CAs) using keys that are at least 2048 bit long (ask the CA if you are not sure).

Thanks to Bruce Schneier for the first post. Bruce also says: "I hope[d] RSA applications would have moved away from 1024-bit security years ago, but for those who haven't yet: wake up."

Thanks also to Eric Rescorla.

See also http://en.wikipedia.org/wiki/RSA_Factoring_Challenge for more on factoring big numbers
September 2008
SMTWTFS
August 2008October 2008
123456
78910111213
14151617181920
21222324252627
282930