GCM (ie. AES-GCM) has the following problems, which extended variants - those that deterministically randomize (key,nonce) pair - do not solve:<p>Inability to encrypt more than 64Gb with the same (key,nonce) pair.<p>Lack of commitment (whether key-commitment, or key+nonce+ad commitment).<p>If one is seriously considering breaking away from existing GCM standards to create yet-another-standard, such proposal would need to offer improvements in all areas (ex. a proposed standard for converting any AEAD into streaming chunk-based AEAD with practically unlimited message sizes under the same (key,nonce) and unlimited message counts.<p>GCM-256 is ubiquitous and is often the preferred choice for all the reasons mentioned by the author, but that very argument is what makes non-standard GCM with 11 AES-rounds silly.<p>In 2023 we should be working on new standards that "wrap" existing crypto-primitives (which are already implemented/available in countless hardware-accelerated libraries/APIs) to get additional features/benefits/capabilities - not musing about AES with 10+1 rounds or SHA-512-really-fast with 80-1 rounds..
Has there been any situation in which 10 rounds would be utterly broken but 14 would give you "enough" of a security margin? My impression is that once you've managed to break a cipher enough to get that many rounds, you've also discovered a linear-time attack on that cipher[0]. Adding a mere 28% slowdown on that attack won't help.<p>[0] "Linear time" means O(n), which is computer science speak for "f(n) = an, but we ignore the a because we're only interested in the fastest growing component of the function". In some cases the a is so large as to make the algorithm in question not feasible for ANY size. Let's just pretend the attacker doesn't have that problem.
> we might wish OCB hadn’t been patented<p>Rogaway says he has released all his OCB patents into the public domain[1], so it sounds like OCB might be an option for greenfield projects? OTOH, I don’t see why you’d use any kind of AES in a greenfield project outside the surreal FIPS world, given how absolutely miserable constant-time software for it is. (ChaCha is kind of miserable when you don’t have at least a 32-bit ALU with a barrel shifter—that is on exactly the kind of platforms where table-based AES might actually be constant-time—but I’m not sure that’s a good enough reason.)<p>[1] <a href="https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/" rel="nofollow noreferrer">https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3...</a>
>In 2023, the way to use AES is AES-GCM. Anything else is very unlikely to make sense.<p>Encrypt-then-MAC remains the most conservative and theoretically secure option.<p>Leaving aside the (very serious) nonce reuse issue, the cracks on non-committing AEADs in general (such as AES-GCM) are already showing. Partitioning oracle attacks affect all of them: <a href="https://crypto.stackexchange.com/questions/88716/understanding-the-impact-of-partitioning-oracle-attacks-on-stream-ciphers" rel="nofollow noreferrer">https://crypto.stackexchange.com/questions/88716/understandi...</a><p>There are also other minor GCM-specific issues (weak keys etc.). None of the issues are cypher-breaking, but I wouldn't say that AES-GCM is automatically the best choice for everything.
From the NIST doc for GCM: <a href="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf" rel="nofollow noreferrer">https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...</a><p>The IV can be any length up to 2^64-1. The reason for picking 96-bit IVs is that other values require an extra invocation of GHASH (page 15). The document recommends 96-bit for interoperability but that's by no means a requirement.<p>The X part is thus in theory already allowed.
How does it compare to XChachaPoly? I guess it's only useful when you are sure to have CPU support for AES and not having to deal with the annoyance of non constant time software implementations. I feel like XChachaPoly has the benefit of being annoyance free (constant time by design even in software implementation), fairly fast even without hardware support and to exists, so it's probably a good choice for most use cases.<p>EDIT: my question is probably more clearly asked as: what's wrong with XChachaPoly that is solved by this new construct?
I sketched out an extended nonce construction using AES-GCM with CBC-MAC last year (both of which are permitted by FIPS).<p><a href="https://soatok.blog/2022/12/21/extending-the-aes-gcm-nonce-without-nightmare-fuel" rel="nofollow noreferrer">https://soatok.blog/2022/12/21/extending-the-aes-gcm-nonce-w...</a><p>I never considered only using 11 rounds, though. That'd have a significant performance impact if we could.
AES-256-GCM runs at well above 10 GB/s per core on semi-modern desktop/server CPUs and the 128 variant isn’t actually 40% faster iirc. I think it was like 11 vs 13 GB/s on the same hardware, not what 10-vs-14 rounds would seem to imply. Even chapoly is only around 3-4x slower.<p>(That’s gigabytes per second, not gigabits)
AEGIS is being standardized, and solves many of the AES-GCM issues while being significantly faster.<p><a href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/" rel="nofollow noreferrer">https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/</a><p><a href="https://github.com/jedisct1/aegis-128X">https://github.com/jedisct1/aegis-128X</a><p>Many implementations are available, including for Go: <a href="https://github.com/jedisct1/draft-aegis-aead#known-implementations">https://github.com/jedisct1/draft-aegis-aead#known-implement...</a>
Do you _really_ need AES256 though? Just a large computation overhead while AES128 is extraordinarily secure already.<p>The conversation about nonce sizes is 100% on point however. Why isn’t it at least the size of the key?
> If for example an application encrypts 2^48 messages under different 128-bit keys, and all messages start with the same few bytes, an attacker can build a lookup table, try and lookup the ciphertext of 2^64 keys, and have a 2^-16 chance to decrypt one message. Not good.<p>This is satire right? The computational and storage requirements to preform such an attack to just get a small probability of decrypting one message seem ludicrous.