>Or was it that they were trying to use low level APIs in OpenSSL to create some higher-level cryptosystem they perhaps didn’t fully understand?

Yes. They wanted to encrypt some URL parameters with AES-ECB.

For example, let's look at the IV.

Symmetric encryption algorithms usually need an input called the initialization vector (IV), but different algorithms have different requirements.

AES-CBC requires unpredictability, but AES-CTR (and AES-GCM) require uniqueness. Misunderstanding of these requirements have led to real world attacks, see for example BEAST or https://eprint.iacr.org/2016/475.pdf.

Here's a random example. HMAC is frequently used in security protocols to generate more keys from a master key (for example, to generate temporary keys from a session key). The input to HMAC is (internally) padded with null bytes (<NUL>) before processing, so that for example "abc" and "abc<NUL><NUL><NUL>" will generate the same result. You may need to be aware of that padding when designing protocols that rely on HMAC, in order to avoid certain weaknesses. https://crypto.stackexchange.com/q/52161

As a very basic but very common example, I've seen many non-experts jump to encryption or symmetric crypto signatures whenever they want to prevent tampering with data, when what they needed was a simple integrity check.

Or, they want to do an integrity check, but don't realize that they need a canonical serialization algorithm for their implementation. So they use a standard, non-canonical serialization algorithm, and most of the time it works (because these algorithms typically don't vary that much, especially across tests on a single machine), but that's dangerous because it fails randomly in real life.

See more discussion here https://latacora.micro.blog/2019/07/24/how-not-to.html

Here is a (far from complete) list of fairly common mistakes:

https://github.com/SalusaSecondus/CryptoGotchas

Encrypting too much data with the same key immediately comes to my mind. Due to subtle issues involving birthday bounds, encrypting e.g. terabytes of data using AES-128-CTR (or GCM or other counter modes) can be insecure. Note that this can become an issue when CTR mode is used as a PRG for other cryptosystems, particularly if there is no good entropy source available and the system is demanding a lot of pseudorandom bytes (e.g. because there are many TLS sessions being served).

Another issue to look out for is compressing plaintext before encryption, which in some cases makes the encryption itself close to useless. Skype had this issue a few years ago and it is a tricky problem for secure voice or video conferencing.

Here's a classic - not understanding the implications of encrypt-then-mac vs mac-then-encrypt.

https://crypto.stackexchange.com/questions/202/should-we-mac...

Crypto code and non-crypto code have different requirements. For compiling non-crypto code you often want the fastest code that still matches the language spec. "Fast" is usually even relative to target platform. For crypto code, you need a very narrowly defined abstract machine that you program against and since that's a much stronger requirement than what the language is defined for, you take the next best thing by turning off all optimizations and hoping you understand well enough how your compiler generates code.

In other words, they already do their best by giving authors control over how much optimization is applied. Anything beyond that is a language design problem, not compiler construction problem.

He's from Vietnam, the blog title gave it away without reading the about section.