mpc-tls: size GHASH preprocessing to the configured record length

[SipengXie2024]

GHASH preprocessing allocates 1026 exponents unconditionally, which is exactly one maximum-size TLS record: 1024 ciphertext blocks plus an AAD block and a length block. A connection that provisions far less still pays for a full record in both directions.

Ghash::alloc now takes a max_power that MpcGhash stores, and setup, compute_shares and compute all read that stored value. The AES-GCM caller derives it from the allocation it already receives:

pub(crate) fn powers_for_len(len: usize) -> usize {
    (len.div_ceil(16) + 2).min(MAX_POWER).next_multiple_of(2)
}

The clamp preserves existing behaviour exactly: any caller provisioning at least one maximum-size record still allocates 1026. Rounding up to an even value is required because odd powers are converted in pairs.

All four sites had to change together. compute derives its block offset from shares.len():

let offset = shares.len() - blocks.len();

That subtraction is only safe while the block_count > MAX_POWER guard and the share vector share one bound. Parameterising alloc alone would let it wrap in release builds, skip past the end of the iterator, and fold an empty zip into Gf2_128::zero() — a wrong tag share with no error. alloc also now rejects bounds it cannot honour (odd, below 2, above MAX_POWER).

Tests added:

• bounded_shares_match_the_unbounded_prefix — for bounds 2, 4, 56 and 1026, the bounded share vector equals the corresponding prefix of the full one.
• powers_for_len_covers_the_input_and_clamps — the bound always covers ceil(len/16) + 2, stays even, and clamps.
• alloc_rejects_bounds_it_cannot_honor.
• bounded_ghash_accepts_its_limit_and_rejects_one_block_more — a four-power instance reproduces the reference GHASH tag at its limit and errors one byte past it, in both roles.

Measured on a downstream application with an 855-byte sent allocation and a 64-byte online receive allocation: 4,123,934 fewer bytes per session (−14.1%), split almost evenly between the two directions, with latency unchanged.

The branch also contains a second, independent commit adding an optional prover-supplied hash commitment blinder; happy to split it into its own PR if you prefer to review them separately.