On Sat, Dec 7, 2024 at 7:41 AM Matt Borland via Boost
Dear all,
The review of Hash2 by Peter Dimov and Christian Mazakas begins today Saturday, December 7th through Sunday December 15th, 2024.
Code: https://github.com/pdimov/hash2 Docs: https://pdimov.github.io/hash2/
Please provide feedback on the following general topics:
- What is your evaluation of the design?
This looks to be a good API and hits the goals desired. Seems like it would be simple and nice to use.
- What is your evaluation of the implementation?
- What is your evaluation of the documentation?
- What is your evaluation of the potential usefulness of the library? Do you already use it in industry?
There are several hashes given in this library that are used in security critical scenarios (e.g. SHA-2). Additionally, the explicit goal of the library is to give the user tools they need to build their own hashes. I do not see any indication that any kind of cryptographic assessment was done on this library. There is not even a mention that the security of these hashes has been thought about nor in what scenarios they could be used. This is absolutely essential for any library providing cryptographic primitives. There are a *lot* of potential pitfalls in the implementation of a cryptographic primitive, even in cases where the "correctness" of the end result aren't in question. For example, there have been timing attacks against SHA-2/HMAC where the difference in the amount of time processing takes can leak information about the secret key. https://dl.acm.org/doi/10.1007/978-3-030-89915-8_2 These side-channel type attacks can be extremely insidious, and are not things that people who are otherwise experts in C++/C/Assembly/etc would ever think about. For cryptography, we need a different type of expert than the type we typically grow in this community. **If Boost wants to take on providing cryptographic primitives, we need to hold those libraries to a higher standard, including an evaluation by outside cryptopgophers before we release anything to the public.** I would be much happier if the choice was made to use a thoroughly vetted library (e.g. OpenSSL, but more compact options would probably be better) behind the scenes, with a nice C++ wrapper on the front. I am tempted to suggest an option where we put big banners on the library saying "not for use in scenarios that require cryptographic security", but there is simply too much danger in users not understanding *when* they require security (with dozens of examples of this happening in the literature) that they would accidentally use this library in scenarios that undermine their security.
- Did you try to use the library? With which compiler(s)? Did you have any problems?
I did not.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Spent a good amount of time reading the documentation. Browsed through some of the code.
- Are you knowledgeable about the problem domain?
Moderately, work in a security critical industry. Ensure to explicitly include with your review: ACCEPT, REJECT, or
CONDITIONAL ACCEPT (with acceptance conditions).
REJECT Sincerely, Thomas Kent