SHA256

[Trivo25]

Implementation of static sized SHA2-256 https://csrc.nist.gov/pubs/fips/180-4/upd1/final

[mitschabaude]

All my comments are addressed now!

[rbonichon]

Need to re-read the sha256 implementation. I'm assuming it's correct or tests would break. But I'll need to verify.

It does seem strange to use little-endian conversions and always have to reverse them. What would be the reason?

[mitschabaude]

It does seem strange to use little-endian conversions and always have to reverse them. What would be the reason?

I can answer that! bytesToWord and wordsToBytes are not introduced in this PR, but existed earlier, for use in the Keccak gadget, where we used their little-endian versions.

Also, a general comment from me is that little-endian bytes layout is by far the more common overall, and also more logical IMO, or in other words, SHA256 is weird here.

So, I don't think we need to add a "le" suffix to methods that use little-endian convention (we have many places where that would need to be added..). I would treat little-endian as the general default and instead use a "be" suffix for methods that use big-endian convention

[rbonichon]

Also, a general comment from me is that little-endian bytes layout is by far the more common overall, and also more logical IMO, or in other words, SHA256 is weird here.

It is the most common these days in hardware architecture but most network protocols are big-endian (very recent example being the transfer protocol in the Optimism Cannon VM). Human text in latin languages or numbers are big-endian too. All this is just a matter of convention. I would not treat either of these as being "obviously" the one used in any setting.

So, I don't think we need to add a "le" suffix to methods that use little-endian convention (we have many places where that would need to be added..). I would treat little-endian as the general default and instead use a "be" suffix for methods that use big-endian convention

My suggestion to add endianness in the name was more akin to following the principle of least astonishment. Rust or OCaml, for example, do that in their integer to bytes converter. I understand it might not be done in this PR but you could consider to have both le and be converters it in a follow-up issue. And that would avoid the inelegant (and not super-efficient) reverse call above.

[rbonichon]

The implementation looks correct.