CAESAR Finalists Announced; What to Do With crypto_aead?

[paragonie-scott]

Now that CAESAR is nearing its conclusion, and the selection of its final portfolio is coming soon, the next step is to decide what to do with crypto_aead.

The options that seem available at first glance:

1. Choose one of the "use case 2" CAESAR finalists. (Standard AEAD; competitive with AES-GCM.)
2. Choose one of the "use case 3" CAESAR finalists. (Nonce-misuse resistant; competitive with AES-GCM-SIV)
3. Make crypto_aead passthrough to an existing implementation (i.e. XChaCha20-Poly1305).
4. Something like MEM-AEAD which surfaced too late to be considered for CAESAR.
5. Don't define a high-level crypto_aead_encrypt()/crypto_aead_decrypt() interface at all, force people to use specific algorithms.

(I'm omitting "use case 1" since that seems more suitable for libhydrogen than libsodium.)

[enkore]

(The description of the use cases can be found here)

My gut says that UC2 is not very interesting for libsodium, because it already contains a number of APIs competing with AES-GCM; adding yet another choice doesn't seen to make much sense, unless it is "special".

[paragonie-scott]

Personally speaking: I liked how NORX was designed, and I thought the ability to use large nonces as a core design feature (in v3 anyway) would save us from having to do an hsalsa/hchacha dance to extend the nonce so it can be generated randomly for each message.

My gut says that UC2 is not very interesting for libsodium, because it already contains a number of APIs competing with AES-GCM; adding yet another choice doesn't seen to make much sense, unless it is "special".

Speaking slightly biased here: I would prefer non-AES ciphers, since i.e. OpenJDK still uses software AES and "our construction has no timing side-channels as long as the block cipher doesn't" really doesn't make me feel all warm and fuzzy. There might be other platforms that use software AES too, so writing polyfills in these languages becomes needlessly difficult. :(

For use case 2, that eliminates two of the three options and leaves MORUS.

[jedisct1]

MORUS is faster than AES on most platforms, easy to implement without side channels and has 128-bit nonces.

This is pretty good. Except that besides speed, there are no practical benefits over XChaChaPoly.

If MORUS wins, and other libraries adopt it, this will be a decent choice.

If not, I'd be inclined to promote XChaChaPoly as the default construction in the high-level API.

We shouldn't jump the gun and implement any of these now no matter what. Algorithms are always tweaked after a competition ends. Not only to settle on parameters and variants, but also because they suddenly and sadly get a lot more attention than during the competition.

[ektrah]

From my point of view, libsodium currently satisfies two use cases:

1. It provides an API that does the Right Thing, without trying too much to be interoperable with anything else.
2. It provides an API for a curated set of primitives that can be used to create implementations that must interoperate with other implementations (e.g., of Noise).

(I understand that @jedisct1 intends libsodium mainly for the former, but my libsodium wrapper is geared more towards the latter.)

For the first case, there is probably little value in providing yet another primitive that has the same properties as the existing ones, so I would favor a primitive that is significantly easier to use or can do something new (or stick with one of the existing ones). For the second case, it will probably take a while until the final Caesar portfolio gains traction. It would be nice to have these primitives in libsodium then, but that is unrelated to the crypto_aead question.

[udf2457]

Don't define a high-level crypto_aead_encrypt()/crypto_aead_decrypt() interface at all, force people to use specific algorithms.

I would be inclined to comment that this option potentially breaks some of the stated objectives of libsodium, e.g.:

• "easy-to-use software library for encryption"

• "The design choices emphasize security and ease of use."

I think you ought to be weary of dropping any high-level interfaces, they should continue to be supported and modernised to ensure coders without a crypto brain continue to have sane defaults that Do The Right Thing (TM).

TL;DR ... My vote would be for a "use case 3".

[mouse07410]

My $0.02:

Do nothing with 'crypto_aead_encrypt()'. It is good as-is. CAESAR outcome is irrelevant here.

Ideally I'd want the ability at run-time to tell the library what algorithm suite I want to use in the subsequent invocations of it's crypto primitives. E.g, ECDSA-384+AES256-OCB, or EdDSA+AES-GCM-SIV... But as I see the complications this would introduce, I'm not voicing this desire too loudly.

[jedisct1]

xchachapoly is probably the best choice.