Re: [boost] Cryptography for Boost.
--On Friday, February 21, 2020 6:21 PM +0300 Mikhail Komarov via Boost <boost@lists.boost.org> wrote:
It's been some time since I've started developing so-called clean C++ cryptography implementation for my organization's internal purposes. It was intended at first to be a cryptography framework fulfilling special cryptography schemes requirements, but eventually it has evolved into a full-featured suite, actively using and, sometimes, even based on Boost libraries. This turned out to be fine way to serve the Boost (and entire C++) community and to assemble a Boost version of a suite.
How does it fit in with openssl and SASL? I'd been contemplating dipping my toes into a Windows email client and openssl has a native Visual Studio port but I don't know of one for any SASL libraries. So the available open source email libraries tend to be *nix-oriented and have to be built with a ported *nix toolchain.
What you are talking about is quite a complex set of protocols (SASL) and it can (and will) be built on top of the suite. But unfortunately for now the suite is not that full-featured. Okay. I consider such a small of responses as if there was no point in discussing hypothetical library without actual code. I’ill come up with a Boost-ified version hopefully next week and maybe that would bake some discussion. Sincerely yours, Mikhail Komarov nemo@nil.foundation
On 22 Feb 2020, at 09:00, Kenneth Porter via Boost <boost@lists.boost.org> wrote:
--On Friday, February 21, 2020 6:21 PM +0300 Mikhail Komarov via Boost <boost@lists.boost.org> wrote:
It's been some time since I've started developing so-called clean C++ cryptography implementation for my organization's internal purposes. It was intended at first to be a cryptography framework fulfilling special cryptography schemes requirements, but eventually it has evolved into a full-featured suite, actively using and, sometimes, even based on Boost libraries. This turned out to be fine way to serve the Boost (and entire C++) community and to assemble a Boost version of a suite.
How does it fit in with openssl and SASL? I'd been contemplating dipping my toes into a Windows email client and openssl has a native Visual Studio port but I don't know of one for any SASL libraries. So the available open source email libraries tend to be *nix-oriented and have to be built with a ported *nix toolchain.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gesendet: Samstag, 22. Februar 2020 um 10:31 Uhr Von: "Mikhail Komarov via Boost" <boost@lists.boost.org>
Okay. I consider such a small of responses as if there was no point in discussing hypothetical library without actual code. I’ill come up with a Boost-ified version hopefully next week and maybe that would bake some discussion.
Don't think it has to be boostified but some code and examples to get an idea about the features and API design would indeed be useful. I can't speak for the boost community, but I guess another big question mark is probably long term support and response to security vulnerabilities. I wouldn't be surprised, if people are reluctant to base the security of their communication on a lesser known library, when they can't be confident that bugs and vulnerabilities are getting fixed quickly. Best Mike
I can't speak for the boost community, but I guess another big question mark is probably long term support and response to security vulnerabilities. I wouldn't be surprised, if people are reluctant to base the security of their communication on a lesser known library, when they can't be confident that bugs and vulnerabilities are getting fixed quickly.
I'd fear the same. Common usage of Boost is: Install specific version and stick to it until absolutely required to upgrade. --> This longevity is not suitable for a crypto library which need to adapt to new threats quickly. I'd hence suggest to make this a standalone version with CI tested against various boost versions (at least min. required, latest release and (opt) master) and use proper semantic versioning as well as good integration with build systems (I'd suggest CMake and/or Meson) However I can imagine that some Boost libraries may use that, especially if it integrates well enough
On Mon, 24 Feb 2020 at 05:42, Alexander Grund via Boost < boost@lists.boost.org> wrote:
I can't speak for the boost community, but I guess another big question mark is probably long term support and response to security vulnerabilities. I wouldn't be surprised, if people are reluctant to base the security of their communication on a lesser known library, when they can't be confident that bugs and vulnerabilities are getting fixed quickly.
I'd fear the same. Common usage of Boost is: Install specific version and stick to it until absolutely required to upgrade.
--> This longevity is not suitable for a crypto library which need to adapt to new threats quickly.
I'd hence suggest to make this a standalone version with CI tested against various boost versions (at least min. required, latest release and (opt) master) and use proper semantic versioning as well as good integration with build systems (I'd suggest CMake and/or Meson)
Yes, this, but why have (in case it's just a stand-alone component) a Boost component in the first place? This assumes thorough understanding of crypto (from the consumer), std-s are a problem and a c-api is the way to go, adopt some good ways-of-working, regarding crypto, use libsodium, or openssl. Also libsodium is actively developed and the devs are not distracted by C++, they can also not introduce nasty things/bugs related to C++, which is easy, the infamous foot-gun. You know what you get and it is guaranteed to work, even with VC-6 (or earlier) or on embedded. degski
However I can imagine that some Boost libraries may use that, especially if it integrates well enough
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- @realdegski https://brave.com/google-gdpr-workaround/ "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
On Mon, Feb 24, 2020 at 3:42 AM Alexander Grund via Boost <boost@lists.boost.org> wrote:
I'd fear the same. Common usage of Boost is: Install specific version and stick to it until absolutely required to upgrade.
Note that this problem already exists, because of Boost.Beast, which has security implications. I have already fixed one security-related problem. The solution here is not to avoid Boost but to make sure that we have a workflow in place which allows Boost to be hotfixed (we have that already). As for users being lazy, there is no solution for that other than to remind them. Lazy users is not a problem for us to solve, nor is it something that should guide our development path. Thanks
On Feb 24, 2020, at 12:34, Mike via Boost <boost@lists.boost.org> wrote:
I can't speak for the boost community, but I guess another big question mark is probably long term support and response to security vulnerabilities.
+1 --- If it is not written by people with academic credentials in cryptography and does not come with an independent security audit from the same it should be a clear no go. Best, Kostas Savvidis ============================================================================================ Institute of Nuclear and Particle Physics NCSR Demokritos https://github.com/kotika/random <https://github.com/kotika/random> https://mixmax.hepforge.org <https://mixmax.hepforge.org/>
Gesendet: Montag, 24. Februar 2020 um 17:00 Uhr Von: "Kostas Savvidis via Boost" <boost@lists.boost.org>
On Feb 24, 2020, at 12:34, Mike via Boost <boost@lists.boost.org> wrote:
I can't speak for the boost community, but I guess another big question mark is probably long term support and response to security vulnerabilities.
+1 --- If it is not written by people with academic credentials in cryptography and does not come with an independent security audit from the same it should be a clear no go.
I have to wonder though: Did/does Openssl/libressl actually satisfy those criteria? I mean, we are (hopefulley) not talking about inventing new crypto algorithms, but rather have a new implementation for existing ones. I'm not sure, if you really need a degree in cryptology to write one (unless the specs are so complicated that no one else can understand them of course). I'm much more concerned with e.g. avoiding the likes of heartbleed and making sure one has a true source of random numbers. But yes, such a library would definetly need an audit by experts in the field to make sure the algorithms are implemented correctly. And as Alexander pointed out, there needs to be a way to patch bugs and update the lib outside of the regular boost distribution (Btw. that is a general concern I have with libraries that process network traffic) Best Mike
Best, Kostas Savvidis
============================================================================================ Institute of Nuclear and Particle Physics NCSR Demokritos https://github.com/kotika/random <https://github.com/kotika/random> https://mixmax.hepforge.org <https://mixmax.hepforge.org/>
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 25/02/2020 22:00, Mike wrote:
Gesendet: Montag, 24. Februar 2020 um 17:00 Uhr Von: "Kostas Savvidis via Boost" <boost@lists.boost.org>
On Feb 24, 2020, at 12:34, Mike via Boost <boost@lists.boost.org> wrote:
I can't speak for the boost community, but I guess another big question mark is probably long term support and response to security vulnerabilities.
+1 --- If it is not written by people with academic credentials in cryptography and does not come with an independent security audit from the same it should be a clear no go.
I have to wonder though: Did/does Openssl/libressl actually satisfy those criteria?
FWIW, when I need something outside of TLS, I usually reach for Crypto++ (https://www.cryptopp.com/ ). It has been formally FIPS validated in the past, but the latest version hasn't been re-validated (since that requires constant $$$). Overall though I agree with Vinnie -- Boost should in general not reimplement any algorithms; at most it should provide a unifying interface around existing proven libraries.
participants (8)
-
Alexander Grund -
degski -
Gavin Lambert -
Kenneth Porter -
Kostas Savvidis -
Mike -
Mikhail Komarov -
Vinnie Falco