9 ms·
Mundane: Rust cryptography library that is difficult to misuse
- jeffbee 6y agoHilarious build-time dependencies. You need Perl and Go and a C++ toolchain to build a Rust library!
- frenchy 6y agoCan't misuse it if you can't even build it.
- vmchale 6y agoI do admire it!
- makeworld 6y agoNote that these are the requirements of the BoringSSL dependency, not the project itself.
- octoberfranklin 6y agoThat might make BoringSSL a poor fit for use outside of golang. I mean this is kinda like a rust library with a dependency on a Java JVM.
- loeg 6y agoIt's not a runtime dependency.
- brundolf 6y agoIt looks like that's because it's backed by an established SSL library. So this is more of a safely-typed Rust wrapper around that (which means they aren't rolling their own crypto, which is typically considered a good thing)
- jedimastert 6y ago> which means they aren't rolling their own crypto I will point out that BoringSSL is also mainly developed by Google, so...kinda? I still trust it, just a kinda interesting fact
- brundolf 6y agoI think the intended meaning of "your own crypto" is "greenfield crypto"
- baby 6y agoI’d still rather use a pure rust implementation
- kachnuv_ocasek 6y agoOr they could've used a formally verified crypto library such as HACL*.
- deleted 6y ago[deleted]
- pabs3 6y agoTheres a Rust library that uses a Python script to generate part of its Rust code, checks that generated Rust code into git and the crates.io package does not include the Python script, so you can't actually build the crate from source properly.
- ilammy 6y agoTechnically, you can avoid depending on Perl and Go (which are used to generate some assembly code) but you still need C++ toolchain to build most of the BoringSSL. It is still possible to [make Mundane] link against system's OpenSSL. However, that's a bit different set of worms to locate it, auto-generate working FFI bindings, etc.
- sitkack 6y agoCouldn't the assembly code be generated with constexpr?
- dmitriid 6y agoSo, judging from zero docs, it's hard to misuse because you wouldn't even know how to use it.
- muricula 6y agoThis may be the documentation: https://docs.rs/mundane/0.4.3/mundane/ https://docs.rs/mundane/0.4.3/mundane/ It's not great, but it's something. You're right though, they should at a minimum link to it more prominently.
- cheeze 6y agoI don't want to crap on the project, but it seems like good user docs would be... the second most important thing after API design in terms of making a library hard to misuse. Maybe I'm wrong here though
- dathinab 6y agohttps://docs.rs/mundane/0.4.3/mundane/ https://docs.rs/mundane/0.4.3/mundane/
- brundolf 6y agoDocumentation for Rust crates goes in a standard location (which does get linked to from the crates.io page), though of course it'd be better if you didn't have to know that in order to find it from GitHub
- dmitriid 6y agoI went to both crates.io and docs.rs. Documentation as is is virtually non-existent there. Unless you're already familiar with how these functions are supposed to work.
- jevgeni 6y agoIt's kind of a faux pas, I think, to claim ergonomics as a top priority and not have good quality documentation anywhere in sight.
- the_duke 6y agoMandatory mention of of ring [1], one of the goto crypto libraries for Rust. It is also has a focus on hard to misuse API design and uses some BoringSSL primitives as well, while notably not depending on it's build system (go, Perl, ...) A cursory glance at the code suggests that `mundane` is purely an API wrapper for BoringSSL at the moment, and does not implement any crypto in Rust. [1] https://github.com/briansmith/ring https://github.com/briansmith/ring
- richardwhiuk 6y agoAnother alternative is https://docs.rs/sodiumoxide/0.2.6/sodiumoxide/ https://docs.rs/sodiumoxide/0.2.6/sodiumoxide/ - bindings to NaCL.
- deleted 6y ago[deleted]
- octoberfranklin 6y agoYeah the golang dependency just seems bizarre.
- adkadskhj 6y agoI found Ring a little difficult to use though, at least from a novice perspective. Wish the documentation was a little more novice focused / available.
- charliesome 6y agoI have never used Ring directly, but my experience dealing with it as a transitive dependency leads me to avoid it. Ring has a policy[0] of only supporting the latest released version with users being expected to always upgrade to latest Ring. This in itself is not so bad, but coupled with the lack of any guarantees around API stability means that it can be a very tricky dependency to work with. This problem is compounded by it only being possible to link one version of Ring in to the same program. Even if you don't depend on Ring directly, Ring could appear as a dependency of many of your dependencies. This forces you into upgrading all of your Ring-depending dependencies in lockstep. You cannot upgrade any until all of these dependencies support the same latest version of Ring. This is a real shame because Ring otherwise looks fantastic. The API is misuse resistant and looks quite pleasant, and the documentation is thorough. Its current versioning and stability policy however is a massive liability for any project that relies on it. I hope this changes eventually. [0]: https://github.com/briansmith/ring#versioning--stability https://github.com/briansmith/ring#versioning--stability
- Tobu 6y agoI don't know what this is doing here. ring is also hard to misuse, and more actively maintained by far.
- deleted 6y ago[deleted]
- vlmutolo 6y agoThis is a good place to link to Orion [1], a pure-Rust crypto project for AEAD, stream ciphers, KDFs, MACs, and plain hashing. There hasn't yet been a formal security audit (hard to justify until there's a significant user base), but the API is tough to beat for usability and hard-to-misuse-ability (docs [2]). It's an unproven library, but the author takes security pretty seriously. There's no unsafe, heavy testing, and fuzzing done for both safety (fuzzing with a sanitizer) and constant-time operation verification to minimize the danger of a timing attack. Here's an example of the API. let key = aead::SecretKey::default(); let ciphertext = aead::seal(&key, "msg".as_bytes())?; let plaintext = aead::open(&key, &ciphertext)?; It doesn't get much easier than that. Also, notice the lack of a user-facing nonce. Can't screw it up if it isn't there. There are also lots of details that are right in the library. Traits like PartialEq are implemented using constant-time operations so that users don't have to know or remember to use special operations provided by the library for comparison. Methods that return types without these protections (like getting the raw bytes out of a PasswordHash) are helpfully named things like "unprotected_as_encoded". [1] https://github.com/brycx/orion https://github.com/brycx/orion [2] https://docs.rs/orion/0.15.5/orion/aead/index.html#example https://docs.rs/orion/0.15.5/orion/aead/index.html#example
- adkadskhj 6y agoOrion looks cool, but i'm curious - where would one learn how to use a library like Orion? Eg, if Orion is aimed at easy to use - i'm still not the target audience. But, i do write software that i want to allow users to sign. To encrypt their data at rest. To verify signatures. Where would i learn what i need to use smart tools by other people? Where would i learn enough to decide how to choose solving my above problems with Orion vs GPG? That's been my biggest problem with crypto. I know enough to know to be wary, but not much beyond that. Choosing tools with that mindset is difficult. And so far, taking a crypto class is just teaching me fundamentals of building my own protocols - where as i just want to use existing tech, safely, and in the right situations.
- vlmutolo 6y agoThat's a good question, and I'd be interested in hearing more about what parts of the library you're hung up on. The intention of the library is definitely to cater to people who don't know anything about crypto. My naive guess, without knowing exactly what the sticking point is for you, is that Orion could do a better job on the modules page [1] explaining exactly what each module is for and when to use it. Right now, I'd say the state of the library, rather than its intention, is that it's extremely usable for people who pretty much know what they want, and fairly hard for the average developer to misuse. But I believe the author would be very interested in something that makes the library cater better to people who don't want to learn crypto, but just want to get things done using it. [1] https://docs.rs/orion/0.15.5/orion/index.html#modules https://docs.rs/orion/0.15.5/orion/index.html#modules EDIT: After some thought, I think I would say that the API for Orion is maybe an 8/10 for beginners, but the documentation is still at maybe 5/10 or 6/10 for beginners. Someone who is familiar with crypto would probably be able to look at the documentation and know what they're doing, but for someone unfamiliar with crypto, I can see how there isn't a ton in the way of explanation of the various primitives. That would be a good area for improvement for the library.
- tptacek 6y agoProbably the Google-sponsored cryptography library you want to use is Tink, whose maintainers include Daniel Bleichenbacher, Sophie Schmieg, and Thai Duong. https://github.com/google/tink https://github.com/google/tink
- TheNorthman 6y agoProbably the Google-sponsored cryptography library you want to use depends on the language you're using... Not much point in using Tink if they don't expose a C-api or any other ergonomic form to make Rust bindings.
- organian 6y agoProject Oak (at Google) are working on Tink Rust: https://github.com/project-oak/tink-rust https://github.com/project-oak/tink-rust, although with this caveat: This is not an official port of Tink, and is not supported by Google's cryptography teams.
- TinkersW 6y agoLooks like an unusable mess for C++, this seems to be common problem with all of these crypto libraries-- just too many files and too complex of a build system(shocker not everyone uses CMake).
- ilammy 6y agoTime for some shameless plugs! Themis [1] has been doing this “hard to misuse” thing for quite a few years. It has major focus on interoperability: supports a dozen of languages, with Rust among them, across all major desktop, mobile, and web platforms. It tries really hard to hide all the crypto mumbo-jumbo from the users so that they don’t have to be experts in algorithm choice and protocol design in order to safely use a library instead of shooting themselves in a foot. Themis is also a wrapper over OpenSSL/BoringSSL, relying on proven crypto implementations instead of trading a simpler build system for god knows how many sleeper primitive implementation bugs. However, binary packages exist for major distros, so if you don't want to build from source you can avoid that easily. Also, docs for humans do exist [2], packages exist, etc. [1]: https://github.com/cossacklabs/themis/ https://github.com/cossacklabs/themis/ [2]: https://docs.cossacklabs.com/themis/ https://docs.cossacklabs.com/themis/
- moonchild 6y ago> difficult to misuse Sounds similar to the motivation behind nacl[1], though my understanding is that most development now happens in libsodium[2]. 1. https://nacl.cr.yp.to/ https://nacl.cr.yp.to/ 2. https://doc.libsodium.org/ https://doc.libsodium.org/
- netsec_burn 6y agoI wish it was easy to cross compile libsodium in Rust.
- chrisdinn 6y agoI see raggi has patched, is this what they’re using in Fuchsia?
- mqus 6y ago> Disclaimer: Mundane is not an officially supported Google product. Because google support wouldn't be reliable enough /s But honestly, doesn't the license usually tell such things?
- im3w1l 6y agoTensorflow readme.md doesn't have that disclaimer, so I think it really does mean something.
- dikei 6y agoIf it's not using Bazel to build, it's probably not used much inside Google.
- weitzj 6y agoI am wondering why they don’t use the google/tink project on GitHub where you already have a fair amount of languages (Java, C++, Go, Python) doing AEAD, etc. Just add another language, and reuse the protobuf definitions.
- timdaub 6y agoFrom the BoringSSL readme: > BoringSSL is a fork of OpenSSL that is designed to meet Google's needs. > Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
- lionkor 6y agoWell, mundane isn't 3rd party, since it comes out of google as well.
- im3w1l 6y agoWill this decrypt nacl/sodium messages? If different choices were made so that it wont, what was the motivation?
- sitkack 6y ago> In order to avoid errors at link time due to conflicting symbols, we build BoringSSL with a custom prefix for all of its symbols which is based on the name and version of this crate. That way, even if multiple different versions of Mundane are present in the same dependency graph, none of the symbols from one version's BoringSSL will conflict with the symbols from another version's BoringSSL. This is awesome! I love you!
- deleted 6y ago[deleted]