Tony Arcieri

Alternatively, `Encapsulate` could have an associated `Decapsulator`, which would be a bit closer to how things are in `kem` v0.2

@bifurcation being able to write generic code that can locate the type which performs decapsulation, similar to `signature::Keypair`. Edit: whoops, it would probably make more sense to be able to...

As a more concrete example of a `signature`-shaped API for this sort of thing, `rsa` defines the following traits: - [`Decryptor`](https://docs.rs/rsa/0.9.6/rsa/traits/trait.Decryptor.html) - [`EncryptingKeypair`](https://docs.rs/rsa/0.9.6/rsa/traits/trait.EncryptingKeypair.html) - [`RandomizedDecryptor`](https://docs.rs/rsa/0.9.6/rsa/traits/trait.RandomizedDecryptor.html) - [`RandomizedEncryptor`](https://docs.rs/rsa/0.9.6/rsa/traits/trait.RandomizedEncryptor.html) (sidebar: it would...

@bifurcation `kem::Keypair` sounds fine to me, and unlike `signature` where there's a proliferation of possible signer traits, it could probably be bounded on `Decapsulate`, defining an associated `Encapsulator` or thereabouts...

> Did we want to support getting the decap key from this? If so, do we know why the signature::Keypair trait doesn't support that? @rozbb in `signature`, the `Keypair` trait...

@rozbb of those, the struct looks better to me. Either are a bit different from `signature`, which allows computing the public key from the secret key.

I wonder if perhaps we should try to migrate from this built-in implementation to https://github.com/RustCrypto/JOSE/tree/master/jose-jwk

Note: there's a PR to fix Solana here: https://github.com/anza-xyz/agave/pull/2252 I'd also note that the latest release of `p256` is v0.13, so `aws-sigv4` is a little behind, if anything.

Re: `TLS_DHE_*` ciphersuites, we don't currently have an implementation of FFDH(E). I'm also not super enthusiastic about adding such support as it's effectively been obsoleted by the `TLS_ECDHE_*` ciphersuites.

I've recently asked about it. It's possible work might resume.