[csrng] input seed length shall be larger than 384 bits

Nobody has claimed this yet.

### Description

[NIST 800-90A](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf) states:
1. 8.6.3: The entropy input shall have entropy that is equal to or greater than the security strength of the
instantiation. Additional entropy may be provided in the nonce or the optional personalization
string during instantiation, or in the additional input during reseeding and generation, but this is
not required and does not increase the “official” security strength of the DRBG instantiation that
is recorded in the internal state.
For us it means at least 256 bits of full entropy.

2. 8.6.7: A nonce may be required in the construction of a seed during instantiation in order to provide a
security cushion to block certain attacks. The nonce shall be either: A value with at least (security_strength/2) bits of entropy, or A value that is expected to repeat no more often than a (security_strength/2)-bit random
string would be expected to repeat.

3. 8.7.1: A personalization string is an optional (but recommended) input to the instantiate function and is
used to derive the seed (see Section 8.6.1). The personalization string may be obtained from
inside or outside a cryptographic module, and may be an empty string. Note that a DRBG does
not rely on a personalization string to provide entropy, even though entropy could be provided in
the personalization string, and knowledge of the personalization string by an adversary does not
degrade the security strength of a DRBG instantiation, as long as the entropy input is unknown.

So the problem is that if nonce is used, then there is no space for personalization string. Even if nonce is not used, personalization string is limited to 4 words, which would mean truncation of hashes.

It would be highly desirable to increase total seed length to at least 512 or, better, 768 bits to support variety of use cases.

However, for CTR_DRBG in 10.2, seed length is limited to 384 bits if no derivation is used. This bring a question where derivation better to happen in software or hardware. 10.3.2 describes quite unique Derivation Function Using a Block Cipher Algorithm (Block_Cipher_df), which runs AES-CBC for CTR_DRBG.

Pros for hardware: simpler software interface (same register level), ability to sideload values from key manager to mix in (issue #22117 ). Cons: more complex HW.

Pros for software: no changes in HW. Cons no sideloading from key manager.

Start by reading NIST SP 800-90A sections 8.6.3, 8.6.7, 8.7.1, 10.2, and 10.3.2, then review issue #22117 for the key-manager context. Determine whether the seed-length and derivation changes belong in hardware or software; done requires a documented design decision and implementation scope.

Written by the indexing model from the issue text.