
Mundane: Rust cryptography library backed by BoringSSL - briansmith
https://github.com/google/mundane
======
QuinnWilton
The repo includes a DESIGN.md file that describes the design motivations for
the library, and it's definitely worth reading. It goes through a few really
powerful techniques for writing misuse-resistant APIs, and I think some of its
advice is applicable to good software engineering in general.

[https://github.com/google/mundane/blob/master/DESIGN.md](https://github.com/google/mundane/blob/master/DESIGN.md)

In particular, their use of the type system to expose opaque types that only
allow meaningful operations on them is something that I've seen used to great
effect in other statically typed languages, like Haskell.

~~~
blub
One exception to the otherwise solid design principles:

"If an error requires particularly subtle error-handling, prefer panicking or
aborting the process. When cryptographic operations fail in a way that would
require reporting an error to the user (in other words, there's no valid non-
error interpretation like in the case of signature verification), and handling
that failure is particularly error-prone, it may be justified to make the
function's API infallible, and instead panic or abort the process on error.
BoringSSL famously does this when failing to read randomness (e.g., from
/dev/urandom), as this has historically been a source of vulnerabilities."

It is almost never okay for a library to abort the process. The only exception
I can think of is when discovering e.g. memory corruption or other UB, or when
continuing would result in the above.

~~~
PudgePacket
> It is almost never okay for a library to abort the process.

For a library with a design principle to be as hard to misuse as possible it
seems like the right decision, and the "exception to the rule".

Infinitely better to crash than to potentially let the process/library run in
some kind of degraded state.

If you are aware of this behaviour and are savvy/experiences enough you'll
either 1) Catch the panic and perform an appropriate library 2) Use a
different library.

~~~
blub
The issue is that the library can't know what state the program is running in,
since it's a library... it has a job to perform some crypto functionality and
it can only either return a result or an error for that particular operation.

When libraries start calling abort out of the blue it's like the janitor
deciding to send everyone home for the day because their mop broke. It's not
their call to make :)

Panicking or any other error handling mechanism which permits the main
application to decide how to continue is perfectly fine.

~~~
adwn
> _When libraries start calling abort out of the blue it 's like the janitor
> deciding to send everyone home for the day because their mop broke._

A more apt analogy would be the janitor that pulls the fire alarm because they
saw smoke coming out of the boiler room. So yes, it's their call to make, and
it would be the right call.

Besides, as lifthrasiir points out, you can isolate this behavior in Rust,
akin to triggering the fire alarm for a single building, but not for the
entire complex.

------
mrath
There is also ring[1] which is somewhat based on BoringSSL. May be their
priorities/philosophies are different. It is nice to see more crypto libs
being developed for Rust.

[1][https://github.com/briansmith/ring](https://github.com/briansmith/ring)

~~~
vvanders
I know it's too early to ask but it would be wonderful to see one of them
totally implemented in Rust. Any time in include one of the crypto wrappers
building for non-linix targets(wasm/asmjs or win32) ends up being a massive
pain.

The base Rust experience is so nice that it ends up spoiling you :).

~~~
briansmith
We are continuing the project of replacing C code with Rust code in _ring_.
The pace of that effort is mostly a function of how much work time I have
available to spend on _ring_.

Day-to-day _ring_ development happens on Windows and it was designed to "just
work" on Windows (as well as Linux, macOS, Android, iOS, and other supported
target operating systems). We did a huge amount of work to make the build
system fully automatic to enable this, and we have a pretty extensive CI
mechanism to make sure everything "just works" as much as we can.

As for WebAssembly, I'm looking forward to something like
[https://pdfs.semanticscholar.org/3887/6d86e5e7851181efc9ed3b...](https://pdfs.semanticscholar.org/3887/6d86e5e7851181efc9ed3bf15765c0b59bb1.pdf).

However, you should probably use the WebCrypto API in a web app if at all
possible, instead of a wasm crypto library. Unfortunately the WebCrypto API is
100% asynchronous whereas almost every other crypto API is 100% synchronous so
that's easier said than done. Really browsers should add a synchronous
WebCrypto API; then crypto libraries can transparently delegate to it when
targetting wasm.

~~~
amenghra
async/await makes it pretty easy to take an async library and use it in a
synchronous context.

~~~
eridius
No it doesn't. await doesn't make asynchronous functions synchronous. It just
changes how you write the code, not how the code itself works. Notably, await
can only be used from inside an async function.

------
Animats
The BoringSSL build system has the following dependencies:

\- CMake 2.8.11 or later

\- Perl 5.6.1 or later.

\- Either Make or Ninja.

\- A C compiler

\- Go 1.11 or later

\- To build the x86 and x86_64 assembly, your assembler must support AVX2
instructions and MOVBE.

It's time for a pure Rust replacement for OpenSSL. This is a shim to call a
Google fork of OpenSSL.

~~~
dochtman
[https://github.com/ctz/rustls](https://github.com/ctz/rustls)

~~~
Animats
_" ring exposes a Rust API and is written in a hybrid of Rust, C, and assembly
language."_

------
mlindner
Well this is indeed Mundane. This is just a Rust frontend to an OpenSSL fork.
There's nothing of major interest here and not sure why it's getting
attention. There are already Rust frontends to OpenSSL.

------
polskibus
Is rust getting more popular inside Google in production use?

------
psergeant
From the install notes, can someone tell me why BoringSSL needs Perl to build?

~~~
chme
I guess for the same reason OpenSSL needs Perl, to generate some files.

IIRC most notable the ASM files are generated via Perl.

Update: Here is a link to some Perl BoringSSL stuff:
[https://boringssl.googlesource.com/boringssl/+/master/crypto...](https://boringssl.googlesource.com/boringssl/+/master/crypto/chacha/asm/)

