Bas Westerbaan

@jedisct1 All right, build passed.

Did you use git or did you download a ZIP from github?

I would be in favour of having `crypto/rand.[Reader.]Read` never return an error, and completely fill the provided slice. (And have it panic if the underlying system call errors.)

To sidestep synchronisation issues, the implementations could be patched so that `randombytes` is passed as a function pointer to `crypto_keypair`.

(This issue is blocking me from using liboqs to implement [X25519Kyber768Draft00](https://datatracker.ietf.org/doc/draft-westerbaan-cfrg-hpke-xyber768d00/) in [rust-hpke](https://github.com/rozbb/rust-hpke/pull/43).)

> The only case in which the function pointer mechanism might be better is if a scheme calls randombytes multiple times This is the case for Kyber, unfortunately.

> @bwesterb do you only need derandomized key generation or also derandomized encapsulation? I need thread-safe derandomized key generation to implement HPKE API. To validate test vectors, I also need...

> Agreed. Derandomized key gen is also a little dangerous; I've seen some libraries include words like "hazardous" in the function API to flag that, do you think we should...

Thank you for this. I will review over the coming days.

> Thanks for pointing out things to consider. No, it is not written not from scratch. The code basically follows the thought process of the reference code. You should add...