aes: shrink AES round keys for AES fixslice backend

[Freax13]

This PR does two things:

1. Add support for using u16 as the native word size for the AES fixslice backend.
2. Round keys are now always store as u16s. They are expanded into the full native words when the backend is created.
   a. On a targets with a 64-bit native word size, this reduces the size of the Aes128, Aes192, and Aes256 types from 704, 832, and 960 to 176, 208, and 240 bytes respectively.

Closes #191

[newpavlov]

I don't think we need to introduce u16-based backend for compact keys. Instead it would be better to store compact round keys in the Aes state and perform their expansion during backend creation (see the AVX-512 backend for reference).

[Freax13]

I don't think we need to introduce u16-based backend for compact keys.

Just to be clear, even with the compact backend, the fixslice implementation still runs on the native word size. Enabling the compact backend does not force it into the u16 path for encryption/decryption.

Instead it would be better to store compact round keys in the Aes state and perform their expansion during backend creation (see the AVX-512 backend for reference).

The proposed changes are very similar to this except that we expand/broadcast the round keys one by one when they're needed instead of doing so at the start of the encrypt/decrypt function. Expanding them at the beginning of encrypt/decrypt would be possible, but it would require saving all the expanded state on the stack and negate the space savings that motivated this change in the first place.

[newpavlov]

it would require saving all the expanded state on the stack and negate the space savings that motivated this change in the first place.

Yes, broadcasted keys are likely to be spilled to the stack (at least on register-starved x86), but it would reduce size of the Aes state (so we would not need bother with something like #593) and would have much less runtime overhead since broadcast has to be done only once during backend selection.

[Freax13]

it would require saving all the expanded state on the stack and negate the space savings that motivated this change in the first place.

Yes, broadcasted keys are likely to be spilled to the stack (at least on register-starved x86), but it would reduce size of the Aes state (so we would not need bother with something like #593) and would have much less runtime overhead since broadcast has to be done only once during backend selection.

Done.

[newpavlov]

I haven't checked the changes in fixslice internals, but it looks mostly good otherwise.

Ideally, it would be nice to keep aes192, mix_columns, and utils intact, but I am fine with the changes if there is a good reason for them.

[newpavlov]

For posterity, could you add a comment (in the PR discussion) explaining why the aes192, mix_columns, and utils changes were necessary?

[Freax13]

For posterity, could you add a comment (in the PR discussion) explaining why the aes192, mix_columns, and utils changes were necessary?

The fixslice implementation uses the words like SIMD registers to encrypt multiple blocks in different lanes each at once. u32 can fit two lanes and u64 can fit four lanes. Because previously u32 with two lanes was the smallest denominator, some of the constants passed to uniform_row and pack_rows were already duplicated to fit that smallest denominator. This caused problems when adding the u16 implementation because a u16 can only fit a single lane.

There were two possible solutions: Either deduplicate the constants in the u16 implementation or adjust the code so that a single lane is the new common denominator and duplicate/quadruple the constants for the u32 and u64 implementations respectively. I chose the later approach.

If you look at the constants passed to uniform_row and pack_rows, you'll note that they previously all contained bit patterns with duplicated bits (e.g. W::pack_rows(0x00, 0x03, 0x0f, 0x0c) is equal to W::pack_rows(0b00_00_00_00, 0b00_00_00_11, 0b00_00_11_11, 0b00_00_11_00) and now those bit patterns have been deduplicated (the same line was changed to W::pack_rows(0b0_0_0_0, 0b0_0_0_1, 0b0_0_1_1, 0b0_0_1_0) or W::pack_rows(0x0, 0x1, 0x3, 0x2) in hex).