1

For a very security-intensive web application, it is feasible to encrypt all vital data sent back and forth between client and server using 2048-bit RSA encryption? Assuming there are kilobytes to megabytes of data being sent back and forth (before encryption), what would be the performance loss of using this type of encryption?

Lastly, how would I (I can write the code if I have a general model) have the server send server-to-client decryption keys and decryption engines to the client without compromising security for the current and future sessions (i.e. another user of the same application will not be able to intercept the data from the first user and use the information stored on their computer from their session for decryption of the first user's data, and a bad-intentioned person will also not be able to intercept and use the first user's decryption keys and engines to accomplish the same task)?

halfer
  • 19,824
  • 17
  • 99
  • 186
TheEnvironmentalist
  • 2,694
  • 2
  • 19
  • 46

4 Answers4

4

It is certainly feasible to do so given modern processing power, but it is bad idea for several reasons.

Firstly, you can authenticate the server with a certificate, but what about the client? You could either use client certificates - problematic to manage, or you could generate a key pair at the client every time (slow) and authenticate the client with a password after establishing a secure session. AES on the other hand, just needs a short key and comes with support at the instruction set level from modern x86 and AMD processors.

Second, and judging from the fact that you're looking at RSA because you need a 'very security-intensive solution', you should know that RSA-2048 is actually less secure than AES-128. 2048 bits of RSA key is equivalent to about 112 bits of symmetric key strength. See here.

Lastly, the key exchange problem in symmetric schemes like AES is typically solved using an asymmetric scheme like RSA or DHKE. So what you should be doing is using a public crypto scheme to exchange symmetric keys, and then using a strong symmetric cipher for the rest of the data - this is exactly what TLS does.

HTTPS is the most well known application layer protocol - it stacks HTTP on top of TLS. TLS is widely supported, OpenSSL is probably the most popular library in use today, and is supported across all major platforms, use it.

Edit 1: Banks don't just apply SSL security because they realize that SSL doesn't solve everything - there are problems that it's not meant to solve. For example, it is useless against phishing or session stealing. The objective of the bank's authentication mechanism is not to check if the person it's talking to knows the password - it's to check if the person is You. This means also making sure the connection is coming from a recognized IP address, sometimes making you answer Security Questions, and asking you to make sure you recognize the bank website by using what are called SiteKeys.

Edit 2: You cannot make sure that the information isn't intercepted by a third party. The best you can hope for is that they cannot distinguish your data from a perfectly random stream of bytes, and this is the goal of every network security protocol. Some schemes also try and hide the actual source and destination addresses, such as IPsec, but this is uncommon.

santosh.ankr
  • 671
  • 4
  • 12
2

If you are building a web application and you need to transmit sensitive information between the web server and the browser, then you should be using SSL. It essentially does what you describe in your question.

See HTTPS for more information on how it works.

Using a 2048-bit encrypted SSL certificate is very feasible and is done all the time. The larger keys may produce a bit more delay, but in my experience, the delays as a result of key size are negligible. I would be more worried about transferring megabytes of data per page load.

Somewhat related: Are there any disadvantages to using a 4096-bit encrypted SSL certificate?

Of course, if your question is about encrypting the data server-side, sending it to the browser, and decyrpting it browser-side: my advice is don't. Think about your goals for this solution. The only thing it attempts to solve, is man-in-the-middle, which SSL already solves for you. In addition, anything you execute on the browser is insecure by nature since it is open to modification by the client, so that solution is quite insecure anyway.

Your last paragraph indicates you have concerns about preventing sql injection and session hijacking. Those should be posted as separate questions, but suffice it to say that you cannot solve those problems by encrypting your data transfers.

Community
  • 1
  • 1
Cypher
  • 2,608
  • 5
  • 27
  • 41
1

To get a good answer you would have to provide your definition of the word "feasible". It's probably possible that this could be done (you might have issues where you need good randomness and javascript in the browser is unable to provide that) but it would be incredibly slow and unwieldy.

Asymmetric encryption provides lots of nice features but performance isn't one of them. Hybrid approaches tend to be favored where asymmetric is used to exchange a symmetric encryption key and then that is used for encrypting and decrypting lots of data. That's how HTTPS in your browser works.

Speaking of browsers, if you're creating a web-app why not leverage the SSL protections that browsers already provide? If you don't trust the browser SSL for protecting your data, then you can't trust it to protect the javascript code that your server is sending down to your client.

u2702
  • 596
  • 5
  • 7
  • There's a reason, as I under it, why banks don't just apply SSL and leave security at that. I'm trying to find some way to send large amounts of information both ways securely, with the encryption and decryption processes being either barely noticeable or unnoticeable to the user. – TheEnvironmentalist Jun 19 '13 at 18:04
  • And a lot of the issue isn't making sure that information isn't maliciously injected by a third party, but making sure that it isn't intercepted by a third party. – TheEnvironmentalist Jun 19 '13 at 18:05
0

No. If you use RSA to encrypt/decrypt the data between client and server. It will be very slow.

Instead of that, 1. Use the RSA key pair to encrypt/decrypt the session key. 2. Encrypt/decrypt the data transferring between client and server using that session key. (as session key is symmetric key, it’ll be faster) 3. Since it is for single-use, there won’t be any problem of compromising security for the current and future sessions .

Please have a look at: http://en.wikipedia.org/wiki/Session_key

Rupali K
  • 66
  • 2