7

I was looking for libraries to implement an encryption system and was interested in using the NaCl: Networking and Cryptography library specifically the box function. Obviously, it uses symmetric encryption XSalsa20, Curve25519 for public-private cryptography and Poly1305 for authentication as the primitives for it.

However, the documentation looks to be insufficient in the way the they've been used. For example, it mentions that to compute the key it uses the sender's private key and the receiver's public key to compute the secret key. But it doesn't explain how. Can anyone shed any light on it?

If I were to use the same public and private key, I wouldn't the same key to be generated on the next attempt and it would be disastrous. Does anyone know of the explanation behind it or hook me up with some more documentation on how the functions work rather than how the functions can be used?

Rainer Joswig
  • 136,269
  • 10
  • 221
  • 346
GamingX
  • 179
  • 1
  • 7

2 Answers2

16

How does crypto_box work?

box uses a Diffie-Hellman key exchange on the two keys and hashes the result. Then it uses that as the key for secret_box.

  • crypto_box is equivalent to crypto_box_beforenm followed by crypto_box_afternm.

  • crypto_box_beforenm 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.

    k = Hash(Curve25519(b, A)) = Hash(Curve25519(a, B))

  • crypto_box_afternm is identical to crypto_secret_box. 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.

What happens if you use it multiple times?

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

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.

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

Common ways to create a unique nonce are:

  • Use an 8 byte prefix and a random 16 byte value (stateless, random 16 bytes are most likely unique)
  • Use a 16 byte prefix and a 8 byte counter (stateful, useful in a connection where you increment for each packet)
CodesInChaos
  • 106,488
  • 23
  • 218
  • 262
  • Adding to the first part of this answer: If you don't want to dig through the whole Curve25519 paper, the way Diffie-Helman can be used as part of a public key infrastructure is also explained very well (and concisely) on https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Public_key. – balu Mar 10 '15 at 11:20
1

For example, it mentions that to compute the key it uses the sender's private key and the receiver's public key to compute the secret key. But it doesn't explain how. Can anyone shed any light on it?

There is a nice, understandable video, but in german language: https://www.youtube.com/watch?v=aC05R9xqbgE. This video explains it for both the "discrete logarithm" and the "elliptic curve" solution.

In the "elliptic curve" scenario, the public key P is a point (with x and y coordinates) on the curve. P is calculated by multiplication of a Generator G (defined by the curve) with a secret key K.To calulate the secret key S, just do a multiplication of the peer's point P (peer's public key) with the own secret key K (a scalar number). Both peers make this operation:

S_Alice = P_Bob mult K_Alice = G mult K_Bob mult K_Alice

S_Bob = P_Alice mult K_Bob = G mult K_Alice mult K_Bob

As the curve is a commutative group, the order of the multiplications does not matter, so from the above calculations you can see that in the end both Bob and Alice calculated an identical key.

Wolfgang Klenk
  • 21
  • 2