[HN Gopher] Mundane: Rust cryptography library that is difficult...
___________________________________________________________________
Mundane: Rust cryptography library that is difficult to misuse
Author : MrXOR
Score : 69 points
Date : 2020-12-15 19:57 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ilammy wrote:
| Time 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.
|
| Also, docs for humans do exist [2], packages exist, etc.
|
| [1]: https://github.com/cossacklabs/themis/
|
| [2]: https://docs.cossacklabs.com/themis/
| the_duke wrote:
| Mandatory 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
| [deleted]
| richardwhiuk wrote:
| Another alternative is
| https://docs.rs/sodiumoxide/0.2.6/sodiumoxide/ - bindings to
| NaCL.
| octoberfranklin wrote:
| Yeah the golang dependency just seems bizarre.
| adkadskhj wrote:
| I 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 wrote:
| I 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
| Tobu wrote:
| I don't know what this is doing here.
|
| ring is also hard to misuse, and more actively maintained by far.
| vlmutolo wrote:
| This 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
|
| [2] https://docs.rs/orion/0.15.5/orion/aead/index.html#example
| adkadskhj wrote:
| Orion 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 wrote:
| That'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
|
| 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.
| kilburn wrote:
| The libsodium's docs [1] are awesome in this regard,
| particularly the sections (and subsections) on secret-key and
| public-key cryptography.
|
| If you study those docs you'll get the modern terminology
| used by most other libraries as well as the intended use-
| cases for the different cryptographic constructs.
|
| Your examples point to public-key use-cases, and I don't see
| any public-key crypto support in this Orion library, so
| probably you just wouldn't use it ;)
|
| [1] https://doc.libsodium.org/
| tptacek wrote:
| Probably 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
| TheNorthman wrote:
| Probably 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.
| dmitriid wrote:
| So, judging from zero docs, it's hard to misuse because you
| wouldn't even know how to use it.
| brundolf wrote:
| Documentation 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 wrote:
| I 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.
| muricula wrote:
| This may be the documentation:
| 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.
| dathinab wrote:
| https://docs.rs/mundane/0.4.3/mundane/
| jeffbee wrote:
| Hilarious build-time dependencies. You need Perl _and_ Go _and_ a
| C++ toolchain to build a Rust library!
| frenchy wrote:
| Can't misuse it if you can't even build it.
| vmchale wrote:
| I do admire it!
| makeworld wrote:
| Note that these are the requirements of the BoringSSL
| dependency, not the project itself.
| octoberfranklin wrote:
| That 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.
| [deleted]
| brundolf wrote:
| It 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 wrote:
| > 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 wrote:
| I think the intended meaning of "your own crypto" is
| "greenfield crypto"
___________________________________________________________________
(page generated 2020-12-15 23:00 UTC)