Re: Cryptography for Boost. +1!

From: degski (degski_at_[hidden])
Date: 2020-02-26 22:26:20

On Wed, 26 Feb 2020 at 11:07, Rainer Deyke via Boost <boost_at_[hidden]>
wrote:

> 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