0

I need to implement tcp socket communication between server and iOS client. I am thinking of using symmetric key encryption for securing data sent through the channel. I will be storing symmetric key inside the application which I think should be secure. (there won't be any handshake of key)

However, I am not sure whether going for symmetric key encryption over ssl socket will improve connection speed significantly?

My requirement is connection should be established as soon as possible when user launches application. Can anyone point me in right direction?

Nilesh
  • 5,955
  • 3
  • 24
  • 34
  • 1
    TLS already uses symmetric encryption after the handshake. What speed issue do you see during the handshake at the moment? – Bruno Dec 05 '11 at 10:50
  • I am concerned about latency added by ssl handshake.(especially on a slower network). I am referring to this question : http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose – Nilesh Dec 05 '11 at 11:49
  • 1
    Just wondering if you're concerned by hearsay (or reading stuff on SO), or if you've actually run some performance tests? What's your plan for sharing that secret key, by the way? – Bruno Dec 05 '11 at 11:55
  • Actually I am in design phase and was just wondering which will be the best way to implement such thing. We have been specifically asked to keep connection time as small as possible. I haven't run any performance tests. The guy in this post has done some analysis though if that interests you. : http://www.semicomplete.com/blog/geekery/ssl-latency.html Regarding sharing the secret, I think for now sticking to ssl seems the best way. – Nilesh Dec 05 '11 at 12:05
  • You should use TLS. It securely established a symmetric session key; it authenticates the server; and it can use an abbreviated handshake for new connections to the same target when a prior TLS session has already been established. Don't roll your own. – user207421 Feb 08 '17 at 22:10
  • Thanks EJP. It was long time ago and we ended up using TLS. – Nilesh Feb 14 '17 at 18:24

1 Answers1

2

The speed issue with TLS is only associated with the public-key handshake. As Bruno commented TLS uses symmetric encrypion post-handshake.

If public-key handshake adds too much latency for this particular application you should not use the shared-secret scheme that you are proposing with a shared encryption key. If you use the same key for each connection the ciphertext is vulnerable to attacks analyzing ciphertext of multiple sessions. Instead you need to apply a scheme for using a "shared secret" (which is never used directly for encryption) to negotiate a unique encryption key for each connection. Plus you need some protocol for data integrity validation on transmitted data.

All of this is tricky business to get right, so if possible you should probably go with TLS.

Versile
  • 308
  • 1
  • 4
  • 2
    In addition, one of the main points why the handshake involves a public key has to do with the certificate, which is used to verify the identity of the server (at least). This step is necessary for securing the channel. – Bruno Dec 05 '11 at 11:51
  • 2
    JFI: TLS supports shared-secret authentication schemes (so-called PSK ciphersuites). – Eugene Mayevski 'Callback Dec 05 '11 at 12:10