Anyway, for an application developer (as opposed to a crypto engineer), just use libsodium when you control both sides.
If you need to interop with someone else, use TLS 1.3 if you can, or TLS 1.2 but only with ciphers that support PFS and AEAD, i.e. in practice x25519 and P-256 ECDHE with RSA signatures with AES GCM or ChaCha20Poly1305.
Same primitives are available in SSH.
If you can, don't use IPSec, use wireguard.
Don't use pgp/openpgp/gpg email, use signal. You can use gpg to sign packages and encrypt backups, but the email integration and UX will kill you.
Is there any problem with the crypto that gpg uses, or is it just a matter of the UX?
Gpg email also leak some more metadata than signal does. But it leaks to different parties, so this is not clear-cut.
For back and forth messages between two or more people, lack of forward secrecy is a problem, integration with the email program is a problem, email metadata is a problem (not just to and from but also the subject line), teaching your confederates to not reply in the clear quoting the entire decrypted message you sent is a problem, etc.
Security practitioners basically believe email cannot be saved, it cannot be used securely by regular people and its only use is to bootstrap something else.
Subject is hidden in newer software e.g. Enigmail and K9 (it's moved to encrypted part and replaced with a placeholder see https://github.com/autocrypt/memoryhole).
If so, what are the reasons? Just enhanced usability, since I recall libsodium using the NaCl crypto primitives almost directly as-is?
> It is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further.
> Sodium supports a variety of compilers and operating systems, including Windows (with MingW or Visual Studio, x86 and x64), iOS, Android, as well as Javascript and Webassembly.
Look at the release notes on the releases page to see what kind of things they do.
This is built into modern browsers so you can use that as the basis for HMAC if you can't trust TLS or have something like an open URL for a lambda function that in theory should only be hit by someone's webhook (ie. Slack)