Bas Westerbaan

You might want to check out [go-ristretto](https://github.com/bwesterb/go-ristretto).

I would prefer Ristretto to be part of the standard library, but in the meantime I have separate package [bwesterb/go-ristretto](https://github.com/bwesterb/go-ristretto).

Do you have any unaccounted items? No items are listed for me either, but the bird folder is pretty much empty anyway: ``` Accounted for: 0MB. Still unaccounted: 0MB ```

The `*KeyPair` type seems to implement `crypto.Signer` already, but if that wasn't obvious then we might want to change the API anyways.

I do agree with @armfazh that `big.Int` isn't great for cryptographic purposes due to timing attacks.

The Go TLS tests require the code to be deterministic. In the case of the normal TLS code, they pass around a `rand io.Reader` which is set to something deterministic...

Yes, by passing a random source or optional seed to both GenerateKey and Encapsulate. I considered that, but I prefer the common interface to be as simple as possible. The...

> I really don't think exporting functions for internal tests is a good reason to impact the API. I'm pretty sure deterministic key generation is useful in some protocols. For...

> To the point about the KEMs in CIRCL having a fixed-length seed as input: this is true of the current set of KEMs, but there are lots of reasons...

> thoughts? Using a seed instead of an `io.Reader` is only a small advantage which I don't think is worth complicating the API. My primary motivation for having two versions...