Cryptography for Boost. Boost.Crypto3.
Hello!
Some time ago I promised to show something about cryptography library architecture and implementation for Boost (https://lists.boost.org/Archives/boost//2020/02/248205.php https://lists.boost.org/Archives/boost//2020/02/248205.php), so here I am. I’m actually glad my two innocent letters triggered such a conversation. That is what I wanted to see!
Please, read this letter very carefully, because some explaining needs to be done before you go to the code.
By the way. The code: https://github.com/NilFoundation/boost-crypto3 https://github.com/NilFoundation/boost-crypto3.
Warning. This letter contains mentioning of my non-commercial organizations I develop Boost.Crypto3 with. Don’t consider that as advertising. It is not supposed to be an advertisement.
So, what cryptography for Boost (and probably STL some time after) should look like?
1. It should definitely be simple to use and implemented with some generic programming spirit.
That is exactly what was done. Remember std::transform?
Typical usage technique for all of the modules of a suite looks as follows.
Classic iterator pair with output iterator:
using namespace boost::crypto3;
std::string input = “Weird German 2 byte thing: Ã.“, out;
encodecodec::base64(input.begin(), input.end(), std::inserter(out, out.end()));
Classic iterator pair with output value return:
using namespace boost::crypto3;
std::string input = “00112233445566778899aabbccddeeff”;
std::string key = “000102030405060708090a0b0c0d0e0f”;
std::string out = encrypt
Cristopher (Kormanyos), I’m aware of your> CRC catalog library (https://github.com/ckormanyos/crc-catalog https://github.com/ckormanyos/crc-catalog)> I like it because of how in particular it is implemented.> I would really like to merge it into our CRC> implementation in Crypto3.Hash. Thank you. In its present state, however,there's only bitwise calculations.The catalog, as implemented, does utilizea clear, generic, stream-oriented approachwhich would fit with your overall work.But if you need table-driven methodsor table generation, we would need todiscuss these.
Thank you for sharing this work.
Kind regards, Chris
On Wednesday, September 2, 2020, 2:52:42 AM GMT+2, Mikhail Komarov via Boost
It is great to see some positive feedback! Thank you! Coming to questions: 1. Yes. You are correct. Processing over the stream of various classes convertible to any Integral type (for now, we will generalize that further in some time). Internal architecture about how these streams are being processed is a little bit more complicated (includes Boost.Accumulator usage, caches data with Merkle-Damgard or Sponge constructions etc), but still being concept-based. Coming to the internal architecture. According to what we’ve been recommended for us to be able to pave the road for this set of concepts to the standard (https://www.reddit.com/r/cpp/comments/ikxgs5/nil_crypto3_conceptbased_pure_c_cryptography/g3ro8dg?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/cpp/comments/ikxgs5/nil_crypto3_conceptbased_pure_c_cryptography/g3ro8dg?utm_source=share&utm_medium=web2x&context=3), the set of concepts used internally will be extended and modified a little bit. 2. Yes. There is even some drafty implementations of such an approach for various cryptography fields in the main =nil; Crypto3 suite (https://github.com/NilFoundation/crypto3 https://github.com/NilFoundation/crypto3). They were simply not yet ported to Boost-ified version (https://github.com/NilFoundation/boost-crypto3 https://github.com/NilFoundation/boost-crypto3). 2.1 For example, here is a drafty public key cryptography implementation (including elliptic curves operations, along with signing and verification): https://github.com/NilFoundation/crypto3-pubkey https://github.com/NilFoundation/crypto3-pubkey. (work in progress) 2.2 Here is a drafty cryptography-enhanced fork of Boost.Random (https://github.com/NilFoundation/crypto3-random https://github.com/NilFoundation/crypto3-random) which uses drafty stream ciphers (https://github.com/NilFoundation/crypto3-stream https://github.com/NilFoundation/crypto3-stream) being implemented with the same approach. I would really like to push stream ciphers into Boost.Crypto3 sometime, so after that I could push Boost.Random, enhanced with Salsa/ChaCha RNGs. 2.3 Same architecture is being also applied to drafty message authentication codes in here: https://github.com/NilFoundation/crypto3-mac https://github.com/NilFoundation/crypto3-mac. (drafty) 2.4 Password-based key derivation functions: https://github.com/NilFoundation/crypto3-pbkdf https://github.com/NilFoundation/crypto3-pbkdf (also drafty) 2.5 Password hashing: https://github.com/NilFoundation/crypto3-passhash https://github.com/NilFoundation/crypto3-passhash (also drafty) 2.6 Usual key derivation functions: https://github.com/NilFoundation/crypto3-kdf https://github.com/NilFoundation/crypto3-kdf (drafty) 2.7 Cipher modes: https://github.com/NilFoundation/crypto3-modes https://github.com/NilFoundation/crypto3-modes (less drafty) 2.8 Codecs: https://github.com/NilFoundation/crypto3-codec https://github.com/NilFoundation/crypto3-codec (not drafty) 2.9 And much more things using similar approach mostly listed in here: https://github.com/NilFoundation/crypto3/tree/master/libs https://github.com/NilFoundation/crypto3/tree/master/libs. I would really like to get a clue of what particular fields could be considered useful for Boost, so I could merge them into Boost.Crypto3 and propose for a review afterwards. Coming to CRC. We have our own implementation of CRC being fit into the general architecture (https://github.com/NilFoundation/crypto3-hash/pull/68 https://github.com/NilFoundation/crypto3-hash/pull/68), but the architecture is a little bit too heavy for such small-digested hashes (literally checksums) as CRC or Adler or xxHash or MurmurHash. So that is why I pretty much like the way you got it implemented. Sincerely yours, Mikhail Komarov nemo@nil.foundation
Mikhail Komarov wrote:
Here's a "meta question" about the idea of having cryptography in Boost: do we think that the "Boost process" (i.e. reviews etc.) is suitable for cryptography, where the issues are somewhat different than other domains? If I were looking for a cryptography library, I don't think that Boost's emphasis on modern C++ best-practice and the "stamp of approval" from our review process would be my top priorities. Rather, I would be looking for a track record of securely-implemented cryptography coming from acknowledged and trusted domain experts. So if I were comparing this with other libraries, my first question would be "Who is Mikhail Komarov?", followed by "what is the Nil Foundation, and why is it registered in the Cayman Islands?". Regards, Phil.
Well, coming to that, that is why I propose to put into Boost.Crypto3 only proven schemes with only proven implementation techniques. Most of them, files related to them e.g. in CryptoPP, were not being changed for years.
Moreover cryptography in Boost is not only about the implementation. It is also about the architecture, the set of concepts.
Coming to “If I were looking for a cryptography…”. You are right, the "stamp of approval” matter nothing in case you are looking for some complex protocol/scheme, but this is not what you would use a generic-purpose cryptography library for. This particular case makes you look for the implementation which you would be able to audit by yourself. But in other cases, bringing CryptoPP/OpenSSL or simply some random library from the Internet to the project in case of need for SHA-family hash or some block cipher is not that handy, as simply use boost::crypto3::sign<ecdsa>() or boost::crypto3::hash
On 9/4/20 7:06 AM, Phil Endecott via Boost wrote:
Lot's of interesting stuff in this little post.
I think any C++ library should have that emphasis.
Hmmm - Perhaps some domains are so arcane, mathematical, that we don't have all the resources to properly evaluate them. Should this be case, I'm thinking we might want to recruit some of the missing resources. That make sure the reviewers include some specialized individuals. Not that particularly trust the individuals more than others, but I think with thinks like this not at a bad idea that all the different facets of such an evaluation be covered. Since it's a super important application area - the standards for acceptance would likely be higher than normal - e.g. no more acceptance with 2 reviews.
So if I were comparing this with other libraries, my first question would be "Who is Mikhail Komarov?",
We're evaluating the submission - not the submitter.
LOL - very interesting. Shades of a James Bond villain. I would be curious to know about this though.
Regards, Phil.
Robert Ramey
participants (6)
-
Christopher Kormanyos -
Kostas Savvidis -
Mikhail Komarov -
Peter Dimov -
Phil Endecott -
Robert Ramey