Why Not Rust Crypto?

One of the most frequent questions I receive about *ring* is "Why not Rust Crypto?," referring to the Rust Crypto project led by Tony Arcieri and Artyom Pavlov. People ask this because *ring* and Rust Crypto implement similar functionality, and Rust Crypto is 100% Rust, while *ring* is a mix of Rust, C, and assembly language. Why do these things exist in parallel instead of working together? Why don't I help the Rust Crypto project?

Here is message that I sent on June 7th, 2016 to Palmer Cox, the maintainer of the original rust-crypto project, verbatim:

Subject: rust-crypto + *ring*

Sorry to bother you by email. A long time ago, I suggested on Reddit that maybe we could find some way to work together on *ring* and rust-crypto and you seemed kind of open to that idea. Below is my idea. Please let me know whether or not you think it's a reasonable idea, or if you would be interested in trying to find some other way to work together.

Here's my idea:

Now, people are writing patches for *ring* that basically just duplicate what rust-crypto already does, e.g. pure Rust digest algorithms. And, I think that's a terrible waste. I'd rather direct them to help you improve your project, and I'd rather spend my time helping you improve your project as far as this "Pure Rust" energy goes. But, it's also true that I want to have *ring* work when it doesn't have any assembly language code for a platform. And, whenever the rust-crypto code is as fast or faster than the assembly language code in *ring*, I'd also like to just use the rust-crypto code. Eventually, I'd like to get rid of as much of the ASM code as possible.

But, there's also more stuff I want to do with *ring* that's far from "pure Rust" and I think you wouldn't be interested in it. Also, rust-crypto really does a *lot* of stuff that I don't want *ring* to do (mostly, implementing legacy algorithms). Also, I'm really partial to the API I designed for *ring*. And, I imagine that you are probably also partial to your API too. So, I definitely don't think it makes sense to try to merge them together into one thing.

But, would you be interested in factoring out some "rust-crypto-core" module that both *ring* and rust-crypto would depend on. It would include, for example, the "block" functions of the digest algorithms, ChaCha, Poly1305, AES(-GCM), Curve25519, etc. I also have some ECC (P-256/P-384) and hopefully eventually some RSA code that I could contribute. (I haven't open-sourced this yet.)

I think this might be a good way to help both of our projects because then I can direct all the "Pure Rust" contributions into your project, which should help your project. And, maybe we can in general get more of the Rust crypto coders working together instead of trying to one-up each other.

Cheers,
Brian

Ultimately, we didn't create the rust-crypto-core project.

Shortly after, somebody included me in an email thread about forking the rust-crypto project. I didn't get a confirmation from the original rust-crypto maintainer regarding that idea, so I decided to avoid participating in the fork. I think I also delayed adding any pure Rust implementations to *ring* for as long as I could. I was hoping that eventually it would become clear what to do.

Fast-forward seven years from 2016 to today. At the very minimum, I want to work with the Rust Crypto project so that we have a single place for all the pure-Rust implementations of the pedestrian cryptography that *ring* implements. I would lke to find a way to work together on that single common implementation so that it becomes faster than *ring*'s assembly language implementations that are inherited from BoringSSL. I am open to *ring* depending on Rust Crypto crates directly. I would like to see *ring*'s inherited unsafe assembly language evaporate as Rust Crypto's implementations overtake it in terms of performance. And I would like to work together to have a single standard Rust crypto library for everybody to use.

In the last few weeks, I have been running this idea by various groups and everybody seems to think it is OK as long as it doesn't hurt performance or delay the Rust Crypto FIPS 140 validation project. That said, I have not spoken to the Rust Crypto project leads or all the other *ring* stakeholders about it. If there's some reason that this isn't a good idea, or if you have a better idea, please email me (brian@briansmith.org) so we can discuss it.