On Wed, 26 Feb 2020 at 11:07, Rainer Deyke via Boost
On 26.02.20 16:14, degski via Boost wrote:
I don't think this is a good idea. Crypto is very hard and 'generic' crypto is not useful to amateurs (that's the intended audience for this Boost-component), imho (unless one insists on doing it wrongly). A crypto-lib should not be generic, but should be guiding and advising (this is not a Boost-approach to things, in general), like 'libsodium' does.
There are two categories of cryptography usage. In the first category, one can choose the algorithm because one controls both endpoints. In the second category, the algorithm is already decided by the other endpoint. The guidance provided by libsodium is great for the first category. The large selection of algorithms provided by Crypto++ is great for the second category.
I like and use libsodium, but I am under no illusions that it is sufficient for everybody's, or even every amateur's, cryptography needs.
An amateur should not use that second category of lib in my view (and a non-amateur won't), the number of ways to f-it-up is just too many. I can agree that it's not sufficient for all, but whatever comes out at the other end, should be made up of building blocks that are libsodium like. It's just so much easier to wrap a c-lib. What seems rather important to me is that upgrading the C++ standard does not touch on anything as sensitive as crypto (iff depending on a c-api). If I would be a CIO, I would sleep a bit better. Mind you, there is also no c++-lib that has been audited, even though they exist for many years, like Botan , CryptoPP or libtomcrypt. And in view of the fact that serious bugs still (!!!) pop up in OpenSSL, just shows (and proves imho), that crypto should not be developed in an environment that's any larger than that and starting a boost thing from scratch seems to be along road till maturity (and then an even longer period till adoption (I'm lookin at Vinnie here, who takes these things in consideration, as far as I understood from his posts). degski