The author should spend a little more time on the distinctions between IVs and nonces (this is a problem in the literature as well) because the constraints on both are subtly different. An IV is an implied first ciphertext block, and in CBC it needs to be unpredictable. A nonce is a number used just once; it is less important that a nonce be unpredictable, and in fact in some constructions (GCM being a good example) a random nonce can be problematic.

I’d also nitpick that there are probably much more important common developer crypto mistakes that should push out, for instance, not using password hashes or having incoherent crypto designs. For instance:

Directly using RSA to encrypt plaintext (and, relatedly, using RSA without secure padding).

Failing to authenticate associated data (such as the IV of a CBC ciphertext.

Compressing before encrypting.

I might also instead of recommending RSA-2048 and discussing key sizes instead just push people towards Curve25519.

I wish I could just tell everyone to use Curve25519, but unfortunately as long as FIPS is still baring it I don’t think it will get adopted at the rate we all want.

I’ll be the dumdum here and ask why you should not do this. I see that encrypting a symmetric key for the message using RSA is recommended instead. Why? :)

A few reasons, one you can only encrypt things with RSA up to the size of the key, so if you want to encrypt a large message you just can’t in a single shot with RSA. You might design some sort of multi-RSA-encryption scheme, but then the problem you face is that RSA encryption is significantly slower than a symmetric cipher like AES.

Also: the amount you can encrypt per “block” is deceptive, because there’s an amount of padding necessary for security, and encrypting correlated bits under RSA makes error oracle attacks more feasible. There is in practice virtually never a reason to encrypt directly with RSA.

This is a pretty good post.

The author should spend a little more time on the distinctions between IVs and nonces (this is a problem in the literature as well) because the constraints on both are subtly different. An IV is an implied first ciphertext block, and in CBC it needs to be unpredictable. A nonce is a number used just once; it is less important that a nonce be unpredictable, and in fact in some constructions (GCM being a good example) a random nonce can be problematic.

I’d also nitpick that there are probably much more important common developer crypto mistakes that should push out, for instance, not using password hashes or having incoherent crypto designs. For instance:

Directly using RSA to encrypt plaintext (and, relatedly, using RSA without secure padding).

Failing to authenticate associated data (such as the IV of a CBC ciphertext.

Compressing before encrypting.

I might also instead of recommending RSA-2048 and discussing key sizes instead just push people towards Curve25519.

I wish I could just tell everyone to use Curve25519, but unfortunately as long as FIPS is still baring it I don’t think it will get adopted at the rate we all want.

I’ll be the dumdum here and ask why you should not do this. I see that encrypting a symmetric key for the message using RSA is recommended instead. Why? :)

A few reasons, one you can only encrypt things with RSA up to the size of the key, so if you want to encrypt a large message you just can’t in a single shot with RSA. You might design some sort of multi-RSA-encryption scheme, but then the problem you face is that RSA encryption is significantly slower than a symmetric cipher like AES.

Finally, I’d like to note that in general I think people should be skeptical of designs that involve encrypting anything with long-term RSA keys: https://alexgaynor.net/2017/apr/26/forward-secrecy-is-the-most-important-thing/

Also: the amount you can encrypt per “block” is deceptive, because there’s an amount of padding necessary for security, and encrypting correlated bits under RSA makes error oracle attacks more feasible. There is in practice virtually never a reason to encrypt directly with RSA.

He left out “writing your own crypto”.