What the *ring* crate provides

[djc]

You've listed ring in the TLS/SSL section, but it actually provides many of the same crypto primitives (AEADs, hashes, signatures) as the RustCrypto crates, so maybe that should be more clearly explained?

I actually think webpki and ring probably shouldn't be mentioned in the TLS section, since they're low-level building blocks that rustls uses but that aren't very friendly as libraries.

[nicoburns]

I rather agree with your analysis. But I'm not quite sure how they should be presented. Do you think they should just be omitted entirely? For now I've stuck them behind a "see also" section.

[djc]

In general, the issue here is the choice for the RustCrypto project to split the primitives into many crates, while ring provides a monolithic crate API. I would probably create one left-hand entry for Primitives to encompass all of Password Hashing, General-Purpose Hashing, AEAD encryption, RSA and Digital Signatures, with entries for both ring and the RustCrypto project, where the description of these contain links to the top-level pages for RustCrypto and maybe the relevant modules in ring. (But I guess you maybe don't have support for links within project descriptions for now?)

(The fact that RustCrypto splits out rsa as a separate crate is a little odd from a conceptual point of view.)

Putting webpki and ring under See also for TLS/SSL makes sense to me. 👍

[oconnor663]

Kind of a tangent, but I'd lean towards removing MD5 and SHA-1 from the list, since those are broken primitives that shouldn't generally be used in new code. Or if we need to include them for back-compat reasons, I think it's important to clearly mark them as deprecated. I like the way the ring API does this: https://docs.rs/ring/latest/ring/digest/index.html. If I had to pick exactly which digests to include, I'd probably say SHA-2 and SHA-3.

[djc]

That's also a good point -- I think that's an additional reason not to go into too much detail on a list of primitives.

[oconnor663]

My even edgier opinion is that AEADs like AES-GCM and ChaCha20-Poly1305 aren't suitable for general use, much like unauthenticated ciphers and raw block ciphers aren't suitable for general use. All of these things are too difficult to use correctly without expert help, and the overwhelming majority of applications that need encryption will do better with higher-level protocols like TLS/HTTPS or higher-level tools like full-disk encryption or age. But I accept that this isn't a common opinion, and that it probably makes sense for this list to cater to what developers are actually asking for, rather than what some jerk thinks they should be asking for :)

[djc]

Can also agree with that one.

[nicoburns]

While I largely agree with your takes, I think I would like for the most part to keep this guide opinionated about the best implementation of a given algorithm or technique without being too opinionated which algorithms or techniques one ought to use. While I wouldn't choose to use md5 or SHA1 for new code, I've found that I quite frequently do have need for this (to compare with data which is already in those formats or interoperate with 3rd party services that are using them).

it probably makes sense for this list to cater to what developers are actually asking for

Basically this. I'd rather someone thinking "I need to use SHA1, and I'm wondering whether Rust is viable for my project" ends up at "oh great, there's an SHA1 library" than "guess I'll have to use Go or C++".

[nicoburns]

Having said that, is anyone aware of a higher-level symmetric encryption library in Rust? We could certainly also point people to that if there's a good one.

[oconnor663]

I think the best candidates are either age or crypto_secretstream, but I don't think either of those are widely used enough for this list, and they're not super beginner-friendly either. The set of algorithms you have now seems pretty reasonable.