core: implement DeterministicRandomSource by joboet · Pull Request #131607 · rust-lang/rust (original) (raw)

Some thoughts:

First, as others have mentioned above, I really want to call this core::random::ChaCha8Source. This would minimize the possibility of regret. Among other reasons, if we did later want to add something like core::random::ChaCha8RandSource, with its various other tradeoffs, we could do that.

Regarding ChaCha8Rand broadly, as others have mentioned, it's not seekable, and that's a rather important property for many things. That's not to say we shouldn't have it or something like it, but simply that it should sit neatly alongside options that are seekable.

Regarding ChaCha8Rand in particular, that algorithm is probably not how I'd prefer to solve the problem it's trying to solve (optimizing better for wider SIMD lanes). I'd probably prefer to use a natively wider block permutation, and thereby benefit from diffusion across all words, rather than adapt ChaCha by striping across multiple instances in an ad-hoc way.

Regarding the number of rounds, 8 is a kind of an unfortunate number. It's secure today, but with quite limited security margin. (Conversely, it's probably overkill by 2-4 rounds if we don't want security at all, i.e., are OK with some detectable patterns in the output that wouldn't matter for most non-cryptographic applications.)

Yes, yes, we're not going for secure here, but that's exactly the problem with this number. This will be easy to use, and it will not have obvious security flaws, so people will use it in places that at least some security is called for. Security needs aren't all or none, of course.

If we call it ChaCha8Source, then actually I think that's fine, because we could always add a ChaCha12Source (or a ChaCha4Source, or a ChaChaSource<const N: usize>), and people would know what they're getting.

But what I'd like to avoid is that we ship DeterministicSource at N rounds, then a couple years later look at how people are using it in practice, and decide that, actually, we'd prefer to have some security margin here, and then have to deprecate it and add a DeterministicMoreSecureSource. Or conversely, that we decide we really want it to be faster and deprecate it in favor of a DeterministicFasterLessSecureSource.

I'd rather people just know what they're getting, and for something meant to be deterministic, it just makes a lot of sense to name the algorithm.