14

Most of the banks use a 128-bit or 256-bit encryption. What does this mean? Does it mean that the keys used in SSL are 128-bit long or what?

If they are the SSL key lengths then 128 bit RSA keys are easy to decrypt. The rsa site itself recommends keys having length of 1024 bits or more.

RoraΖ
  • 12,317
  • 4
  • 51
  • 83
Ashwin
  • 1,607
  • 3
  • 18
  • 25

5 Answers5

23

You can pretty much ignore the statements about 128 and 256 bits. It is a marketing statement intended to sound impressive, but really it just means that they are using SSL in a not-totally-stupid way.

(It means the symmetric-key cipher is using a 128-bit or 256-bit key. This ensures that the symmetric cipher is not the weakest link in the chain. However since the symmetric cipher is not the weakest link in the chain, the risks will be primarily elsewhere, so you shouldn't get too caught up in the meaning of 128- or 256-bit strength. This just means that they haven't chosen a stupid configuration that makes the symmetric key readily breakable. It does not mean that the RSA key is 128 bits or 256 bits; as you say, a 128-bit or 256-bit RSA key would be totally insecure.)

There is a lot written about this topic on this site. I suggest you read Is visiting HTTPS websites on a public hotspot secure?. Also see the blog entry QotW #3: Does an established SSL connection mean a line is really secure?. And read Is accessing bank account on the internet really secure? and Does an established ssl connection mean a line is really secure. Doing a search on this site will find lots of information -- give it a try!

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • Thank you:) this is what I wnated to know. I will go through the links that you have provided. – Ashwin Apr 11 '12 at 04:11
  • But, why is there a need to use a symetric key. When the data itself can be ncrypted suing the server's public key. In case of user authentication, only the username and password are are needed which is not very long and can be emcrypted directly using a 2048 bit rsa key(with 2048 bit key you can directly encrypt data upto 256 bytes.) – Ashwin Apr 11 '12 at 04:26
  • 1
    @Ashwin, see [symmetric encryption session keys in SSL/TLS](http://security.stackexchange.com/q/3657/971) for the explanation: it is because symmetric-key cryptography is much faster, so SSL uses the (slow) public-key cryptography to establish a symmetric key, and then everything can subsequently be encrypted using the (fast) symmetric-key cryptography. I encourage you to search and read other posts here -- there's lots of information available! – D.W. Apr 11 '12 at 04:43
  • It's not just a marketing statement, key lengths are important, but so is implementation Always let browser tell you rather than what banks marketers advertise. – ewanm89 Apr 12 '12 at 12:57
9

Asymmetric key length (like in RSA) and cipher key length (like in AES, RC4) are quite different. RSA keys used in public-private asymmetric cryptography should be 1024-bits or greater. AES, RC4 and other cipher keys should be 128 bits or greater. What's the difference? RSA widely let's everyone know the public key N and e, where N is the product of two large prime numbers. If you can factor the composite number N you can derive the private key and decrypt any message encrypted with the public key.

Factoring is a hard problem that cannot be done in polynomial time on a non-quantum computer, but there are tricks from number theory to factor numbers better than naive brute force. Trivially when looking for factors of N, rather than trying every integer between 1 and N, you could skip all the even numbers except 2, or try dividing by only prime factors or stop when you reach sqrt(N), rather than trying to divide by every factor between 1 and N. In the real world techniques like elliptic curve method can factor ~260-bit composite numbers in a couple minutes on one cpu.

AES and RC4 on the other hand are symmetric ciphers. They just need some random number key to decrypt a message. So to brute-force a 128 bit cipher key you have to try most of the 2128 ~ 1038 different keys until you found the one that worked. So if you can check a trillion (10^12) keys per second it would take ~10^19 years before you've checked most of the keys. Note a 256-bit key would be 2^128 times harder to brute-force (take 10^57 years).

So when I log into a banking site and click on the https information in google-chrome I see:

Your connection to home.ingdirect.com is encrypted with 128-bit encryption.

The connection uses TLS 1.0.

The connection is encrypted using RC4_128, with MD5 for message authentication and RSA as the key exchange mechanism.

If I then click on the detailed certificate information, and go to the certificate field "Subject's Public Key" I see that they use a 2048-bit modulus (N the modulus of two large prime numbers).

Community
  • 1
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • So the 128 nit encryption is the key for aes encryption but for key exchange 2048 bit rsa key is used right? – Ashwin Apr 11 '12 at 04:08
  • But, why is there a need to use a symetric key. When the data itself can be ncrypted suing the server's public key. In case of user authentication, only the username and password are are needed which is not very long and can be emcrypted directly using a 2048 bit rsa key(with 2048 bit key you can directly encrypt data upto 256 bytes.) – Ashwin Apr 11 '12 at 04:26
  • P.S. @Ashwin, Please don't post the same comment multiple times under different answers. – D.W. Apr 11 '12 at 04:45
  • @D.W. : I posted the same question multiple times in hope that atleast someone will answer. – Ashwin Apr 11 '12 at 08:27
  • @Ashwin, yes, I know that's why you did it, but that's not the point. I am explaining that posting the same question multiple times is not appropriate on this site. Please don't. – D.W. Apr 11 '12 at 09:30
  • @D.W. : okay dude.. just chill:) – Ashwin Apr 11 '12 at 09:34
  • 3
    @Ashwin - As D.W. said, asymmetric cryptography is roughly 10000 times slower/more CPU intensive than using a block cipher. So it makes sense to only transfer enough info to then use the much faster key. – dr jimbob Apr 11 '12 at 14:30
  • 1
    RC4, not AES in this particular case, but past the particular symmetric algorithm used.. – ewanm89 Apr 12 '12 at 12:54
  • 1
    @drjimbob not to mention key generation, we only use likely primes not guaranteed primes cause of that one :/ – ewanm89 Apr 12 '12 at 12:55
  • 1
    @ewanm89 - Yes, we only use likely primes -- but with astronomical odds they actually are prime. With random entropy input the chance of getting a [false positive prime in openssl with default settings is 1 in ~2^80 ~ 10^24](http://www.openssl.org/docs/crypto/BN_generate_prime.html) So until you check about ~10^23 numbers for primality with overwhelming odds you can assume your numbers are truly prime. E.g., if you check a billion potential primes a second, it will take ~10 million years before you are likely to have a false positive prime in your keypair. Edited for RC4/AES mixup. – dr jimbob Apr 12 '12 at 15:23
  • yeah, just pointing out that bit is also slow. – ewanm89 Apr 12 '12 at 23:38
  • 2
    factoring is not NP hard. It's just there is no known algorithm that can factor in polynomial time but AFAIK no one has proven it can't be done. http://en.wikipedia.org/wiki/Integer_factorization – Guy Sirton Apr 13 '12 at 02:02
  • Should not have claimed factoring was NP hard (esp the hard part). Should have said best known (non-quantum computing) algorithms are exponential (really sub-exponential); that is not polynomial time. There isn't a proof showing the P-reducibility to other NP problems like SAT=TSP; partially due to factor not being a decision problem (yes/no answer). The decision problem: does a number N have a factor in the range `[2, k]` is [known to be NP](http://qwiki.stanford.edu/index.php/Complexity_Garden#integer_factor), [2](http://en.wikipedia.org/wiki/NP_(complexity)#Examples). But P≟NP is unknown. – dr jimbob Apr 13 '12 at 14:27
  • @GuySirton: While [many people would be surprised](https://complexityzoo.uwaterloo.ca/Complexity_Garden#integer_factorization) if it turns out that factoring is NP-hard, is there any proof that factoring is definitely not NP-hard? – David Cary May 13 '13 at 15:34
  • @DavidCary: I think what I wanted to say a year ago :-) is: "the statement that factoring is NP hard" is incorrect. Since then the answer has been edited and that statement removed... I don't know of a proof showing that factoring isn't NP hard. – Guy Sirton May 13 '13 at 21:26
6

It is not just the security of the encryption you should be concerned about but also its implementation. There are some attacks out there that circumvent ssl security altogether.

Blackhat Presentation on defeating SSL

SSLStrip software

woozle
  • 69
  • 2
  • And that's before we get to the problem that we can't trust CAs – ewanm89 Apr 10 '12 at 14:21
  • The question is quite specifically about the relationship between strength and key size, although the OP hadn't realised it was about the symmetric keys. It's fair to assume that HTTPS is used correctly here, with the right website. What you're talking about is a completely different problem. – Bruno Apr 10 '12 at 14:32
  • +1 for interesting read. Particularly, about the old browsers not checking who's allowed to sign intermediate certificates, users trusting the lock favicon, and unicode chars in the URL like: ⁄ that are similar to / as part of a wildcard signed domain. – dr jimbob Apr 10 '12 at 18:30
  • @woozle : But, why is there a need to use a symetric key. When the data itself can be ncrypted suing the server's public key. In case of user authentication, only the username and password are are needed which is not very long and can be emcrypted directly using a 2048 bit rsa key(with 2048 bit key you can directly encrypt data upto 256 bytes.) – Ashwin Apr 11 '12 at 04:27
  • @Bruno, I don't believe that in security it is safe to assume anything is secure. – woozle Apr 11 '12 at 13:50
  • @woozle, indeed, but you have to restrict the scope of the question too. If we don't assume the OP has checked whether SSL was enabled, with the correct host and a trusted cert (which is what SSLStrip targets), there's no point asking about the security offered by the key size. The list of other threats could be very long otherwise. – Bruno Apr 11 '12 at 13:57
5

It's the AES/RC4 symmetric keys that are 256bits long.

Asymmetric cryptography like RSA is very slow and needs very big keys based around products of very large primes as a such it is only used for the initial exchange of symmetric encryption keys and agreeing on the algorithm to use and such.

After the initial key exchange the connection uses all symmetric encryption algorithms with those smaller key sizes (which can be smaller as can be just any random bit string/number, none of this large primes requirements).

ewanm89
  • 2,043
  • 12
  • 15
  • But, why is there a need to use a symetric key. When the data itself can be ncrypted suing the server's public key. In case of user authentication, only the username and password are are needed which is not very long and can be emcrypted directly using a 2048 bit rsa key(with 2048 bit key you can directly encrypt data upto 256 bytes.) – Ashwin Apr 11 '12 at 04:27
  • Assymetric encryption is very slow, it needs longer slower math to even start to be secure with a lot bigger numbers. The whole session is encrypted in the sense of SSL/TLS, in terms of HTTPS that includes the page, the images (else browser will throw a warning), javascript files, css files... If one just does the password it can be easily circumvented, also after authentication when one is now setting the funds to be transferred, one does not want session stolen (firesheep) or data tampering. – ewanm89 Apr 12 '12 at 12:52
0

It's actually a hybrid encryption scheme. The 128 and 256 bits refers to a symmetric key cipher such as AES. The RSA key which is an asymmetric or public key cipher uses like 2048 bits.

So what the scheme is using is: RSA-2048-with-AES-256-CTR The RSA-2048 key is used to encrypt the AES-256 key. But the actual transaction data is encrypted with the AES-256 key.

WAR10CK
  • 161
  • 3