Use TryCryptoRng instead of CryptoRng

[josh-brown-anchor]

There are a number of places in the library that the use the CryptoRng trait. This makes it impossible to pass failable randomness sources such as OsRng to these functions. Instead, this library should use the TryCryptoRng trait which is strictly more general and then add an error type to the error enum:

rust-hpke/src/lib.rs

Line 148 in ba75d11

pub enum HpkeError {

[rozbb]

This is true but the fallibility trickles down to every public function. I've had this convo elsewhere, but is it strictly necessary to support TryCryptoRng? If someone only has access to a fallible RNG, why can't they use it to make a 32B seed, and seed an infallible RNG like ChaCha12Rng?

[josh-brown-anchor]

fallibility trickles down to every public function.

This is true but from what I can tell all the public functions are already failable. It only requires a modification of HPKError enum. Users that pass a CryptoRng will know that, that error variant is impossible.

If someone only has access to a fallible RNG

This implies that such a scenario is relatively rare however since OsRng only implements TryCryptoRng, almost all users will only have access to such an Rng. Therefore, I think forcing users to go through the process of choosing another Rng and then seeding it, without a strict library necessity, seems like poor ergonomics.

[tarcieri]

FWIW we gave the kem crate an infallible interface except for TryDecapsulate to handle ECDH, which included the crypto RNGs, though elsewhere in the @RustCrypto ecosystem we try to support TryCryptoRng while making an infallible getrandom-based API the primary recommended user-facing API