The FNV hash functions are used incorrectly

[chfast]

In the original design, each byte of input is treated with a round of the FNV hashing.
https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function

In Ethash input data is hashed in 32-bit chunks following the FNV-1 formula for single round.
This is not changed in ProgPoW except for using FNV-1a formula.

This is "more correct" implementation: https://godbolt.org/z/tO3Lqt.

[AndreaLanfranchi]

Good finding.
The same mis-implementation is present in ethash though.

[chfast]

The same mis-implementation is present in ethash though.

Yes, I clarified the description.

I'm not a cryptography expert to assess if that's worth fixing. Maybe that would save us from the mysterious DAG compression attack.

[AndreaLanfranchi]

I see in ethash the mis-implementation has been deliberately chosen
https://github.com/ethereum/ethash/blob/master/src/libethash/fnv.h#L30-L39

DAG access in PP is quite different from the one in ethash.
The latter computes dag offset on one round fnv over mix only.
In PP instead mix is filled by kiss99 where each of the four words is FNV-1a'ed independentely

DEV_INLINE void fill_mix(const uint64_t seed, const uint32_t lane_id, uint32_t* mix)
{
    // Use FNV to expand the per-warp seed to per-lane
    // Use KISS to expand the per-lane seed to fill mix
    uint32_t fnv_hash = 0x811c9dc5;
    kiss99_t st;
    st.z = fnv1a(fnv_hash, seed);
    st.w = fnv1a(fnv_hash, seed >> 32);
    st.jsr = fnv1a(fnv_hash, lane_id);
    st.jcong = fnv1a(fnv_hash, lane_id);
#pragma unroll
    for (int i = 0; i < PROGPOW_REGS; i++)
        mix[i] = kiss99(st);
}

Not a cryptographer either but quite different paths.