Slashdot Mirror

Symmetric and asymmetric keys are different things and have different key lengths. One cannot directly compare key sizes between two wholly different classes of ciphers. There are numerous reasons, mostly involving arcane mathematics, why asymmetric ciphers require longer key lengths than symmetric ciphers to offer similar levels of protection.

For example, a 1024-bit RSA key (RSA is an asymmetric cipher) is essentially equivalent to an 80-bit symmetric key (AES, 3DES, etc. are symmetric ciphers). SHA1, a hashing algorithm, provides less than 80 bits of security; those wishing stronger signatures are switching to SHA-256 (which offers 128 bits of security) and SHA-512 (which offers 256 bits).

A 2048-bit RSA key, such as those used by most CAs and web servers these days, has the same strength as a 112-bit symmetric key. NIST says they should be good enough until around 2030.

3072-bit RSA keys offer the same strength as a 128-bit symmetric key. A whopping 15,360-bit RSA key would be needed for 256-bit security; the same level of security could be achieved with a 512-bit elliptic curve key, which would be much, much faster than such a large RSA key.

That's a good question. I will attempt to answer it, with the caveat that I'm also not a crypto expert.

Most of the relatively shorter key lengths you see these days, such as 128-bit and 256-bit refer to symmetric encryption algorithms like AES. At this point in time, such keylengths are secure for the foreseeable future. These algorithms tend to be quite fast (AES has hardware-acceleration in many CPUs, which can encrypt or decrypt data at 1GB+/sec in some cases, and around 300MB/sec on many non-accelerated CPUs), but require that both parties exchanging encrypted data share the same key. (Hence the name "symmetric" -- the same key is used for encrypting and decrypting.)

The two parties could previous exchange a shared symmetric key by means of a trusted channel, like a trusted courier, or meeting in person. This can be extremely difficult in the real-world, though.

The longer-length keys you often see (1024-bit, 2048-bit, 4096-bit and, in the case mentioned in the article, the not-very-secure-at-all 512-bit length) are "asymmetric" keys -- when they're created, one creates a "public key" and a "private key" that are linked a certain mathematical way. The public key can be distributed widely, while the private key must be kept secret. If Alice wants to send Bob a secure message, she can encrypt it with Bob's public key, but the message can only be decrypted with Bob's private key -- even if someone intercepts the encrypted message and has Bob's public key, they are unable to decrypt it.

Asymmetric encryption is extremely slow, relative to symmetric encryption (I seem to recall reading that they're about a thousand times slower). Sending large amounts of data over secure connections would be extremely slow. Fortunately, modern cryptosystems use a hybrid model: they use asymmetric keys to exchange a shared secret key that is then used for faster symmetric encryption -- this allows for quick symmetric encryption methods to be used by solving the problem of exchanging the symmetric key without needing to meet in person.

SSL, for example, uses such a method. A simplified description follows: when your browser connects to a secure website the server sends you its public key (which has been digitally signed by a certificate authority who vouches for the identity of the server). Your browser checks the signature to make sure it's actually been issued by the authority and, if it checks out, creates a random symmetric key, encrypts it with the server's public key and sends it to the server. The server decrypts the symmetric key with its private key. Both client and server then encrypt all future communications with the symmetric key.

Because asymmetric and symmetric encryption keys use entirely different mathematical methods to secure data, their keylengths aren't directly comparable. According to NIST, a 3072-bit asymmetric key is about as strong as a 128-bit symmetric key.

See and for more details.

You might want to have a look at http://www.keylength.com/ (overview of all 'official' recommendations regarding protocols and minimal keylengths).

If you work for banks: take into account the Payment Card Industry standard (https://www.pcisecuritystandards.org/ - strictly speeking only valid for credit card handling systems) and look at national compliancy requirements ...

The certs from StartCom are whatever you generate for them to sign. Last year they accepted 1024 bit RSA and 2048 bit RSA. LIke the rest of the SSL vendors, in 2011 only 2048 bit RSA certs are allowed for issuance, and full transition to 2048 only certs by 2013.

Secondly, the 128 or 256 bit symmetric crypto has nothing to do with the SSL cert or provider, that's software settings on the host. 128 bit AES is widely considered secure against attacks for the next 20 years or so, and 256 bit should be secure for the as far into the future as we can guess. http://www.keylength.com/

The (in)security I refer to has to do with the level of checking into who you are. Basically, they just send an email to administrator type address at the site you want a cert for, and if you get the email you are assumed to be the admin. This can be attacked easily through DNS flaws or just signing up for a webmail account with an address that the SSL provider thinks sounds like an admin account. This happened to many of the large webmail providers before they started blocking the common admin accounts for registration.

XKCD was right. The common attacks are against the humans who run your DNS or mail providers, not that the crypto is weak.
http://xkcd.com/538/

Non-sense.

First 128 bit keys were always too short for RSA keys, that's for symmetric keys.
2048 bit is far from standard, just take a look at your browsers certificate store and especially the certificates of many sites.
2048 bit is far from being broken. Although the security of RSA is non-linear with key-length, breaking 2048 bits is way way more difficult than breaking 1024 bit keys.
4096 bit is more than enough for "Long-term protection: Generic application-independent recommendation, protection from 2009 to 2040" according to eCrypt II (see link below).
16Kib is longer than the recommendation against "quantum computers", by which they don't mean 4 qubit quantum machines that can break 2x2 sudoku's, and then it would make much more sense to switch to Elliptic Curve Cryptography anyway (if Microsoft ever upgrades their crypto libs to fully support ECC instead of a limited set of NIST curves of course).

For a better description of key sizes and their estimated security please take a look at http://www.keylength.com/ .

Mods, this is a rather obvious troll, please mod parent DOWN.

"Adequate" is a moving target. To hit a moving target, you aim for where the target will be, not where it is now.

Processors are getting cheaper, thousand node botnets aren't unheard of. That's today. My guts are telling me we hear about some brilliant new attack on RSA or similar algorithm every 8 months, which cuts the time to solve by 90%.

Back in the olden days, people thought that 56bit DES was hot stuff (they were wrong). Processors are now measured in Gigahertz instead of Megahertz - 3 orders of magnitude. Multiply that by the number of cores - 4 in a desktop is pretty common, 12 in a server isn't ridiculous - and that server, which would have classed as a "supercomputer" 15 years ago is now only $5000 - there's a lot of horsepower. Now we're thinking that 2 more orders of magnitude on the keylength is going to save us? (see below)

Who knows what tomorrow will bring?

(the below part: I know that key complexity isn't linear. I also know that brute force attacks aren't getting more expensive, and that the only defense is to make recovery prohibitively expensive for an attacker - that the data they get won't be useful after the time they spent getting it. I also feel just a bit justified for saying 16kbit - since our friends linked in TFS are saying 15kbit.)

TLDR: Ridiculously longer keys are probably smart.

You are looking for a realistic keylength? Well, let's guess (first google hit): Keylength.com. Only it seems to be down at this time. Too many slashdot hits I suppose. Anyway, you can look through the NIST or ECRYPT documents, but they are not written for mere uninformed human creatures. The best bit of information is table 4 in the NIST document (warning, in PDF format).

have a look at this http://www.keylength.com/index.php

and please stop spreading fud

http://www.keylength.com/ has sound information about how long a key needs to be to resist brute force attacks.

There will be a different key for each phone call so if it takes a cluster of supercomputers for ten years to guess a key [hypothetical example, it will actually be more], then they'll have to run for another decade to listen to the next call.

Much more practical for an eavesdropper is traffic analysis. Bunch of evening and late night calls to a particular number? Followed by the guy's phone being in range of a foreign cell all night? Number belongs to a single woman? Now you know he's having an affair without decrypting a single call. You're a government official and news of your crimes appears on ABC? See who's calling the journalists. Regular calls to AA? Great for campaign smear tactics.

Here is a very useful site, listing estimates of how long various algorithms will be secure, and at what key sizes. It covers public- and secret-key algorithms, as well as hashes.

http://www.keylength.com/