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:
_detachedAPIs 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).