Yes, I believe that's possible, though not necessarily with the same performance. I built magicnonce [1] explicitly with two properties in mind: * the simplest

Yes, I believe that's possible, though not necessarily with the same performance. I built magicnonce [1] explicitly with two properties in mind: * the simplest possible synthetic nonce design that's "obviously" correct for some useful value of correct. * uses only explicitly exported libsodium APIs. It's an off-line scheme like SIV, because the users I'm targeting don't care about on-line schemes. If you really care about on-line schemes, I think the simplest, most practicable solution right now is to just use an large nonce scheme (like secretbox) filled with random bits. To give you an idea about performance and to continue with the author's gracious use of unflattering benchmarks, my Clojure+FFI code is about 20% slower than his AES-SIV-PMAC code. It should probably just publish it on IACR instead of just in a random module of my libsodium binding. [1]: https://github.com/lvh/caesium/blob/master/src/caesium/magicnonce/secretbox.clj https://github.com/lvh/caesium/blob/master/src/caesium/magic... One could argue that it is still desirable to have fast, AES-based algorithms, and I think that both this article and related work (e.g. the AES-GCM-SIV paper) do a reasonable job of making that point. For example, my cost function assumes libsodium is free but implementing any nontrivial crypto is very expensive. If that's not true, say, in resource-constrained embedded environments (libsodium not free, developing crypto par for the course), I can totally see why you'd end up with SIV or SIV-PMAC: you just need one really fast implementation of an established primitive (AES). Really anywhere where the platform hasn't tilted the table in favor of GCM by having CLMUL instructions, AES-SIV-PMAC should dominate both from a performance and safety perspective.