Re: [hash2] Formal Review Begins

From: Tom Kent (lists_at_[hidden])
Date: 2024-12-11 01:55:00

On Sat, Dec 7, 2024 at 7:41 AM Matt Borland via Boost <boost_at_[hidden]>
wrote:

> 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