Conversation

Notices

1. Jeff Martin (cuchaz@gladtech.social)'s status on Tuesday, 06-Jun-2023 01:10:10 JST Jeff Martin

   Any #Rust #Cryptography people out there? :blobcatwave:

   I've been using the Rust OpenSSL bindings for a while now, and they're fine. They're fine.

   But the lib seems to be missing any bindings for EVP_PKEY_pairwise_check() and I'd really like to use it. Support for OpenSSL v3.x apis seems to be generally lacking.

   Although, I've heard OpenSSL isn't a great library in general and maybe I should try to use something else. So maybe this is a good opportunity to migrate to a better lib?

   What are the good crypto libraries out there for Rust? I'm looking for implementations of basic stuff like RSA, HMAC, AES, etc. Bonus points if the implementation is actually in a memory-safe language (like Rust!).

   Ring looks nice maybe? I suppose there are probably bindings for libsodium somewhere. What are people using these days?

   • silverpill (silverpill@mitra.social)'s status on Tuesday, 06-Jun-2023 01:10:09 JST silverpill

     in reply to

     @cuchaz I use crates from RustCrypto family: https://github.com/RustCrypto. AFAIK they haven't been independently audited, but they are well-maintained and written in Rust.

   • silverpill (silverpill@mitra.social)'s status on Thursday, 08-Jun-2023 02:19:27 JST silverpill

     in reply to

     • Soatok Dreamseeker

     @cuchaz @soatok

     >"Versioned Protocols"

     W3C Verifiable Credentials workgroup has published a set of specs for "cryptosuites", which are versioned:

     ecdsa-2019 https://w3c.github.io/vc-di-ecdsa/
     eddsa-2022 https://w3c.github.io/vc-di-eddsa/

     You may find them useful if you're signing JSON objects.

   • Soatok Dreamseeker (soatok@furry.engineer)'s status on Thursday, 08-Jun-2023 02:19:28 JST Soatok Dreamseeker

     in reply to

     @cuchaz https://soatok.blog/2022/08/20/cryptographic-agility-and-superior-alternatives/

   • Jeff Martin (cuchaz@gladtech.social)'s status on Thursday, 08-Jun-2023 02:19:28 JST Jeff Martin

     in reply to

     • Soatok Dreamseeker

     @soatok Awesome, thanks for the reference! Love your blog btw. As a new reader, I haven't seen a lot of the older posts yet, like this one.

     I totally agree with you how lots of agility is bad here. I'd say my approach is pretty darn close to your section called "Versioned Protocols". I try to strike a balance here so I can actually have a defined migration path while not allowing dumb things like `alg = none`. All the primitive choices and parameters are hard-coded. The only data-defined choice is a single version number. It feels like a good spot on that tradeoff spectrum.

   • Jeff Martin (cuchaz@gladtech.social)'s status on Thursday, 08-Jun-2023 02:19:29 JST Jeff Martin

     in reply to

     Oof, libsodium is waaaay too opinionated for this project. I don't think I can use it at all.

     I love their approach though! The problem is that I'm doing something really similar and they're kind of incompatible with each other.

     Libsodium's API seems to be a bunch of instances of: Oh, you're doing cryptography application X? (eg authenticated encryption), then you should use primitive Y. A bunch of experts got together to pick Y and they're great choices!

     The problem with that is the best choice of Y changes over time. My library (Burger Identities) embraces that change and uses a kind of pluggable "backend" for each cryptography application. So today you might be using Y, but tomorrow the best answer might be Z. And Burger Identities gives you a way to migrate to the better primitives while still keeping compatibility with the people you're exchanging messages with.

     So today I'm implementing a "backend" with RSA. Soon I'll get around to implementing one that uses ECC. And then later on, some kind of post-quantum implementation too. But that means I need to use something lower-level than libsodium.