3 ms·

It seems to me that this blog post is mostly about parameter choosing and this criticism could just as easily be applied to AES (there are lots of pitfalls ther

• rocqua 7y ago
  > this criticism could just as easily be applied to AES Not really, because the pitfalls in AES are more well-known. Moreover, there are widespread AES-modes that work pretty well. Really, once you have picked a mode of AES (besides ECB) the biggest pitfalls are 'only use a nonce once' and 'use HMAC (MAC-then-encrypt) if your mode isn't authenticated'. With AES-GCM, that last one drops off. With AES-SIV the first requirement drops, and AES-GCM-SIV has neither consideration. Granted, AES-GCM and similar are not trivial to implement, but given there are test-vectors it is harder to accidentally publish a faulty version. Moreover, much fewer people actually know how AES works. Especially compared with the amount of people who could essentially implement primitive (insecure) RSA from memory. This comes with many more attempts at RSA. Essentially because the distance between the insecure primitive and the secure systems using RSA is so incredibly large.
• tptacek 7y ago
  There definitely are similar pitfalls in AES, and nobody should be encrypting with "AES"; they should be using something like AES-GCM-SIV (or, to extend the analogy with the post, Chapoly, which has the virtue of only being usable in a relatively secure fashion). More cryptography has been broken by casual invocation of AES than has been broken by serious attempts to deploy custom ciphers.