Let me suggest an alternative design using C++20 concepts and a CRTP-ish structure: Instead of this long list of parameters, we could write a concept to tie down the parameters each MDx-hash needs to define (as static constexpr members). Then, the instantiation of MDx_Hash in the concrete implementations shrinks to: MDx_Hash<MD5> m_md;:

template <typename T>
concept mdx_hash_implementation =
    requires(T::digest_type digest, uint8_t input[], size_t blocks, MD_Endian endian) {
        typename T::digest_type;
        T::endianness;
        T::block_bytes;
        T::ctr_bytes;
        T::init(digest);
        T::compress_n(digest, input, blocks);
    } &&
    T::block_bytes >= 64 && is_power_of_2(T::block_bytes) &&
    T::ctr_bytes >= 8 && is_power_of_2(T::ctr_bytes) &&
    T::ctr_bytes < T::block_bytes &&
    sizeof(typename T::digest_type) >= 16;
    

template <mdx_hash_implementation T>
class MDx
{
    std::array<uint8_t, T::block_bytes> m_buffer;
    T::digest_type m_digest;
    uint64_t m_count;
    size_t m_position;
};

class MD5
{
public:
    using digest_type = std::array<uint32_t, 4>;
    static constexpr MD_Endian endianness = MD_Endian::Little;
    static constexpr size_t block_bytes = 64;
    static constexpr size_t ctr_bytes = 8;
    
public:
    static void init(digest_type& digest);
    static void compress_n(digest_type& digest, const uint8_t input[], size_t blocks);

private:
    MDx<MD5> m_md;
};

That surely is a bit more boilerplate in the concrete implementations. But I see a few advantages:

• It lends itself from the usual STL members: e.g. std::vector<>::value_type
• Readability: Instead of a long list of magic numbers in the MDx_Hash instantiation, each parameter has a speaking name
• DRY: Parameter definitions can be referred to in the implementation classes (if needed) -> less implicit knowledge: e.g. digest_type encapsulates the digest_length and digest_element_type and the init()/compress_n() methods don't need to repeat it
• Parameter constraints are declared as a concept, hopefully resulting in better compiler errors

Certainly this can be further refined.

Godbolt: https://godbolt.org/z/1h1nzcYoh

Now that each MDx hash inherits straight from HashFunction, these "plumbing methods" are repeated for each class. From what I can see, they all simply forward to their respective m_md or create a copy of themselves. Its just copy-and-paste boilerplate, but it does bug me somewhat.

With the full CRTP-approach I suggested earlier this would go away. At the expense of inheriting from an MDx template.

Is that correct? The compress and init methods take [8] elements.

Do I misunderstand something or is that a copy-and-paste error? (also for the SHA-flavours in this file)