[aes/rtl] Overwrite GHASH state when clearing instead of XORing - #31584

Previously, the design XORed the current, unmasked cipher core output
qualified by CTRL_GCM_SHADOWED.NUM_VALID_BYTES into the current GHASH
state for clearing the GHASH state. Even though the unmasked cipher
core output is over steered using the clearing PRNG while clearing the
GHASH state, this was non optimal for the following reasons:

1. How many bytes of the GHASH state got cleared depended on
   CTRL_GCM_SHADOWED.NUM_VALID_BYTES. If software mis-configured this
   register, it would have been possible that the GHASH state isn't
   modified at all.
2. Knowing two secret netlist permutations applied to the output of the
   clearing PRNG, and assuming that software did not fully clear the
   GHASH module, it was possible to re-trigger the generation of the
   final tag computation and thereby recovering the intermediate state
   of the GHASH module. This could be leveraged for subsequent
   cryptanalysis attacks on the hash subkey.

This commit changes the implementation as follows:
- The cipher core is modified to output the AES state whenever idle.
  This is fine as before entering the idle state, the AES state is wiped
  using the clearing PRNG.
- For clearing, the GHASH state is overwritten with the current, masked
  cipher core output (i.e. the cleared AES state when the cipher core is
  idle).

Since now the hash subkey registers and the GHASH state are cleared with
the same data, it means the two GF multipliers effectively compute the
square of the two individual shares afterwards. This is fine from an SCA
perspective, because the cleared AES state (i.e. the output of the
clearing PRNG) isn't secret anyways (it is also used to clear the data
output registers readable by software).

Thanks to Dino Mehmedagić @nodix95 for reporting this!

Signed-off-by: Pirmin Vogel <vogelpi@lowrisc.org>