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?
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.
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.