box.c.txt
unbox.c.txt
box.go.txt
unbox.go.txt

@FiloSottile

Why do you think the x/crypto implementations don't interoperate with NaCl's crypto_box? Did you test it? If so, please provide the code for your tests.

Isn't libsodium's crypto_box_easy supposed to be the same as djb NaCl's crypto_box? Libsodium just offers an additional detached mode (called crypto_box_detached) that allows you to write the tag somewhere else instead of prepending it to the ciphertext.

@flyn-org
Where is the sample code using DJB's reference NaCl that fails to interoperate with your sample .go?

Have you tested either with tweetNaCl/20140427/tweetnacl.{h,c} ?

P.S. Check whether your NaCl code fulfills all "caller must ensure" points of NaCl documentation like:

WARNING: Messages in the C NaCl API are 0-padded versions of messages in the C++ NaCl API. Specifically: The caller must ensure, before calling the C NaCl crypto_box function, that the first crypto_box_ZEROBYTES bytes of the message m are all 0. Typical higher-level applications will work with the remaining bytes of the message; note, however, that mlen counts all of the bytes, including the bytes required to be 0.

The original NaCl API is bizarre to the point of being perplexing and unsafe, so while x/crypto/nacl is interoperable with it, it doesn't match its idiosyncrasies, so doesn't require the same padding.

If you use the more reasonable "easy" libsodium API, or if you properly apply padding as required by the original NaCl API, you should find it to interoperate correctly with x/crypto/nacl. (If not, please open a new issue!)