0

If I have number of computational nodes (over cloud for instance) and I would like to transfer data between them. The data over the network has to pass through as fast as possible and the encryption and decryption should be minimized. What is the best way for doing it in practice?

Avi
  • 563
  • 1
  • 5
  • 13
  • 2
    First you would have to provide a compelling argument why SSL/TLS would not work. – schroeder Sep 13 '16 at 19:02
  • I don't argue that SSL/TLS doesn't work. Because there is a need for lots of transformation, maybe we can use a trick to save time in the process or maybe there is a best practice for such a case. – Avi Sep 13 '16 at 19:05
  • 1
    The problem is that the "best way" is something like SSL/TLS. I assume you have considered it and rejected it, so we need to know what those reasons are (and the requirements for success). Is SSL/TLS too slow, or is it that you want to "go as fast as you can"? If the latter, then we need a LOT more detail on your implementation because there are a lot of possible moving parts. – schroeder Sep 13 '16 at 19:42

1 Answers1

2

I'd first try SSL/TLS - https. That's easy, there's lots of great info on it, you can use websockets to keep the connection open to improve your speed (much of the SSL/TLS slowdowns are in the handshaking at the beginning of each connection).

If that doesn't work for you, look at Quic - https://www.chromium.org/quic - Google's 'https' over udp protocol - designed to be both fast and secure.

Whatever you do, try to avoid inventing your own protocol and/or encryption - it is much harder than you might think to avoid all security holes.

crovers
  • 6,311
  • 1
  • 19
  • 29
  • Thanks @crovers. Is there a relation between number of sites or number of records transferred between sites or maybe the CPU per site that I can take into consideration when choosing the appropriate protocol? – Avi Sep 13 '16 at 19:58
  • 2
    It is going to depend on your particular data. If you are sending small numbers of big datasets, then just plain https is probably fine - the negotiation will get swamped in the sending time. If you are sending large numbers of small things from a small number of hosts, then consider websockets over https - each host will only connect once and then maintain that connection. Large numbers of small things from many hosts - maybe that's the time to consider QUIC. My advice - be agile, implement something that is standard and works, change if you have to – crovers Sep 13 '16 at 20:19