Skip to content

refactor(aes): machine-word generic fixslice#560

Open
sinui0 wants to merge 3 commits into
RustCrypto:masterfrom
privacy-ethereum:refactor/fixslice-generic
Open

refactor(aes): machine-word generic fixslice#560
sinui0 wants to merge 3 commits into
RustCrypto:masterfrom
privacy-ethereum:refactor/fixslice-generic

Conversation

@sinui0
Copy link
Copy Markdown

@sinui0 sinui0 commented May 15, 2026

This PR collapses the two fixslice impls into a single fixslice.rs parameterized over a Word trait that abstracts the machine-word width.

I tried to structure the commits to make it clear to the reviewer that this introduces no changes to the existing implementation logic.

This PR was motivated by #559 to support larger machine-word (SIMD) implementations without introducing major duplication and maintenance burden.

sinui0 added 3 commits May 14, 2026 08:55
Drop the cpubits-based selection between width-specific fixslice modules
in preparation for unifying both into a single width-generic implementation.
Refactor the fixslice AES implementation so the algorithm body is generic
over a `Word` trait, with a single `impl Word for u32` carrying all
width-specific code (row width, packing routines, bitslice/inv_bitslice).

The three-pass delta-swap pipeline used by `bitslice` and `inv_bitslice`
is extracted into a shared width-generic `bitslice_swaps` helper, with
mask constants derived from a `Word::byte_repeat` method. Each impl now
only carries the bytes-in/bytes-out routine.

This is a purely mechanical refactor: no logic changes, no behavior
changes, the only word width supported is still `u32`.
Add the second `Word` impl, `impl Word for u64`, which batches 4 blocks
per state versus 2 for `u32`. The concrete re-exports and the hazmat
helpers are gated by `target_pointer_width` via `cpubits!`, selecting
`u32` on 16/32-bit targets and `u64` on 64-bit.
@tarcieri
Copy link
Copy Markdown
Member

This looks good to me as a general direction, though it may be some time before I can review it in detail.

I'm a bit confused how this broke the build the way it did, it seems somehow with only changes to the soft backend it broke things in the NEON backend somehow?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants