8
$\begingroup$

Why is there so little response (e.g. implementation in crypto libraries, programs...) after the end of the CAESAR competition? As far as I can see, there is no shift from AES-GCM to any of the CAESAR algorithms. The response to the Password Hashing Competition, for example, was greater, at least in my perception. Is there a reason for that?

$\endgroup$
0

2 Answers 2

3
$\begingroup$

CAESAR competition did not result in any standard.

I think it is because AES-GCM is already widely adopted (with hardware support, although some CAESAR algorithms also use AES) and CAESAR didn't bring anything significantly new. For example OCB was known before, but it is not widely adopted because it is patented (seems like patents have expired now). I guess CAESAR was too late for industry. There is no compelling reason to shift from AES-GCM.

Possibly Ascon and ACORN are being adopted, but we don't know as they are embedded in small devices. Ascon is also one of NIST lightweight finalists.

Password Hashing Competition did bring more as we only had PBKDF, bcrypt, scrypt.

EDIT: I said there are no compelling reason to shift from AES-GCM, but there are many reasons. However, it seems industry doesn't consider them as significat or is slow to adopt something new when there is already well established de facto standard. It seems new ciphers are slowly getting adopted, see the other answer.

$\endgroup$
6
  • $\begingroup$ OCB is no longer patented. I expect adoption to increase. $\endgroup$ Commented Oct 12, 2021 at 13:43
  • $\begingroup$ @SAIPeregrinus I believe it is still patented, but usage is free for most use cases. See cs.ucdavis.edu/~rogaway/ocb/license.htm $\endgroup$
    – LightBit
    Commented Oct 12, 2021 at 14:55
  • 2
    $\begingroup$ Also there are some pretty cheap hardware crypto accelerators that already supported AES-GCM (I've used Microchip's ATECC608B), and larger CPUs have AES acceleration instructions. Changing hardware designs is expensive. $\endgroup$ Commented Oct 12, 2021 at 15:00
  • 3
    $\begingroup$ Rogaway allowed the patents to expire deliberately (didn't pay the renewal fees), and didn't update that page. US7949129B2 & US8321675B2 are the patents. Both are expired. $\endgroup$ Commented Oct 12, 2021 at 15:04
  • 1
    $\begingroup$ The Adjusted Expiration is when it would have expired had the fees been paid. :lawyers: $\endgroup$ Commented Oct 13, 2021 at 0:09
6
$\begingroup$

The current accepted answer is out of date and somewhat misleading. Disclaimer: I'm an author on the AEGIS Internet-Draft I'm about to talk about.

AEGIS (technically AEGIS-128L and AEGIS-256) has an Internet-Draft and TLS cipher suite name. It's in libsodium, the Zig programming language standard library, the Linux kernel, OVH routers, VPN software, and being used in internal deployments. At present, there are known implementations in 9 programming languages. There are also Project Wycheproof test vectors from Google.

Moreover, there are compelling reasons to shift from AES-GCM. AEGIS is the perfect example of that:

  • Significantly faster than AES-GCM and AES-OCB with AES-NI. Software implementations are normally faster too. Speed is one of the main reasons AES-GCM is used.
  • Easy to implement compared to AES-GCM especially but also AES-OCB. It's merely processing AES blocks, some XORs, and calling the AES round function. Additionally, the Internet-Draft has very readable pseudocode and test vectors that can be copied and pasted nicely, unlike some RFCs.
  • Better security bounds (e.g. 128-bit security against forgery attacks for a 128-bit tag).
  • Went through the CAESAR competition and is still receiving analysis. Other similarly fast algorithms like Rocca-S have received less analysis.
  • Key committing assuming the associated data cannot be attacker-controlled. AES-GCM, AES-OCB, ChaCha20-Poly1305, and so on are not, enabling vulnerabilities in certain scenarios like the partitioning oracle attack. This is an AEAD design flaw that must be fixed. However, AEGIS is unfortunately not fully committing as originally thought.
  • Larger nonces (128 bits for AEGIS-128L and 256 bits for AEGIS-256), meaning they can safely be random.
  • Leaking a state doesn't leak the key nor previous states, which is the case with some other AES-based AEADs.
  • Different associated data with the same key/nonce results in a different keystream, which provides some resistance against key reuse in different contexts.
  • Suitable as an efficient MAC independent from encryption. Capable of 128- and now 256-bit tags.

Then NIST has decided to standardise Ascon, a CAESAR finalist, for lightweight cryptography applications. The fact it succeeded in two competitions suggests one can be confident it is safe and worth using.

Finally, regarding the slow/lack of response, I would like to draw your attention to this answer to another CAESAR question. This aides the existing answer, which makes a good point about AES-GCM being widely adopted. It always takes a while for new algorithms to be adopted.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.