On Fri, Feb 21, 2020 at 8:09 AM Mikhail Komarov via Boost
...wether there is still any interest in cryptography library for Boost and is there any sense to show the community what do I have for now?
I think there is utility in a cryptography _framework_ but not necessarily a cryptography _library_. Implementing cryptographic algorithms is something that is best left to experts. Generally, a new implementation of an algorithm is worse than an old implementation simply because the old implementation has had more provably-correct hours in operation. What I would like to see in a _framework_ is a set of named requirements. Examples: * BlockCipher * MessageAuthenticationCode * CompressionFunction * OneToOneMapping etc... This is more of a written / documentation specification than C++ code, although having some C++ metafunctions to check that types meet syntactic requirements is nice. With a set of named requirements in place, building a cryptography _library_ then becomes a mechanical operation: implement the named requirements in terms of already-existing, proven correct libraries. Whether this becomes a boost library or not is not particularly important, as most users do not and should not be casually reaching for cryptographic primitives. For the limited set of users who do need to use these primitives responsibly, accessing them from a library that isn't Boost, is not a barrier. Thanks