2

I am trying to brainstorm how I might either:

1) create a protocol (although against this option)
2) use an existing protocol

That does the following:

1) allows 1 way communication from 1 node to another.
2) Provides (high grade) encryption over this 1 way connection

Requirement:

  • cannot use TCP
  • use keys similar to ssh does with public/private

I'm thinking some mature udp solution, but am not sure.

Can someone enlighten me how this may be possible?

Thanks

Improve this question
7
  • Is it possible for nodes to know other node's keys?
    – jrtapsell
    May 31, 2018 at 13:11
  • Yes, similar to ssh, but without tcp, somehow?
    – Jshee
    May 31, 2018 at 13:12
  • Is there a reason for not allowing TCP?
    – jrtapsell
    May 31, 2018 at 13:13
  • Yes it isnt allowed in my use case. Node A is only one way to Node B
    – Jshee
    May 31, 2018 at 13:13
  • So the nodes can have a fixed list of all the other nodes, and their keys, if so then you just want to lookup the target node and encrypt to its key
    – jrtapsell
    May 31, 2018 at 13:19

2 Answers 2

Reset to default
3

use keys similar to ssh does with public/private

This means authentication of the sender and recipient by letting each of these prove that they have access to the private key matching the accepted public key. This is essentially done by having on party create a challenge and the other party sign this challenge with the private key. This of course requires bidirectional communication which is against your requirement of one-way communication.

But, if you skip the "similar to ssh" you can use other established methods for one-way communication. A typical example for such methods is end-to-end encryption in mail, which is also one-way. Established protocols in this area are PGP and S/MIME which basically work like this:

  • Sender signs the message with its own private key, where the public key is known to the recipient.
  • Sender encrypts the (signed) message with the recipients public key. The encryption should of course involve also integrity protection (using an additional HMAC or authenticated encryption). And as usual the public key is not used to encrypt the whole message but this is instead done with a randomly generated symmetric key which is then protected (i.e. encrypted) with the public key.

Once the message is signed and encrypted without involvement of the recipient the message can be send over whatever unidirectional channel you want, i.e. UDP, data diode, avian carrier or whatever. There is no communication back from the recipient needed but of course the sender will never know if the recipient actually received the message.

Please note that this schema does not provide any forward secrecy, i.e. if the recipients private key is compromised all messages encrypted for this key (current, previous and future) can be decrypted. I don't think it is possible to provide forward secrecy with a pure one-way scheme though, but you might check this with the crypto experts at crypto.stackexchange.com.

Improve this answer
6
  • Do PGP and/or S/MIME generate a "session" symmetrical encryption key for each message, and only use asymmetric encryption to send that at the beginning of the message? Do they have a key refresh policy after some data has been sent to generate a new key, to prevent plaintext attack on the session key?
    – pqnet
    May 31, 2018 at 15:20
  • @pqnet: As practically all relevant encryption protocols using asymmetric cryptography PGP and S/MIME also combine asymmetric with symmetric encryption. I'm not aware of any key refresh inside a single message since the messages don't get that large that this is really needed and a new message has a new symmetric key.
    – Steffen Ullrich
    May 31, 2018 at 15:36
  • then PGP might be unsuitable for suitably large streams of data if used as network encryption protocol
    – pqnet
    Jun 6, 2018 at 18:49
  • @pqnet: you can simply split your large message into smaller ones and handle each of these separately.
    – Steffen Ullrich
    Jun 6, 2018 at 19:20
  • 1
    @pqnet: PGP is used for mails. I never tried to suggest that you should use plain PGP or S/MIME, just that you can model your protocol like these instead of modeling it like SSH - since the PGP model provides one-way while the SSH model does not. Of course you cannot use plain PGP since you also must add some kind of resistance against data loss (one-way means no feedback of successful delivery).
    – Steffen Ullrich
    Jun 7, 2018 at 18:46
-1

Why don't use DTLS (https://www.rfc-editor.org/rfc/rfc6347)? I think fix your requirements from my point of view

Improve this answer
1
  • DTLS has a key exchange at the beginning which needs two-way communication
    – Steffen Ullrich
    May 31, 2018 at 13:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .