The MSB on these libraries isn't the author, but rather the intent of the library. Libsodium is designed to get you to basic core cryptographic functionality with the fewest possible landmines. Crypto++ is designed to be an interface to the maximum number of constructions and primitives. Those are radically different goals, and almost everybody is better served by the former.

For me, libsodium has one problem... grr... not exactly problem, but peculiarity, which is not mentioned in docs anywhere.

libsodium doesn't put any metadata (including library and/or construction "version") in any its results, like boxes, keys, etc. So, there is no mechanism for versioning and backward compatibility.

So, it is so-so Ok for real time communication between two installations of software product (and even then two ends could have different versions of software and/or library used!), but it is not suitable for long-time storage or communication between different systems.

You store your "boxed" backup [keys] on disk. You want to read it 15 years later. How could you be sure, that libsodium didn't change algorithms in these 15 years? You need exactly same version of library that created this "box".

And even application which is aware of this problem could not properly solve this: it could record & check libsodium version and refuse to work with "old" data, but how could it enforce future libsodium to read product of old one, as there is no any provision for this in API?

libsodium is too simple for many tasks.

Has libsodium actually made backward incompatible changes to its formats?

Not YET, but there are no any promises too.

New API like secretstream includes algo into API names, so, I hope, it is "stable forever", but it is rather new feature.

Basic APIs like "crypto_secretbox" are "black boxes" and there are no any guarantees spelled out. Algorithms are mentioned in documentation, though.

What will do libsodium if used algorithm will be broken? I don't know.

I don't have the source right now, but I believe a lot of the algorithms used are set in build time #defines so it might be possible to capture them at build time and store them with the encrypted data.

Means you'd have to find a compiled lib with the exact same settings to decrypt them though.

If a high-level API ever has to be changed, that will be libsodium 2.0.

In 12 years, libsodium never had any breaking API changes, even though I don't like the NaCl API much (especially usage of `unsigned long long` instead of `size_t` for sizes).

API stability is something I'm very committed to, in all my software. APIs can always be improved. But from a developer perspective, a suboptimal but stable API is far better than something that requires changes to all your applications every time the dependencies are updated.

This is documented in the FAQ.

No.

I’m not casting shade on anyone, but “highly reputable engineer” is not how I would describe Wei Dai. “Early thinker in this field, respected for his opinions” might be more accurate.

Especially if you are directly comparing against libsodium and Daniel Bernstein who is a widely respected engineer whose work is widely used and heavily reviewed.

Daniel Bernstein is not the creator of libsodium. Libsodium is based on his work on <https://nacl.cr.yp.to/> which is not the same.

Frank Denis, maintainer of libsodium, is also a reputable engineer.

Libsodium is a fork of nacl.

It's certainly not the same as Nacl. But I'd reiterate: the point here isn't trust in the library's author. It's the intent of the library.

Because extending trust usually works retrospectively?

Or

which battle tested applications exist today using crypto+, that illustrate it's a better choice than what sofar held up under libsodium (which is a lot)?

My comment was intended to be constructive, not to spark a flamewar. If you compare Crypto++ and Libsodium, you’ll notice they were created in different decades. This reflects that, at one point, C++ developers predominantly used Crypto++, while later, Libsodium emerged as an alternative.