Is libsodium's `box` construct secure without additional manual padding of the plaintext before encryption?

Question

I have read the following questions and answers:

• How safe are Libsodium Crypto Boxes?
• What can be learned from the ciphertext of LibSodium's crypto_box_detached()?

However, neither of these discuss an important detail that caught my attention while reading the libsodium documentation on the padding API:

Most modern cryptographic constructions disclose message lengths. The ciphertext for a given message will always have the same length, or add a constant number of bytes to it. For most applications, this is not an issue. But in some specific situations, such as interactive remote shells, hiding the length may be desirable.

As far as I can tell, this also applies to boxes, because they use a stream cipher, XSalsa20, under the hood. However, the docs for the Box API claim that:

The _easy and _detached APIs are faster and improve usability by not requiring padding, copying or tricky pointer arithmetic.

I've also read in various places that unpadded symmetric key cryptography is not secure for several reasons (e.g. malleability caused by determinism). However, in the Box implementation, the asymmetric keys are not used for encrypting the plaintext itself, but for deriving the shared secret key for the XSalsa20 symmetric cipher.

Overall, this made me wonder whether the problem of padding is still relevant, and whether I should manually pad my messages before passing them to crypto_box_easy (and obviously, unpad them when they are returned from crypto_box_easy_open) for better security? I can't quite connect the dots, and I don't want to uselessly complicate the crypto code I'm writing either (because that in itself could grow the security attack surface).

Answer 1

The _easy and _detached APIs are faster and improve usability by not requiring padding, copying or tricky pointer arithmetic.

This refers to the way the original NaCl API worked. You had to add some zeros before the message, and remove them after decryption. But this is just how the functions had to be used. It made the primitive implementation easier, but usage trickier. It didn't add any actual padding to the messages.

(e.g. malleability caused by determinism)

Irrelevant here. The nonce ensures that the same message encrypted twice produces different ciphertexts.

Padding should be added only if you consider that an attacker may learn something relevant from the length of the messages. If you are sending encrypted passwords, this will reveal the length of the passwords, which may not be desirable. If the only messages that can be exchanged are "yes" and "no", the attacker will not require to decrypt anything to guess the message. Here, padding would be useful.

But for most applications, it is useless.