Re: Re: bswap is slow on SPARC

> From: Mouse <[email protected]>
> Date: Mon, 24 Nov 2025 10:01:26 -0500 (EST)
> 
> (For that matter, why would encryption care about integer endianness
> to begin with?)

The case that attracted nia's attention is Adiantum,[1] a wide-block
cipher that

(a) has good security which depends only on the security of the
    extremely heavily studied cryptographic primitives ChaCha12 and
    AES (i.e., Adiantum is not a novel cryptographic primitive
    requiring custom cryptanalysis to attain confidence in its
    security); and

(b) has performance that is generally better than AES-CBC or AES-XTS
    on CPUs without AES hardware acceleration -- not guaranteed, but
    in practice it usually is (when AES is implemented to resist
    timing side channel attacks, anyway, and I ripped out all the
    vulnerable AES code in the NetBSD kernel at the same time I added
    support for Adiantum[2]).

We support Adiantum for cgd(4) disk encryption.

Part of Adiantum is the hash function NH which interprets its input in
4-byte blocks as a sequence of 32-bit integers in little-endian, and
computes 64- and 32-bit addition and multiplication on the integers.
The algebraic structure of integer arithmetic is necessary to prove a
bound on the collision probability of NH under uniform random keys as
part of the theorem reducing Adiantum's security to ChaCha12's and
AES's security.

Another part of Adiantum is the stream cipher ChaCha12 which
interprets its input in 4-byte blocks as a sequence of 32-bit integers
in little-endian, and interleaves 32-bit addition, 32-bit rotation,
and bitwise xor.  The incompatibility of the algebraic structures of
Z/(2^32)Z (integer addition) and GF(2^32) (bitwise xor) is the basis
of the `ARX' (Add/Rotate/Xor) design principle for scrambling inputs
in many cryptographic primitives, such as BLAKE2, SHA-2, and
Threefish.

You could switch NH and ChaCha12 to big-endian (and it is easy to
prove that that can't affect the _cryptanalytic_ security in
principle), but that would not provide a compatible on-disk format, so
it would necessarily be a different cipher, not Adiantum.  Unnecessary
knobs in cryptographic protocols are generally risky, and we already
have too many options (including some legacy options like Blowfish and
3DES that could admit cryptanalytic attacks, not just side channel
attacks[3]) -- not to mention the implementation costs of adopting,
verifying, testing, and maintaining additional crypto primitives.

So, while we could look for alternatives or invent a big-endian
Adiantum to address the evidently underserved demand for fast disk
encryption on machines with sparcv8 CPUs, I think the low-hanging
fruit of speeding up bswap32 by inlining it is a better start.


[1] Paul Crowley and Eric Biggers, `Adiantum: length-preserving
    encryption for entry-level processors', IACR Transactions on
    Symmetric Cryptology 2018(4), pp. 39--61.
    https://doi.org/10.13154/tosc.v2018.i4.39-61

[2] https://mail-index.NetBSD.org/tech-kern/2020/06/18/msg026505.html

[3] Karthikeyan Bhargavan and Gaetan Leurent, `On the Practical
    (In-)Security of 64-bit Block Ciphers', ACM CCS '16, pp. 456--467.
    https://doi.org/10.1145/2976749.2978423
    https://sweet32.info/SWEET32_CCS16.pdf (paywall-free)
    https://sweet32.info (popular exposition)