1
$\begingroup$

Is it possible to achieve forward secrecy using a one way communication channel with pre-shared secret?

I have a setup where I need to send some information across a unsafe channel between server A and server B. This communication can only go from A to B so no handshake or two way key exchange is possible.

I could simply share a key between the two servers and use symmetric encryption. But I would like to get forward secrecy if possible so that if the shared keys are compromised in the future the old communication is not compromised.

Is there a known protocol that can do this?

I guess the problem is its impossible to share random session keys like you can in say diffie-hellman and then have to rely on deterministic key generation such as TOTP which derives from the shared secret.

The data to be transmitted is less then 2 kb, all the usual stuff about authentication, replay, tampering etc. still applies.

Improve this question
$\endgroup$
3
  • $\begingroup$ You should also consider the topic that you may not be able to use your transmitted data yourself when having absolutly no response if the packages reached the destination. And if it is that valuable it would be a shame to not knowing if your data is correct or even decryptable. $\endgroup$
    – Matte
    Sep 5, 2017 at 11:32
  • $\begingroup$ @Matte your correct. But for my current application that is not a concern. And I agree my actual setup is pretty flawed but i still would like to know if its possible just out of curiosity. That and it would be a simple solution to my problem. $\endgroup$
    – CodeMonkey
    Sep 5, 2017 at 12:03
  • $\begingroup$ Sounds like you may want to look into Unidirectional Gateways. They provide a one directional communication like what you are mentioning. Kind of pricy though. $\endgroup$
    – W P
    Sep 5, 2017 at 18:36

1 Answer 1

Reset to default
1
$\begingroup$

Is there a known protocol that can do this?

It's easy to see that forward security is impossible with the constraints you have.

Suppose an attacker breaks into B to create a B' with the exact same state.

Then, from now on, when A sends a message to B, the attacker takes that message and also submits it to B'.

B and B' are essentially identical; if B can understand the message, so can B'.

This remains true even if B can generate some local entropy (e.g. has an entropy source whose output the attacker cannot predict); as B cannot send its entropy back to A, it has to understand the message from A no matter what the entropy is (and hence B' can as well, even if its entropy sample is different).

Improve this answer
$\endgroup$
4
  • $\begingroup$ What about forward secrecy only regarding the sender? (Attacker duplicates the sender's state, and then the sender sends a message to the receiver that must not be readable by the attacker.) $\endgroup$
    – Macil
    Sep 5, 2017 at 18:22
  • $\begingroup$ @AgentME: if you disallow public key crypto, I'm pretty sure it's the same; using symmetric crypto only, from A, the attacker should know enough to reconstruct a B' that is able to decrypt every message. Once you do allow public key crypto, then you put B's public encryption key on A, problem solved... $\endgroup$
    – poncho
    Sep 5, 2017 at 18:25
  • $\begingroup$ This means that a breach compromises all future communications, not that it compromises past communications. Protecting past communications should be possible with a ratcheting system. $\endgroup$
    – Gordon Davisson
    Sep 5, 2017 at 18:50
  • $\begingroup$ @poncho the timing of when B is compromised is important. All messages before that moment could have forward secrecy, using a OTP as an example your system at B would have to delete the key used after decryption (and the message after you read it). $\endgroup$
    – daniel
    Sep 6, 2017 at 7:33

Your Answer

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