Many implementations don't work on big-endian systems

[spth]

I noticed that many Ascon implementations here work on little-endian systems, but not on big-endian systems. I looked into crypto_aead and crypto_hash to add some Ascon cryptography to the test suite of the Small Device C Compiler (SDCC). Unsurprisingly, I got failures (fine, after all the point of that was to improve SDCC). But after a while I noticed that apparently nearly everything fails for big-endian targets. To check if that is due to SDCC bugs specific to the endianness-handling code, I also tested on a big-endian Debian GNU/Linux host, and found that both my tests, and the self-test from this repository fail there.
Thus I assume that the endianness handling in many implementations here is broken. In particular, the implementation "ref" works fine (for both Ascon-AEAD128 and Ascon-Hash256, while apparently implementations that use a lendian.h fail.

I've attached LastTest.log from a Debian GNU/Linux on ppc64 machine. We can see that the test failed for bi32, bi32_lowsize, bi32_lowreg, opt8, opt8_lowsize, bi8. LastTest.log

Using SDCC I had tried ref, opt32_lowsize, opt8, bi8, opt8_lowsize, and I see all of them except for ref fail my test (just your test vector 333 for Ascon-AEAD128 and your test vector 42 for Ascon-Hash256) on big-endian targets.

[Scottcjn]

Reproduced on native big-endian POWER8 — root cause is a numeric IV assignment in the byte-array implementations.

I reproduced this on a native big-endian POWER8 (ppc64, Linux/musl — real hardware, not emulation) and compared each implementation's generated KAT against ref (which is correct on BE).

The failing implementations (opt8, opt8_lowsize, bi8, bi32, bi32_lowreg, …) share one root cause. They keep the state as a little-endian byte array (s->b[w][i], filled via INSERT/ABSORB/memcpy), but the IV is assigned as a numeric 64-bit constant in ascon_initaead():

s->x[0] = ASCON_128A_IV;

On a little-endian host the numeric .x view and the .b[] byte-array view agree, so it works. On big-endian they disagree: s->x[0] = <constant> lays the IV out MSB-first while the rest of the implementation reads it LSB-first, so the initial state is wrong and every output diverges — the very first vector (empty AD + empty message) already produces the wrong tag.

ref is immune because it never uses the byte-array view: it loads/stores through shift-based SETBYTE/GETBYTE, which is endian-agnostic.

Minimal fix — route the IV through the same little-endian conversion the load path already uses:

s->x[0] = U64TOWORD(ASCON_128A_IV);   /* U64LE: byte-swap on big-endian, no-op on little-endian */

With only that one change in opt8/aead.c, its generated LWC_AEAD_KAT_128_128.txt (Ascon-AEAD128) becomes byte-identical to ref on the POWER8 — all vectors. The byte-based ROR and the S-box need no change; they're already consistent with the byte array.

Note this is implementation-specific: the same wrap must not be applied to the numeric implementations (ref, opt32, opt64, avx512), where it would byte-swap an already-correct IV and break them. The same pattern applies to the Hash/XOF/CXOF/MAC byte-array variants (their *_IV assignments).

I have the big-endian hardware to validate each implementation against ref, so I'm happy to put together a PR that applies this across the affected byte-array implementations (AEAD + Hash/XOF/CXOF/MAC) and verify each one — just let me know if that's welcome.