<h3>Hints</h3>

<p><b>How does crypto_box

<ul>
  <li><code>crypto_box</code> uses a Diffie-Hellman key exchange on the two keys and hashes the result. Then it uses that as the key for
  <li><code>crypto_box</code> is equivalent to <code>crypto_box_beforenm</code> followed by
  <li><code>crypto_box_beforenm</code> is the hashed key-exchange which works as described in the Curve25519 paper, using elliptic curve Diffie-Hellman key exchange on Curve25519 hashing the result with HSalsa. This yields a 32 byte shared key.<br /><code>k = Hash(Curve25519(b, A)) = Hash(Curve25519(a,
  <li><code>crypto_box_afternm</code> is identical to <code>crypto_secret_box</code>. It takes a 24 byte nonce and a 32 byte key. It's an authenticated stream cipher using XSalsa20 for encryption and Poly1305 as MAC. The first 32 bytes of the output of XSalsa20 are used for the MAC, the rest are xored into the plaintext to encrypt it.</li>
</ul>

<p><b>What happens if you use it multiple

<p>If you take two fixed key-pairs, the result of the key exchange will always be the same.</p>

<p>But the symmetric part secret_box is secure even when you use a key several times, as long as you never reuse a nonce for that key, i.e. the (key, nonce) pair must be unique.</p>

<p>This property is pretty much the same for all modern authenticated stream ciphers, such as AES-GCM or XSalsa20-Poly1305.</p>

<p>Common ways to create a unique nonce are:</p>

<ul>
  <li>Use an 8 byte prefix and a random 16 byte value (stateless, random 16 bytes are most likely unique)</li>
  <li>Use a 16 byte prefix and a 8 byte counter (stateful, useful in a connection where you increment for each packet)</li>
</ul>

<p>from