Lots of little bugs!
- The Keccak sponge table's padding logic was wrong, it was mixing up the number of rows with the number of hashes.
- The Keccak sponge table's Keccak-looking data was wrong - input to Keccak-f should be after xor'ing in the block.
- The Keccak sponge table's logic-looking filter was wrong. We do 5 logic CTLs for any final-block row, even if some of the xors are with 0s from Keccak padding.
- The CPU was using the wrong/outdated output memory channel for its Keccak sponge and logic CTLs.
- The Keccak table just didn't have a way to filter out padding rows. I added a filter column for this.
- The Keccak table wasn't remembering the original preimage of a permutation; lookers were seeing the preimage of the final step. I added columns for the original preimage.
- `ctl_data_logic` was using the wrong memory channel
- Kernel bootloading generation was using the wrong length for its Keccak sponge CTL, and its `keccak_sponge_log` was seeing the wrong clock since it was called after adding the final bootloading row.
`keccak_rust` doesn't seem to have much usage, and it treats `x` as the major axis of its 5x5 input. This is not exactly wrong, since Keccak itself doesn't have a notion of axis order. However, there is a convention for mapping bits of the cube to a flat list of bits, which is
> The mapping between the bits of `s` and those of `a` is `s[w(5y + x) + z] = a[x][y][z]`.
Obeying this convention would be awkward with `keccak_rust` - the words in memory would need to be transposed.
Based on the approach @SyxtonPrime described.
In terms of columns, the changes are:
- Store inputs (`A`) as `u32` limbs, rather than individual bits.
- Remove `C_partial`. It was used to store an intermediate product in a 5-way xor, but we've since realized that we can do a 5-way xor directly.
- Add `C_prime`, an intermediate result used to help verify the relation between `A` and `A'`.
