fix: random generation for garbling mode

[cyphersnake]

The current way of generating randomness as well as the size of the seed is not sufficient for this system and requires rethinking and increasing entropy

[AaronFeickert]

What specifically about the current design needs to be changed?

[cyphersnake]

Right now u64 is taken as seed for simplicity. We should at least migrate to [u8; 32], check that ChaCha20 is sufficient and document it for auditing purposes

[AaronFeickert]

The use of ChaCha20 is absolutely fine for this use case (and could easily be reduced to ChaCha12).

[AaronFeickert]

Is there a particular need for a 256-bit seed, versus 128 bits?

[cyphersnake]

This issue is just there to figure out what we need. I.e. I just put this issue aside and used the simplest ChaCha20(seed: u64)

[AaronFeickert]

There's no harm in using a seed with 256-bit entropy or ChaCha20 if there aren't meaningful efficiency hits.

[AaronFeickert]

Obligatory link to the Too Much Crypto preprint, which recommends (in section 5.3) going as low as ChaCha8 where speed is important.

[cyphersnake]

So we actually only have a few thousand random values being created. I.e. it is never a bottle neck. VSSS also doesn't look like something that will change that.

In classic garbling where we make all labels random it is critical to have a fast generator, here we have all labels except input determinized through fn garble.