[noise] More Implementation Pitfalls: ReadMessage() Error Conditions

[Jason A. Donenfeld]

On Mon, Nov 16, 2015 at 8:29 PM, Alex <alex at centromere.net> wrote:
> This is not a problem with cacophony because all variables are
> immutable in Haskell. As a result, every function must return both
> the ciphertext/plaintext plus a fresh altered state[1].

That's good to hear. In that case, I'd recommend you add some sort of
locking/mutex to prevent nonce reuse in the case of two messages
arriving on different processors and each creating a different
resultant state from the same base state. Though, perhaps the
concurrency model in Haskell already prevents against this; not sure.