Support sender decryption of messages encrypted to counterparty

[hal0x2328]

Describe the solution you'd like and the expected behavior

To be able decrypt messages I've previously encrypted for another party.

Is your feature request related to a problem? Please describe.

In my Safe Remote Purchase dApp I have an encrypted chat feature which allows buyer and seller to communicate regarding the sale. In order to decrypt and display the full conversation state, currently the dApp must encrypt each message twice - one copy encrypted to the recipient, and a second copy encrypted to self.

Since the encrypt/decrypt functions use ECDH, the symmetric encryption key is the same for messages encrypted by the seller and messages encrypted by the buyer. i.e.
encrypt(recipientPublicKey, senderPrivateKey ... generates the same shared secret key as decrypt(senderPublicKey, recipientPrivateKey ... - so theoretically the sender should be able to call decrypt(recipientPublicKey, senderPrivateKey ... to decrypt the messages they've previously sent.

However the nOS crypto implementation in #241 uses the sender's public key as part of the HMAC input. So if the sender calls decrypt for a message previously sent as shown in the third example above, the recipient's public key is used instead of the sender's in the HMAC calculation, so the HMAC fails validation and the decrypt function throws an error (even though it is technically capable of decrypting the message accurately).

Possible implementation / References

Possible solutions:

1. Change the HMAC calculation from

const dataToMac = Buffer.concat([ivBuffer, senderPublicKeyBuffer, dataBuffer]);

to

const dataToMac = Buffer.concat([ivBuffer, dataBuffer]);

or just

const dataToMac = Buffer.concat([dataBuffer]);

I don't know if there is a reason method one was chosen over the others but this change would break any previous messages' decryption in nOS dApps already using the encrypt/decrypt feature.

2. Allow the caller of decrypt to pass a flag to ignore the MAC check. Not ideal because it could lead to malformed output if the input keys are incorrect or the ciphertext message bytes are corrupt.

3. Allow the caller of decrypt to pass an optional public key which would override the senderPublicKey for the HMAC calculation but not the generation of the shared secret. i.e.

decrypt( {senderPublicKey, wif, iv, mac, data, hmacPublicKey} )

Seems like a bit of a hack but would maintain backward compatibility.