# specific scenario question relating to using NACL crypto_box in a protocol

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

• This looks more like a protocol design problem than a crypto issue. – camp0 Aug 15 at 8:06
• Possibly yes, we have no issue with the underlying crypto. We were hoping to avoid digital signatures – Pavlos Aug 15 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.