[loup-vaillant]

> That's a dangerous statement on it's own.

I'm not sure how best to say it.

Implementing primitives & protocols requires little cryptographic knowledge. It does however require significant knowledge about program correctness: testing methods, proofs, and if side channels are important, the characteristics of your platform, and an accurate enough idea how your compiler or interpreter works.

Likewise, to implement an energy constant implementation of Chacah20 in silicon, you don't need a cryptographer, you need a hardware designer. The only thing you need a cryptographer for, is telling the hardware designer to make it constant energy — or convincing the higher ups why the extra cost is justified.

The blog post you link (which I love by the way) seems to confirm my view: many problems are ones of correctness. I believe most such bugs would be caught by corrupting the inputs, as I alluded to. Here, corrupting the password would fail to abort, and you'd catch the bug.

[codysc]

I don't think I exactly understand your points.

Using an example of IV reuse in AES-GCM:

The weaknesses resulting from this wouldn't be discoverable with a test like corrupting the password from the first example. If the developer wasn't aware that IV reuse introduced that weakness then they would be using strong primitives but in a way that dramatically undermines the actual encryption.

Not to put words in your mouth, but I assume your answer would be to say that this would be a matter of correctness. If yes, then where I'm coming from is that the majority of devs don't have the skillset to be correct and sometimes wouldn't dive deep enough to discover these kinds of pitfalls.

[loup-vaillant]

> Using an example of IV reuse in AES-GCM:

Yes, that one wouldn't be caught by corrupting inputs. You need to make sure you don't reuse the IV in the first place. And that's indeed a cryptography related bug.

> I assume your answer would be to say this would be a matter of correctness

It would be.

> where I'm coming from is that the majority of devs don't have the skillset to be correct

Unfortunately, I can believe that. Correctness is hard. Or expensive. Let's try with this example.

If you're designing an AEAD yourself, you can notice the error by trying (and failing) to prove IND-CCA2. If you're implementing or using AEAD, code review should the problem… unless this is a bug like you've shown before. Tough one to spot.

One way to avoid the IV bug with a reasonable degree of certainty would be to use a counter or a ratchet. Don't send the IV over the network, let it be implicit. Then write two implementations in two very different languages. It is very unlikely that both happen to repeat the same hard coded IV.

If we still want to use random IVs, we probably need to mitigate replay attacks: have the receiver store the last few IVs of the messages it received this session, and have it compare any new IVs with this set. Won't stop all replay attacks (the attacker could wait until old IVs are forgotten), but it will at least catch the accidental reuse.