proposal: crypto/mlkem: support derandomized encapsulation in tests

[chrisfenner]

Proposal Details

MLKEM encapsulation takes no arguments and reads m from drbg

In tests only, I would like to be able to inject the randomness so that production Go code can be tested using test vectors for a protocol that builds on top of ML-KEM.

I appreciate how this was done for OAEP, where the library asserts that derandomized OAEP is not happening outside of tests.

If it is acceptable to support derandomized encapsulation, there are a few ways I can think of to do it:

1. Breaking change to the API (add an optional io.Reader that we read from instead of drbg if not nil, and use boring.UnreachableExceptTests() to ensure that it is only used in tests.
2. Non-breaking mildly awkward change to the API (add m as a ...byte) that we check is length messageSize and use instead of reading from drbg if not zero-length, and use boring.UnreachableExceptTests() to ensure that it is only not zero-length in tests.
3. New API (introduce a new EncapsulateWithMyReader (not an actual name suggestion) that reads from an optional io.reader, using drbg if nil, and use boring.UnreachableExceptTests() to ensure that it is only not nil in tests)

[mateusz834]

Related: #70942

[FiloSottile]

Indeed, the easiest way will be to add an EncapsulateWithTestReader method that takes a RandReader from #70942.

I appreciate how this was done for OAEP, where the library asserts that derandomized OAEP is not happening outside of tests.

Note that this applies only to Go+BoringCrypto.

[chrisfenner]

Indeed, the easiest way will be to add an EncapsulateWithTestReader method that takes a RandReader from #70942.

That would work for me. Would you like me to send a PR?