2.0.0 release candidate

[LoupVaillant]

I have pushed the new AEAD interface. Hopefully it will be really stable this time. (I believe it will be because it is now compatible with Libsodium's crypto_aead_xchacha20poly1305_ietf_encrypt(), to the point where I was able to make test vectors.)

Since this change breaks everything, I took the opportunity to tweak the incremental interface. The subsequent compile time errors may help users figure out why their data isn't decrypting itself any more. Or maybe it will just piss them off. I'm not sure.

I'm thinking of renaming crypto_aead_lock() into crypto_lock_aead() (and crypto_aead_unlock into crypto_unlock_aead). This would have 2 effects:

• Naming wise, this would make everything start by crypto_lock or crypto_unlock. This may or may not matter. I just like being consistent, and this was a tiny inconsistency.
• Versioning wise, this change will trigger compile time errors for virtually every user. Is signalling the incompatibility this way actually a good idea, or will it just piss them off, and I'd better not force them to change their source code? (I know I already did this for the incremental interface, but I expect virtually no one had the time to actually use it yet. Doing the same to the monolithic interface will affect virtually everyone.)

@CuleX, @mikejsavage, @secworks, @konovod, what do you think?

[secworks]

I think following/using the construct from RFC7539 is a really good move.

[konovod]

Telling in readme about incompatibility is IMHO enough, no need to change names. On the other hand, even big libraries like to change names, I don't think that can piss off anyone. So if renaming is useful for consistency - do it.

[LoupVaillant]

@secworks, note that I did make a small departure from RFC7539, namely using XChacha20 instead of the IETF version of Chacha20 (with a 96-bit nonce and 32-bit counter). This effectively means processing an additional Chacha block for each message. But I judged this overhead was worth the extra convenience and security that comes with being able to use random nonces. (Counters are stateful. Random stuff is effectively stateless, and thus leaves less room for error.)

I may add support for the official IETF version, but only if some user begs for it with a compelling use case (even my block based encrypted file system isn't one). Otherwise they can still patch Monocypher (it's 3 lines of code).

@konovod, thanks. I'll probably change the names before release, unless someone else points out a good reason not to.

[ghost]

Versioning wise, this change will trigger compile time errors for virtually every user. Is signalling the incompatibility this way actually a good idea, or will it just piss them off, and I'd better not force them to change their source code? (I know I already did this for the incremental interface, but I expect virtually no one had the time to actually use it yet. Doing the same to the monolithic interface will affect virtually everyone.)

I'm in favor of the rename for the sake of consistency when we have the chance. The code is going to break and that will prompt developers to actually check the changelog instead of just pulling in 2.0.0. We'll also have to bump the soname since the API is now broken between shared libs on 1.1.0 and 2.0.0.

[LoupVaillant]

Oh, crap, the .so wasn't versionned. I should have bumped it already for 1.1.0. How about the following?

1. output monocypher.so.2.0 (for the upcoming 2.0.x releases)
2. output a monocypher.so symbolic link.

We'll also need to decide on a policy for shared objects: are Major/minor versions enough, or do we need patch versions as well? Should we bump the .so version number for mere patches, or should we overwrite it?

[LoupVaillant]

@CuleX, could you review that last commit? I want to make sure I'm observing the relevant standards.

[ghost]

Re soname handling: See https://autotools.io/libtool/version.html for the principles of versioning. There's no real uniform standard, though. Some libraries get away with a single integer at the end.

[mikejsavage]

If you want to make everyone aware of breaking changes, you could rename the header to monocypher2.h :d

since you're breaking stuff you could also break this:

// Deprecated name
#define crypto_poly1305_auth crypto_poly1305

[LoupVaillant]

Oh yeah, didn't remember that deprecation, thanks. Doing it right away. Then we should be good to go.

[LoupVaillant]

@mikejsavage, could you review my last commit? I've replaced the code by informal text.

[LoupVaillant]

Now we should be good. I'll release 2.0.0 in a couple hours.

[mikejsavage]

need to update $ tar -xzf monocypher-1.1.0.tar.gz on the website, otherwise it looks good!

[LoupVaillant]

Oh, I always forget them. Will do that tonight.