4

As explained in the TCP/IP Guide, it is possible to configure TCP/IP to operate in simplex mode and this mode is utilized, among other things, in communication from satellites.

One consideration with TCP/IP is however that, in itself, it "lacks even the most basic mechanisms for security, such as authentication or encryption", as explained in this article.

According to this other question, IPSec can be used to provide encryption for IP, but as can be read at Wikipedia, IPSec is used to establish mutual authentication and exchange of encryption keys.

Neither mutual authentication nor an exchange of keys should be possible in fully simplex mode (or maybe it is but I am missing something?).

Anyway, the question I wanted to ask is: if TCP/IP is actually ever operated in simplex mode, what are the options for encrypting the data?

  • 1
    "TCP/IP"? Raw IP can work in simplex mode (as can UDP), but TCP cannot since you must send and receive packets to perform a handshake. – user1686 Aug 26 '15 at 16:43
  • @grawity, a handshake is only needed when negotiating encryption. Neither TCP nor IP include mechanisms for encryption within themselves. They can be run in simplex mode (just like it's explained in The TCP/IP Guide) but any encryption cannot depend on a handshake. – coderworks Aug 26 '15 at 20:02
  • No, just because a "TCP/IP guide" describes general modes like simplex or duplex, doesn't automatically mean all of them apply to TCP or IP specifically. A handshake is also needed when negotiating the TCP connection, and a TCP connection is full-duplex. /// ("Encryption cannot depend on handshake"? Well, handshake cannot depend on encryption either! There are many other parameters that can be 'negotiated', not just keys.) – user1686 Aug 26 '15 at 20:13
4

With one-directional communication the sender must have least some knowledge of the recipient so that the data can be encrypted. This knowledge might be a common pre-shared secret which is used in symmetric communication or it might be the public key like used in PGP and S/MIME. This public key then can be used to encrypt a message which can be decrypted only by private key (which should only be accessible to the recipient). In practice this public key is usually used for performance reasons to encrypt only a short random secret and this random secret is used as symmetric key to encrypt the larger data.

The established standards PGP and S/MIME are actually good examples how to encrypt a message without doing any kind of handshakes inside the communication channel. The sender only needs the public key of the recipient to create such an encrypted message.

Of course if the common pre-shared key or the private key of the sender are compromised all communication done using this key can be decrypted, which includes all old communication. This risk can be mitigated if you use a different key all the time in the hope that not all of the keys gets compromised. But this would mean that you need some kind of back communication from time to time to exchange or negotiate the new keys.

| improve this answer | |
  • In simple terms - without a key, sending encrypted data is pointless. – user67862 Aug 26 '15 at 11:08
  • 1
    @Ian: the key is needed for the encryption not for the sending. You can still send pre-encrypted data without having access to the key. – Steffen Ullrich Aug 26 '15 at 11:34
  • Apologies - I meant to say encrypting without notifying the receiver of any key is pointless. – user67862 Aug 26 '15 at 12:19
  • After re reading your comment though, you seem to argue against even what I've just added to my initial comment. – user67862 Aug 26 '15 at 12:20
  • 1
    @Ian: I must say that I don't really understand what you arguing about. A key must be there before encrypting something. Thus you either have the key (common pre-shared key) or create it (random key) and transmit it protected (encrypted with the public key of the recipient). – Steffen Ullrich Aug 26 '15 at 13:20
1

OTP and variations thereof can be utilized and would be the best option given a strong enough key, of course traditional symmetric & asymmetric ciphers can also be used.

The problem however would be forward-secrecy for previous communications, once the data is encrypted and sent it is a matter of time before the key can be factored leading to a compromise of the data.

This problem is compounded in simplex mode because you cannot perform any further key exchanges between parties because it is usually embedded in the firmware.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.