Cryptography for Boost.
Hello! Cryptography for Boost. Again. 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. So this letter is about 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? Sincerely yours, Mikhail Komarov nemo@nil.foundation
+1 Quoting Mikhail Komarov via Boost <boost@lists.boost.org>:
Hello!
Cryptography for Boost. Again.
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.
So this letter is about 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?
Sincerely yours,
Mikhail Komarov nemo@nil.foundation
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tell me, and I forget. Ask me, and I discover...
On Mon, 24 Feb 2020 at 01:53, Ggh via Boost <boost@lists.boost.org> 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 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. -- Rainer Deyke (rainerd@eldwood.com)
On Wed, 26 Feb 2020 at 11:07, Rainer Deyke via Boost <boost@lists.boost.org> 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
Sorry for dragging on! On Wed, 26 Feb 2020 at 16:26, degski <degski@gmail.com> wrote:
On Wed, 26 Feb 2020 at 11:07, Rainer Deyke via Boost < boost@lists.boost.org> wrote: Mind you, there is also no c++-lib that has been audited, even though they exist for many years, like Botan , CryptoPP or libtomcrypt.
This obviously is a great opportunity to have something audited like this in Boost. The biggest problem the others don't get audited is because that's not how they we're written, making this an objective would make life easier from the start. Boost.org could fund, something the other devs don't have. 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
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 Wed, Feb 26, 2020 at 3:23 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
...
Sorry... I forgot to explain the most important motivation for creating a cryptography framework! There are many cryptographic algorithms which are second-order operations. That is, they are expressed in terms of underlying primitives. For example, the "Merkle–Damgård construction" is an algorithm which can be used to turn a block cipher into a cryptographic hash function. This can be expressed in C++ quite elegantly: template< class BlockCipher, std::size_t DigestBits > struct MerkleDamgardConstruction; It is much easier to write, and verify the correctness of the generic construction implementation because it assumes that the provided BlockCipher type is already correct. There is no cryptographic operation in the implementation. Merkle-Damgard is not without its problems, so users will still have to ensure that the security tradeoffs are appropriate for their use-case. There are many other second-order algorithms which can be (relatively) easily expressed in terms of cryptographic primitives by writing a function template or class template parameterized on various concepts such as BlockCipher, OneWayFunction, and so on. These come up quite often in crypto-currency applications. A "BIP" is a "Bitcoin Improvement Proposal" which is a highly structured paper describing a possible improvement to Bitcoin. Often, they involve new second-order and third-order cyptographic algorithms. A Boostly cryptography "framework" would allow authors to quickly prototype new higher order algorithms using the concepts I described above along with our wrappers implementing those concepts, simply by writing function or class templates and combining existing cryptographic primitives. The value of having named requirements is to give these cryptographic primitives uniform interfaces so they may be changed or substituted at will, as the needs require, facilitating the prototyping described above. Thanks
On 26.02.20 23:26, degski via Boost wrote:
On Wed, 26 Feb 2020 at 11:07, Rainer Deyke via Boost <boost@lists.boost.org> 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 Thu, 27 Feb 2020 at 10:08, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
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.
No, I understood you well, but collapsed the conclusion towards a conclusion about libs. 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.
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. 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. 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 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)
On Fri, 28 Feb 2020 at 17:49, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
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.
Yes, a good way to decrypt it is then to use PkZip. You do realize that PKZip has supported encrypted (aka
password-protected) zip files since 1993, right?
That's just slightly before the rest of the world stopped using it (like much better things like .arc, .lh, .arj etc etc, compression was a big thing in the 80's and 90's for obvious reasons). 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)? Normally these are one-time problems, which need a quick simple (possibly inefficient) one-time solution (creating some shell command to unzip (and re-zip) a list of file with pkzip, or something of the kind). Time is money, no matter what you take to write in C++, it will need debugging (could be long, old file-formats, you are now trying to find the bugs in a 27-year old application, I'm sure the boss will think that was time well spent). In a previous life, I was an FD (CFO) of a business unit in a multinational, and I have managed 2 big implementation of SAP/R3. In Europe I was getting results much faster than my counter-parts in the other countries of the EU, by just hiring some temps (cheap, as many as you like to have at one time) to do the keying (of old data) and make the book-keepers do the checking of the input. It saved mega on consultancy fees (at the time about EUR4K/day, vs E10/day for the temp) and got the job done, it's not beautiful and everybody moaned when I decided that, but two weeks later we had happy faces all over the place. The pkzip-situation is similar. 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 28.02.20 17:53, degski via Boost wrote:
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 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 Fri, 28 Feb 2020 at 20:31, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
Meanwhile zip files are still the single most popular archive format on the internet.
Yes, and there's not much wrong with that (compression ratio's if anything, better use lib-xz), zlib is foss and cross-platform available.
Go to the boost download page and you'll find a zip file as the "lowest common denominator" download for Windows.
And they all work great with zlib. 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.
Once you have the stream api, you just chain, and do encryption and compression (in that order, only) in one hit and the whole thing becomes very efficient.
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.
Oh, oh, oh, would you really consider not using OpenSSL? 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 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 Fri, 28 Feb 2020 at 23:44, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
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.
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)? In OpenSSL, this known bug is now fixed, the relevance is negative, won't happen again, so you can stop hesitating. In the future Boost.Crypto, on the other hand, the only thing we'll have for a considerable period of time, is unknown unknowns (just like OpenSSL, but without the twenty-two years of debugging and wide-spread use!!!, under the assumption that Boost will do this twice as fast, we're talking 2032 to reach this state, or never, who knows?). Wrapping libsodium (or something functionally equivalent, I personally don't care, which one, after wrapping this has no real relevance I think), seems [to me] to be a good investment of dev-time, focussing on making things auto-magically work [auto-magically, correctly] C++/Boost-style, RAII, strong typing, etc, etc. 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 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 Sat, 29 Feb 2020 at 04:16, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
I don't need a C++ implementation, and I don't need a C++ wrapper.
+1 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 Thu, 27 Feb 2020 at 10:08, Rainer Deyke via Boost <boost@lists.boost.org> 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
On Fri, Feb 28, 2020 at 7:35 AM degski via Boost <boost@lists.boost.org> wrote:
What is this nonsense? A library that only has two algorithms (Curve25519 and Gimli?) seems pointless to me. Thanks
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, February 28, 2020 3:47 PM, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
On Fri, Feb 28, 2020 at 7:35 AM degski via Boost boost@lists.boost.org wrote:
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
On Fri, Feb 28, 2020 at 10:25 AM Lee Clagett via Boost <boost@lists.boost.org> wrote:
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.
Hmmmmmmmmmmmmmmmm........ ....okay, I see your point. The name is a tiny bit misleading though because it alludes to doing more than it actually does.
Boost providing the kitchen sink of cryptography is only the correct approach if the goal is to provide mass interoperability with other systems.
For Boost, as I alluded to earlier, I would target experts and put something together those experts can use to quickly prototype ideas (interchangeable components which satisfy named requirements). If people need specific algorithms they can already get them, they just might have to suffer a tiny bit with C APIs and do without the accoutrements of modern C++. If Boost offered the library I describe, those people who are using specific algorithms could use the Boost-wrapped versions of those algorithms and gain access to modern C++ features. Thanks
On Fri, Feb 21, 2020 at 8:09 AM Mikhail Komarov via Boost <boost@lists.boost.org> wrote:
...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
participants (6)
-
degski -
Ggh -
Lee Clagett -
Mikhail Komarov -
Rainer Deyke -
Vinnie Falco