BLAKE2: issue with endianness?

[cobratbq]

Hi, I've been going through tht BLAKE2 code-base and I stumbled onto this thing that bothers me.

hashes/blake2/src/macros.rs

Line 144 in bf1b257

*v = $word::from_ne_bytes(chunk.try_into().unwrap());

Notice how the block is loaded in 32-bit chunks in native-endianness? This seems to correspond to the spec (RFC 7693) at top of page 24 where it says "get little-endian words".

Given that the data being loaded is raw data from the block-buffer, it seems that native-endianness can never be correct. I would guess this mistake is caused by wanting to convert into native-endianness, i.e. properly processing as u32, but that's a given. The source-buffer is simply interpreted as little-endian by convenient, AFAICT.

[tarcieri]

FWIW we run the test suite cross-compiled to PPC32 (big endian):

hashes/.github/workflows/blake2.yml

Lines 85 to 110 in 479ad0b

	cross:
	needs: set-msrv
	strategy:
	matrix:
	rust:
	- ${{needs.set-msrv.outputs.msrv}}
	- stable
	target:
	- aarch64-unknown-linux-gnu
	- powerpc-unknown-linux-gnu
	features:
	- default
	runs-on: ubuntu-latest
	defaults:
	run:
	# Cross mounts only current package, i.e. by default it ignores workspace's Cargo.toml
	working-directory: .
	steps:
	- uses: actions/checkout@v4
	- uses: ./.github/actions/cross-tests
	with:
	rust: ${{ matrix.rust }}
	package: ${{ github.workflow }}
	target: ${{ matrix.target }}
	features: ${{ matrix.features }}

https://github.com/RustCrypto/hashes/actions/runs/15885774221/job/44797227071

[cobratbq]

Okay, that seems solid. So .. am I just reasoning about it wrong or does this seem contradictory?

[tarcieri]

Offhand I'm uncertain why it works

[cobratbq]

Okay. I'm going through this code anyways. I'll see if I can figure it out as I go.

[cobratbq]

I think I've figured it out. Endianness is important, but the conversion (if needed) happens at a later time. So, at this point, it seems there is no problem.

See

hashes/blake2/src/macros.rs

Line 110 in bf1b257

v[0] = v[0].wrapping_add(v[1]).wrapping_add(m.from_le());

At that point, a vectorized data-type is in use, so this may have efficiency benefits.

Note: I haven't fully verified, but this makes sense. It also makes sense it would be native-endian, such that they're literally deferring until use. It is somewhat less straight-forward than it seems, because 32-bit integer is a single word and then there is an additional consideration of how these are (always?) processed in a certain way, regardless of endianness. (That is, big-endian would sometimes also work.)