Use the same method that we generate private keys in BLS

[jonas-lj]

we could use the same method that we generate private keys in BLS where some 32 bytes entropy bytes are an input, in our case the whole digest. However @asonnino it's very common for rogue key protection to use half scalars, because we care about pre-image attacks; you try to cancel-out another pub key, so combinatorics are already very expensive.

We do use half scalars in many apps (ie in the EdDSA half aggregation) for performance reasons to make that exponentiation half-expensive. In fact though, here we don't care, as this applies once at private key randomization (and with our mode where new-priv_key = old_priv_key \times this_scalar, we don't even have an ECC operation).

@asonnino: You remember the discussion we had at overleaf, shall we update the private key or for each signature we multiply by this scalar? if we do the former half or full scalar doesn't really matter. In the second you have to pay that cost every time you sign.

Originally posted by @kchalkias in https://github.com/MystenLabs/fastcrypto/pull/236#discussion_r1027302408

[jonas-lj]

@kchalkias There's a method called get_128bit_scalar given an RNG in the bls12381 module which is used to randomise signatures in verify_batch_empty_fail_different_msg. If half scalars are enough, we could change this method to take 16 bytes instead. Using the generate method, as you suggest, is also possible but then we would have to either extract the scalar from the private key afterwards, or use the private key type to represent the scalar.