Figure out in-tree crypto story

[brson]

We've previously made the decision not to distribute any crypto with Rust at all, but this is probably not tenable since crypto is used everywhere. My current opinion is that we should not distribute any crypto written in Rust, but that distributing bindings to well-regarded crypto is fine.

Figure out a strategy here, build consensus, then start implementing a robust crypto library out of tree, with the goal of merging into the main distribution someday. There are some existing efforts along these lines that should be evaluated for this purpose.

[thestinger]

@ciphergoth: A stream cipher is trivially a CSPRNG. There's nothing else that's required. You need to retrieve an initial seed from the operating system, as you do for any kind of DoS secure hashing scheme. Re-seeding it is optional and can actually hurt rather than helping. Not providing a fast CSPRNG means that people are going to use an insecure RNG for cases where they should not... the absence of the feature is a security vulnerability in practice.

http://blog.cr.yp.to/20140205-entropy.html

[tarcieri]

@ciphergoth re: verifying artifacts, what you said is true, however even with just hash functions you can decompose the dependencies into a Merkle tree, so for example a bootstrapping tool can pull in all of its subresources and confirm their integrity, with each of them pinned to specific digests.

With something like that, rustc bootstrap could have cryptographic integrity.

[ciphergoth]

If all the platforms you need to run on can provide a good seed then I take it all back, including an RNG is very desirable.

I still feel there's a very strong presumption against including things in 1.0, since if you leave something out and it was a mistake you can include it later, but if you put it in or give it the wrong API you are in big trouble. Since Rust has a good dependency management story it doesn't seem like a big problem to use that to get hold of the functions you need.

[thestinger]

If all the platforms you need to run on can provide a good seed then I take it all back, including an RNG is very desirable.

A seed is obviously needed for SipHash to be worth anything so I don't understand the distinction you're making.

[thestinger]

Since Rust has a good dependency management story

It really doesn't. The most that can be said is that it has one. It's awful at doing proper reproducible releases and is yet another insecure packager manager without a package signing story or proper system integration. Of course, you can't expect much when compiler snapshots are built on third party cloud infrastructure. Each Xen vulnerability leaves Rust's compiler snapshots wide open to attacks from anything else on those machines.

[tshepang]

OT: @thestinger I would be keen to read a detailed blog post by you containing all Rust-related issues you have. You notice a lot, and the one about package signing is quite interesting.

[tarcieri]

@tshepang FWIW I made an issue about that here: https://github.com/rust-lang/crates.io/issues/75

[ciphergoth]

Are you saying that the issues you raise with Crate are a reason to put things in-tree?

[tarcieri]

@ciphergoth no, I already gave my rationale for that above (see rustc bootstrap and subresource integrity)

[ciphergoth]

Can you describe the sort of scenario you're thinking of in more detail? The hash of some other resource is included in the Rust sources themselves—what sort of resource do you have in mind and at what stage is it fetched? Also note that you currently have to have Python installed to build rustc; at a pinch you could use a hash function built into Python as a bootstrapping aid. I don't yet see a compelling enough picture to overcome the leave-things-out presumption, but it's very possible you're right and I'm just not seeing the whole picture.

[tarcieri]

I was really making a more general statement about the utility. I don't have some master plan mapped out in my head.

[ciphergoth]

I think it would probably be safe to add the hash function to the sources in the same change that makes use of it.

[tarcieri]

Sure, my point wasn't that hash functions should be included right now, merely that they should be "allowed"

FWIW, SHA256 already appears to be in the rustc sources:

http://doc.rust-lang.org/rustc/util/sha2/struct.Sha256.html

[ciphergoth]

Oh interesting, thanks! It's used here as part of a mangling strategy for symbols and crate names.

https://github.com/rust-lang/rust/blob/master/src/librustc_trans/back/link.rs#L75

I share your sense that I'm less alarmed at seeing a hash function in the sources than pretty much any other cryptographic primitive!

[tarcieri]

Hmm, I see that Rust vendors a Rust implementation of ChaCha20 for use as a PRNG:

https://github.com/rust-lang/rust/blob/master/src/librand/chacha.rs

Hard to say how I feel about that. I'm curious if anyone knows if that gets exposed with the name "secure" on it anywhere, or how the key is generated?

This is all I could find on it:

https://github.com/rust-lang/rust/wiki/Lib-rand

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#766

[l0kod]

cc rust-lang/cargo#1281