Hacker News Reader

Comment by daenz | Hacker News Reader

For the very example-driven people, can you give a couple of examples of some of those non-obvious, subtle implementation details that completely destroy crypto schemes?

View on HN

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...

If speed was not an issue and you don't mind having to have 3 keys, could you cover all the bases by doing MAC-then-encrypt, then treat that as cleartext and do encrypt-and-MAC on that, and finally treat the result of that as cleartext and do encrypt-then-MAC on that to get the final thing you send?

Reply on news.ycombinator.com