[tptacek]

That is the charitable way to describe Colin's suggestions. Another way to describe them is "well-aged", or "conservative".

Here are more modern alternatives to each of Colin's suggestions:

* Message encryption: AES-CTR+HMAC -> A fast native stream cipher (Salsa20) + polynomial MAC (Poly1305, VMAC).

* Standalone integrity checking: HMAC -> HMAC or SHA3.

* Hash: BLAKE2 or SHA3.

* Passwords: scrypt or, if not available, bcrypt.

* Public key encryption: ECDH + whatever you're using for message encryption, over Curve25519.

* Public key signatures: Deterministic ECDSA, EdDSA.

* Ephemeral key agreement: ECDH over Curve25519.

* Online backups: use Tarsnap.

[cperciva]

Another way to describe them is "well-aged", or "conservative".

I absolutely agree. I am 100% in favour of being conservative when choosing cryptographic primitives.

All the alternatives you've mentioned have arguments in their favour. But unless you need to have signatures which are 32 bytes instead of 256 bytes, or you need to perform 10,000 private key operations per second instead of 1,000, or you need to build an ASIC which uses a few thousand fewer transistors, my recommendation is to be conservative.

[tptacek]

I wonder whether I might not be able to convince you that RSA is less conservative than ECC. Certainly, I haven't once tested a piece of real-world software that got it right. Did you see that just the other day, a team managed to resurrect the PKCS1v15 padding oracle in JSSE? Is RSA plus OAEP really simpler than just using a curve to derive a key to encrypt with?