Re: [boost] Cryptography for Boost.

newer
GSoC, Boost C++ and Slack channel

older
Start with Boost Multiprecision

Kenneth Porter

22 Feb 2020 22 Feb '20

6 a.m.

--On Friday, February 21, 2020 6:21 PM +0300 Mikhail Komarov via Boost 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.

Show replies by date

Mikhail Komarov

22 Feb 22 Feb

9:31 a.m.

New subject: Cryptography for Boost.

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 wrote:

--On Friday, February 21, 2020 6:21 PM +0300 Mikhail Komarov via Boost 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

Mike

24 Feb 24 Feb

10:34 a.m.

New subject: Cryptography for Boost.

...

Gesendet: Samstag, 22. Februar 2020 um 10:31 Uhr Von: "Mikhail Komarov via Boost"

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

Alexander Grund

11:42 a.m.

New subject: Cryptography for Boost.

...

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

degski

26 Feb 26 Feb

3:41 p.m.

New subject: Cryptography for Boost.

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

Vinnie Falco

11:45 p.m.

New subject: Cryptography for Boost.

On Mon, Feb 24, 2020 at 3:42 AM Alexander Grund via Boost 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

Kostas Savvidis

24 Feb 24 Feb

4 p.m.

New subject: Cryptography for Boost.

...

On Feb 24, 2020, at 12:34, Mike via Boost 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/

Mike

25 Feb 25 Feb

9 a.m.

New subject: Cryptography for Boost.

...

Gesendet: Montag, 24. Februar 2020 um 17:00 Uhr Von: "Kostas Savvidis via Boost"

...
On Feb 24, 2020, at 12:34, Mike via Boost 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

Gavin Lambert

26 Feb 26 Feb

12:21 a.m.

New subject: Cryptography for Boost.

On 25/02/2020 22:00, Mike wrote:

...

...
Gesendet: Montag, 24. Februar 2020 um 17:00 Uhr Von: "Kostas Savvidis via Boost"

...
On Feb 24, 2020, at 12:34, Mike via Boost 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.

1735

Age (days ago)

1739

Last active (days ago)

List overview

Download

8 comments

8 participants

participants (8)

Alexander Grund
degski
Gavin Lambert
Kenneth Porter
Kostas Savvidis
Mike
Mikhail Komarov
Vinnie Falco