This is a great proposal.

It would have been a good opportunity to leverage the AES-PRF construction (see tosc.v2018.i2.161-191 in addition to the original paper), whose overhead is negligible. But unfortunately, FIPS restrictions is why we can't have nice things.

If FIPS compliance is not a requirement, AEGIS (AEGIS-256 in particular) is a more efficient alternative and on the standard track.

But when only FIPS-approved things can be used, AES-GEM is a nice way to solve a very common problem.

Zig implementation: https://github.com/jedisct1/zig-aes-gem

I like these proposals to extend the current systems. They will probably never lead anywhere, but they are still a nice reminder that we are still learning things.

My vacation plans include trying to grok at least a little bit of the xocb paper: https://dl.acm.org/doi/10.1007/978-3-031-30634-1_18

How does this compare to other GCM alternatives such as AES-SIV and AES GCM-SIV?

Don't see also, because it's completely unrelated, GEM AES: https://www.seasip.info/Gem/aes.html

Remember: You should never been on the bleeding edge with crypto. It takes years to find attacks in ciphers, and more years to find attacks in implementations.

Never roll your on crypto. Always move slow and trust the process.

This is not a new cipher. The approach is actually very conservative.

Moving slow is fine, but the reality is that the current options are not great for today's use cases. They're very easy to use insecurely.

Ironically, this is exactly what I'm warning about.