It's a pragmatic decision. Incorrectly implemented crypto has worse consequences than potential memory safety problems.
We have crypto experts on staff who could write this kind of thing, but we have a shipping schedule to meet and crypto is the kind of thing we definitely don't want to rush out the door.
Doing either (incorrectly implementing crypto or telling users to use an unsafe C library) would be highly irresponsible. I respect the hell out of you and your team but I think you are dead wrong on this one. Have your domain experts take their time and do it right.
There are plenty of safe C crypto libraries. NSS, OpenSSL, and gnuTLS are all widely used by a LOT of sites, and, recent OpenSSL vulnerability aside, have a great track record. What would you suggest using?
I agree, especially interesting because in a good written crypto some functions should spend always the same time, independent of the input, and you have to know if you designed your language good enough to even make such crypto possible.
This shouldn't be a problem. If you can do constant-time operations in C, you can do them in Rust, by dint of the fact that you can more or less generate any LLVM IR you'd like in Rust, up to and including inline asm.
> We have crypto experts on staff who could write this kind of thing, but we have a shipping schedule to meet and crypto is the kind of thing we definitely don't want to rush out the door.
I hope that the "wrap C libraries" approach then is a short-term approach, and that doesn't mean that you don't plan on having those crypto experts build crypto libraries in Rust (hopefully, with compatible APIs, so that there can be a seemless transition down the road.)
We have crypto experts on staff who could write this kind of thing, but we have a shipping schedule to meet and crypto is the kind of thing we definitely don't want to rush out the door.