On Mon, 24 Feb 2020 at 01:53, Ggh via Boost wrote:

+1

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. Of course it's possible to put this functionality into Boost, but for what gain (other then the dependency explosion)? Also for safety, and usefulness, it [the lib] should have a c-api. This also does away with all the issues regarding c++std's, particularly std::string is affected by this (and probably used quite a bit (or could be used quite a bit), depending on which std is in effect. degski -- @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 Wed, 26 Feb 2020 at 11:07, Rainer Deyke via Boost 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

Let me give you a perfect use-case. Beast Lounge is a massively multiplayer Blackjack MMO I am working on (https://github.com/vinniefalco/BeastLounge). No real money, and to keep things simple , very little information is kept on the server. Instead the user's character sheet (containing things like their achievements and game stats) is stored in their browser. To make this secure, the server serializes the character sheet, adds a timestamp, and then emits a digital signature using an asymmetric encryption algorithm. To avoid a replay attack (i.e. rolling back the character sheet) the server remembers the highest timestamp for each player id. Anyway since this thing is designed for teaching and for forking and building your own things, it would be ideal if it could use cryptographic aglorithms which have modern C++ interfaces. libsodium is of course out of the question since it is in C. The wrappers for it aren't great either. Cryptopp is wonderfully broad in functionality, but its C++ interfaces leave something to be desired. For example there is no way to specify the allocator for a BufferedTransformation. To reiterate my position, I believe there is room for a "cryptography framework" library in Boost which does not try to reimplement any algorithms but instead provides a robust set of named requirements, and a set of utility types and algorithms. Then we can pick and choose the already-existing implementations (perhaps from Cryptopp and libsodium), and adapt their interface to our clean named requirements to bring it up to the level of interface quality users expect from Boost libraries. The details of how these external implementations are integrated into Boost, updated in response to security reports, or replaced can be worked out later. Beast already has SHA, Cha-Cha, and base64 conversions as implementation details in order to implement the WebSocket protocol. Base64 is also needed for implementing Basic Authentication, which users have to do themselves since Beast is low-level. The SHA algorithm is both a compression function and a message authentication code. ChaCha (and the related Salsa20) are stream ciphers. While base64 is a codec. We would be doing C++ a solid by creating well defined named requirements for these interfaces: * Digest * CompressionFunction * StreamCipher etc... With a good set of concepts / named requirements, and the corresponding wrappers around well-tested already existing algorithms from other libraries (I'll use libsodium and Cryptopp as the examples again), we can offer a Boost library that "does cryptography", but without reinventing any algorithms, using mostly upstream code, and with clean well-thought interfaces that appeal to the sensibilities of modern C++ users. Thanks

On 26.02.20 23:26, degski via Boost wrote:

On Wed, 26 Feb 2020 at 11:07, Rainer Deyke via Boost 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.

Looks like you missed the point of my two categories. These are not categories of libraries, but categories of needs that users have, which an individual library may or may not meet. For example: Let's say I want to write a program that reads encrypted zip files. I therefore need a library that provides an implementation(s) of the specific algorithm(s) used to by encrypted zip files, or I need to provide my own. It doesn't matter for the purpose of my program that the default ZipCrypto used by zip files is a terrible, terrible encryption algorithm that should never be used. The file is already encrypted, the damage is already done, and I just want to decrypt it. Crypto++ doesn't provide a ZipCrypto implementation, but it does provide several other algorithms that can also be used to encrypt zip files. libsodium, on the other hand, treats encryption as a black box - it only provides one secret-key encryption algorithm, and you have to search the documentation thoroughly to even find out which algorithm that is. -- Rainer Deyke (rainerd@eldwood.com)

On 28.02.20 16:26, degski via Boost wrote:

Hmm, you're implying that you want to use data from one crypto-lib (or any old way of creating that data), and then use (decrypt) that with whatever Boost produces. If doing this seriously and the data are (behind the scenes) encrypted using OpenSSL, one should use OpenSSL to decrypt in my opinion (common sense), then any problem-fixes get correctly pushed downstream.

In my example, I don't know or care which how the encrypted zip files were generated. Could be WinZip or PKZip, both of which are closed source. The encryption method is specified by the file format, not by program which generates the file.

This does not seem a very good idea in the first place as the any old-way-of-creating-that-data might not exactly be what you imagine it to be. Also the zip example is inherently bad, since this is something totally different from encryption, but yes for a C++dev, implementing this functionality using streams, it all looks the same, but I think these things are substantially different.

You do realize that PKZip has supported encrypted (aka password-protected) zip files since 1993, right? And strong encryption since 2002. This is entirely separate from the compression used. -- Rainer Deyke (rainerd@eldwood.com)

Do you really think Boost has to cater for this kind of situations (some nut-case with a pkzip file. I would do a one time unzip with pkzip, and re-zip with lzma or something of that kind), while earlier today, the suggestion of having a signed size_type is readily rejected. I doubt there are many even bigger nut-cases that still keep generating pkzip-archies in 2020)? Meanwhile zip files are still the single most popular archive format on

On 28.02.20 17:53, degski via Boost wrote: the internet. Go to the boost download page and you'll find a zip file as the "lowest common denominator" download for Windows. Go to https://itch.io/ and you'll find thousands of indie games, the vast majority of them packaged as zip. Download a Java jar file and you'll be downloading a zip file with a different extension. Same with .docx. Granted, most of these zip files aren't encrypted. And if I really wanted to read from a zip file, I'd use a third-party library like libzip or libarchive to do the heavy lifting. It was just an example to demonstrate that there are use cases for specific encryption methods, even when those algorithms are known to be method. (Implementing TLS would be another example, although again one where higher-level libraries exist. Reading obscure encrypted file formats would a more compelling example, because there often isn't a readily available library around to do the heavy lifting, but the very nature of obscure file formats is that they are obscure, i.e. I can't think of any off of the top of my head.) -- Rainer Deyke (rainerd@eldwood.com)

On 28.02.20 20:34, degski via Boost wrote:

Oh, oh, oh, would you really consider not using OpenSSL?

OpenSSL is in fact a popular choice for category 2 cryptography, although the heartbleed debacle has made me somewhat hesitant to use it. -- Rainer Deyke (rainerd@eldwood.com)

On 29.02.20 07:23, degski via Boost wrote:

I was referring to this before, and in this case we are talking about the (most?) widely used foss-lib in this field (both C and C++), still you're hesitant to use it [I don't mean [at all] you're wrong, just that you're hesitant]. How hesitant do you think anyone, but you, would be towards anything implemented from scratch (even with a pedigree like Boost)?

I'm not arguing for, or against, any particular strategy for Boost.Crypto, or if it should exist at all. My contribution to this thread is limited to pointing out that libsodium is not sufficient for all crypto needs. Something else (like OpenSSL!) is needed when one doesn't control both endpoints and therefore needs to use a specific crypto method instead of letting the library decide. For my personal crypto needs, I am happy with libsodium for now, despite its limitations. I may need TSL in the future, in which case I'll take a look at the open source libraries providing TSL, including but not limited to OpenSSL. I don't need a C++ implementation, and I don't need a C++ wrapper. -- Rainer Deyke (rainerd@eldwood.com)

On Thu, 27 Feb 2020 at 10:08, Rainer Deyke via Boost wrote:

... and you have to search the documentation thoroughly to even find out which algorithm that is.

You are unfortunately right about this, I hadn't looked at the docs for some time, it has changed, previously this was all very much more explicit, but the examples and example use-cases, we're not there, so there was some progress, and, I agree with you, we also regressed a bit. There appears to be a new star, https://github.com/jedisct1/libhydrogen, they promise better, but I don't see it, yet. degski -- @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

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, February 28, 2020 3:47 PM, Vinnie Falco via Boost wrote:

On Fri, Feb 28, 2020 at 7:35 AM degski via Boost boost@lists.boost.org wrote:

...

https://github.com/jedisct1/libhydrogen

What is this nonsense? A library that only has two algorithms (Curve25519 and Gimli?) seems pointless to me.

Thanks

Everyone wanted audits by professionals. Less primitives means easier audits. That library provides everything useful: symmetric encryption, public-key encryption, digital signatures, and even an API for a key exchange protocol. One of the authors of Gimli/curve25519, Daniel Bernstein, as long argued for less options and fewer APIs for cryptography to prevent misuse. Having options to select block-cipher-modes with AES is nice, but has been used incorrectly frequently due to subtle differences. This library/cipher/curve comes from a long line of experience of prior mistakes. Boost providing the kitchen sink of cryptography is only the correct approach if the goal is to provide mass interoperability with other systems. Otherwise, less is more. I've looked at lots of cryptography code, this more sane to read than much of the competitors. The biggest risk is the fairly new cipher and possibly the AEAD design (probably based on poly1305?). x25519 is being considered for major standards at this point. Lee