Scenario 1: SenderA sends message1 to ReceiverB

message1 is encrypted using NACL crypto_box using SenderA secret key and ReceiverB public key.

we understand that the NACL crypto_box authenticator proves to ReceiverB that message1 originated from SenderA.

we understand that ReceiverB cannot prove to a third party that message1 originated from SenderA because ReceiverB could have calculated the same authenticator. For our purposes this is a good thing.

Scenario 2:

AttackerA steals ReceiverB secret key and is also able to stage a man in the middle attack

We understand that AttackerA can now read all messages addressed to ReceiverB. We also understand that AttackerA can now impersonate ReceiverB and send out messages as ReceiverB. We accept that this may happen and we can manage the consequences.

What we cannot manage and must remain valid is that ReceiverB can always prove that any message received from SenderA (intercepted by AttackerA or not) has indeed originated from SenderA. Is there anyway that AttackerA can change an existing message from SenderA and still make it appear to ReceiverB as a valid message from SenderA?

Thank you

  • $\begingroup$ This looks more like a protocol design problem than a crypto issue. $\endgroup$ – camp0 Aug 15 '19 at 8:06
  • $\begingroup$ Possibly yes, we have no issue with the underlying crypto. We were hoping to avoid digital signatures $\endgroup$ – Pavlos Aug 15 '19 at 20:41

Yes, the attacker does have the ability to make messages to appear to be from SenderA. In the end, the crypto_box functionality relies on a MAC, not a signature. That means that it depends on a shared secret key, rather than a private key for message authenticity. As explicitly stated by the protocol, this allows any message to be signed if you possess just one of the private keys. Because in that case you can calculate the shared secret key and - of course - any MAC generated by the shared secret key.

If you require that messages are authentic even if the key of the receiver is lost then you need to use a signature as well. Generally you would then have to use sign-then-encrypt to create a secure protocol, especially if you consider that private keys may get known by the attacker(s) of the system. Obviously the public keys need to be trusted in any scenario.


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.