On 09/07/17 16:59, Vinnie Falco via Boost wrote:

On Thu, Sep 7, 2017 at 2:50 AM, Richard Hodges via Boost wrote:

...

I think it would be reasonable to say that most people (tm) use either the openssl or CryptoCpp libraries.

I doubt either of these libraries would pass a Boost review.

They don't need to. I think a full implementation of cryptographic algorithms in Boost, while would be nice in theory, is not very feasible in practice. First, it would require a group of very skillful and active developers that keep their hand on pulse in the security and cryptography field. Vulnerabilities need to be acted upon fast, which also means that Boost release schedule doesn't suit very well for such a library. The implementation has to be robust and fast to compete with other implementations (and by fast I mean including writing assembler routines for many algorithms). Then, preferably, the implementation would have to pass an independent audit to gain some trust in users. A cryptography library in Boost is very much welcome, but, at least initially, I think, it should focus primarilly on providing proper interface that fits in C++ ecosystem well. The bulk of the work should be done by a third party implementation, like OpenSSL or gnutls or libnss or whatever the native API is on a given platform. Maybe, if the API becomes popular and the library gains momentum, it could then offer its own implementation of some algorithms, e.g. to remove external dependencies. Then the difficulties I mentioned can be tackled gradually over time.

On 09/07/17 18:12, Vinnie Falco via Boost wrote:

On Thu, Sep 7, 2017 at 8:08 AM, Andrey Semashev via Boost wrote:

...

initially, I think, it should focus primarilly on providing proper interface

Are you suggesting that the first step is to define some concepts such as BigInteger, Digest, BlockCipher, MessageAuthenticationCode, or OneWayFunction?

Yes, probably. And then implement those concepts on top of existing crypto libraries.

On Thu, Sep 7, 2017 at 8:30 AM, Niall Douglas via Boost wrote:

I vaguely remember that...Howard had some WG21 proposal for a standardised hashing infrastructure? One not fundamentally broken like std::hash. One should probably study/implement that proposal.

You're thinking of hash_append, described here: http://htmlpreview.github.io/?https://github.com/HowardHinnant/papers/blob/m... Repository: https://github.com/howardhinnant/hash_append This library is designed for non-cryptographic hashing. Specifically for unordered containers (hash tables). The requirements for cryptographic hash algorithms are different, and difficult to unify with the use-case for hash tables. For example when calculating the cryptographic digest on serialized data, endianness of integers matters.

On Sep 7, 2017, at 12:11 PM, Vinnie Falco via Boost wrote:

On Thu, Sep 7, 2017 at 8:30 AM, Niall Douglas via Boost wrote:

...

I vaguely remember that...Howard had some WG21 proposal for a standardised hashing infrastructure? One not fundamentally broken like std::hash. One should probably study/implement that proposal.

You're thinking of hash_append, described here:

http://htmlpreview.github.io/?https://github.com/HowardHinnant/papers/blob/m...

Repository:

https://github.com/howardhinnant/hash_append

This library is designed for non-cryptographic hashing. Specifically for unordered containers (hash tables). The requirements for cryptographic hash algorithms are different, and difficult to unify with the use-case for hash tables.

For example when calculating the cryptographic digest on serialized data, endianness of integers matters.

endian taken into account here: https://github.com/HowardHinnant/hash_append/blob/master/sha256.h#L30 (example sha256 hasher) xstd::endian is now C++17 (as std::endian, 23.15.9 [meta.endian]). Howard

On Sep 7, 2017, at 12:40 PM, Vinnie Falco via Boost wrote:

On Thu, Sep 7, 2017 at 9:26 AM, Howard Hinnant via Boost wrote:

...

endian taken into account here:

I use endianness only as an easily understood example of an issue that makes the needs of a cryptographic hash interface different from an unordered container hash interface. There are other issues, which require a move involved discussion than I think is appropriate in this thread. For example, we cannot have distinct cryptographic and non-cryptographic serialization algorithms for the same type (using n3980).

Demo for distinct serialization algorithms for varying hashers: #include "hash_append.h" #include "sha256.h" #include "fnv1a.h" #include <iostream> class X { std::array d_{}; public: friend void hash_append(acme::sha256& h, X const& x) { std::cout << "hash with sha256: "; xstd::hash_append(h, x.d_); } template <class Hasher> friend void hash_append(Hasher& h, X const& x) { std::cout << "hash with everything else: "; xstd::hash_append(h, x.d_, x.d_.size()); } }; int main() { X x; xstd::uhashacme::fnv1a h1; std::cout << h1(x) << '\n'; xstd::uhashacme::sha256 h2; for (auto const& i : h2(x)) std::cout << std::hex << (unsigned)i; std::cout << '\n'; } Output: hash with everything else: 7024978713738287141 hash with sha256: 66687aadf862bd776c8fc18b8e9f8e2089714856ee233b3902a591dd5f2925

The bottom line is that n3980 needs to go through more iteration and study with respect to its usage for cryptographic hash algorithms before we can state that the interface is well suited for it.

I welcome and encourage more study and discussion in any context, thread or list. My only motivation here is to dispel mistaken believes that the current hash_append infrastructure can not handle issues such as endian or alternate serialization algorithms for different hashers. Admittedly, the latest proposal (N3980) is sorely in need of updating and likely doesn’t have the latest details of the implementation at https://github.com/HowardHinnant/hash_append . And thanks for the shout-out to this lib earlier in this thread. Howard

On 7 September 2017 at 18:08, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

I think a full implementation of cryptographic algorithms in Boost, while would be nice in theory, is not very feasible in practice.

I agree with you, but for an important other reason, over and above the ones you mention. Crypto is tricky businness. If you don't know what your doing (and most people don't), things can go horribly wrong. Supplying the building blocks for doing Crypto (as suggested in follow-up post to this one) is not "safe". The way these alogo's get integrated in the code-base is hugely important, problems like side channel attacks spring to mind, it's a different way of thinking about algorithms. I think an approach like the one of libsodium https://www.gitbook.com/book/jedisct1/libsodium/details is the correct one. Per "task" (let's say password authentication) to be done, there are 1 or 2 (full and complete) options on offer, options that do those things well, and in a safe way. This approach, though, is contrary to boosts' philosophy (offer all and every option, so the user can do things "his/her" way). Another good crypto library is Botan https://botan.randombit.net/. The code is well organised and easy to grasp and extend. Botan is slightly easier to use than CryptoCpp IMO. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

On 8 September 2017 at 08:33, Vinnie Falco via Boost wrote:

On Thu, Sep 7, 2017 at 10:12 PM, degski via Boost wrote: A C library with no abstractions... nack

C is *not* a dirty word (assuming it *is* a word), AFAIK! OpenSSL is C, isn't it? But, if you insist on C++, you could check out the Other Language Bindings page: https://download.libsodium.org/doc/bindings_for_other_languages/ , where you'll find 3 wrapper libraries. The importance is the different approach, I wrote about earlier.

C++, with some abstractions in the form of common base classes. This looks promising :)

It's also been C++11, since, umh, well, 2011 :-). degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798