What does "crypto_box" actually mean in libsodium and NaCl? I cannot find what "crypto_box" actually means. In general, and in specific cases, what does "box" do? I know that libsodium is authenticated encryption, but GPG is not. "Box" makes me think the encryption and signing are somehow sealed and protected. 

What does "crypto_box" mean in libsodium and NaCl?
What does "cryptobox" mean in Libsodium and NaCl? In general, and in specific case, what does "box" do?


cryptobox or correctly crypto_box is just box. box_easy calls secretbox with the shared key between the sender and receiver, unique per direction. box_seal calls box_easy with a random sender secret key and prepends the ciphertext with its corresponding public key. secretbox does the symmetric authenticated encryption.



crypto_box_easy(ciphertext, MESSAGE, MESSAGE_LEN, nonce,
                    bob_publickey, alice_secretkey) 
crypto_box_seal(ciphertext, MESSAGE, MESSAGE_LEN, recipient_pk);
crypto_secretbox_easy(ciphertext, MESSAGE, MESSAGE_LEN, nonce, key);



  I know that libsodium is authenticated encryption, but gpg is not. "Box" makes me think the encryption and signing are somehow sealed and protected.


Both secretbox and GPG/PGP use authenticated encryption. box (deniably) authenticates the sender without a signature. box uses Diffie-Hellman to derive a key which requires either of the sender or receiver's secret key to compute. Consequently, if an adversary steals Alice' key, they may impersonate Bob to Alice; this attack is known as Key Compromise Impersonation.

PGP is vulnerable to a related attack by using sign-then-encrypt. I.e. If Alice signs a message and encrypts it for Bob, Bob may decrypt it and encrypt it for Carol. When Carol decrypts the message, she may believe Alice sent her the message, because Alice did, in fact, sign it.

Libsodium's box is better than PGP's sign-then-encrypt but we can do even better when both parties can send messages to the other. I.e Triple-DH used in Signal (ignore the prekey extension). Edit: Although I'd rather avoid signatures, I should have included this. Signatures may be combined appropriately by signing the (message, recipient public key) tuple; such that signature validation with the incorrect recipient fails to verify.