5 ms·

Mundane: Rust cryptography library backed by BoringSSL

120 points by briansmith 8y ago

QuinnWilton 8y ago
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.
- cyphar 8y ago
  It is very interesting, though I do have a small gripe with how they characterise the "goto fail" bug. #[must_use] probably wouldn't have helped because the bug was that they effectively returned Ok() early. However, having an ergonomic error handling design in a systems language definitely helps. try! and ? are actually a massive improvement in the state of systems languages. Error handling is very important when designing a language.
- blub 8y ago
  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.
  - lifthrasiir 8y ago
    > It is almost never okay for a library to abort the process. Using Joe Duffy's distinction [1], bugs aren't recoverable errors. Error handling admits the necessity of error recovery, but you generally don't have such a fine-grained policy for bugs. A dual-use of exceptions as a means to signal bug conditions is unfortunate, and I believe Mundane's policy is clearly following this distinction. Also, panicking in Rust can be caught in the same thread [2]. So it is actually much more flexible than process abort---if you need a general, umbrella protection against bugs, here you have a way. [1] http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/ [2] https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.h...
    - blub 8y ago
      That's a thought provoking article, and I see no problem with the proposed error management technique as a whole, for that particular project. This however is a crypto library designed to run on consumer OSs, as part of programs which will likely offer much more functionality that generating random numbers. In general, a bug is a software fault, which is a passive flaw in the program, introduced by a programmer. Faults can manifest and cause the program to behave in an uninteded way, which in turn can lead to failure - the program can no longer perform its function. Any point on the fault -> error -> failure chain can be an intervention point. The relevant point for this discussion is the detection of errors and preventing them from becoming system failures, and if not possible, handling those gracefully. Let's agree not to discuss recovery attempts and assume that the system is instead moved directly to a safe state when such a bug/error is detected. A crash-only safe state is simple and quite easy to implement, but whether it's the best approach for a particular software depends on the dependability requirements of that software. Abandoning the current operation and returning to the top level execution context is an alternative that shouldn't be so easily dismissed. In the BoringSSL case, there doesn't seem to be a reason to abort. The error condition is known, can be detected and failure can be returned just as easily. Panicking is also fine, if the parent program can react to it.
      - 8y ago
- vkjv 8y ago
  The `miscreant` library also does this: https://github.com/miscreant/miscreant https://github.com/miscreant/miscreant. It's really effective. For example, any method that requires a one time pad takes ownership. This allows the borrow checker to validate that you don't accidentally use an OTP more than once.
mrath 8y ago
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 8y ago
  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 :).
  - mrath 8y ago
    > it would be wonderful to see one of them totally implemented in Rust Yes definitely. Crypto libs are so critical that building on something like BoringSSL is still good win. There were attempts made to build pure rust crypto libs, some of them are not maintained and some are a bit granular. I think pure rust lib similar to BoringSSL is going to be quite an effort
  - briansmith 8y ago
    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/6d86e5e7851181efc9ed3bf15765c0b59bb1.pdf https://pdfs.semanticscholar.org/3887/6d86e5e7851181efc9ed3b.... 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.
psergeant 8y ago
From the install notes, can someone tell me why BoringSSL needs Perl to build?
- chme 8y ago
  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/chacha/asm/ https://boringssl.googlesource.com/boringssl/+/master/crypto...
- floatboth 8y ago
  Worse: why does it need Go?
- mlindner 8y ago
  Perl is used to generate the final assembly files so they can be adapted between different x86_64 variants/systems/assemblers.
Animats 8y ago
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 8y ago
  https://github.com/ctz/rustls https://github.com/ctz/rustls
  - Animats 8y ago
    "ring exposes a Rust API and is written in a hybrid of Rust, C, and assembly language."
polskibus 8y ago
Is rust getting more popular inside Google in production use?
mlindner 8y ago
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.

120 points by briansmith 8y ago

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.

cyphar 8y ago
It is very interesting, though I do have a small gripe with how they characterise the "goto fail" bug. #[must_use] probably wouldn't have helped because the bug was that they effectively returned Ok() early. However, having an ergonomic error handling design in a systems language definitely helps. try! and ? are actually a massive improvement in the state of systems languages. Error handling is very important when designing a language.
blub 8y ago
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.
- lifthrasiir 8y ago
  > It is almost never okay for a library to abort the process. Using Joe Duffy's distinction [1], bugs aren't recoverable errors. Error handling admits the necessity of error recovery, but you generally don't have such a fine-grained policy for bugs. A dual-use of exceptions as a means to signal bug conditions is unfortunate, and I believe Mundane's policy is clearly following this distinction. Also, panicking in Rust can be caught in the same thread [2]. So it is actually much more flexible than process abort---if you need a general, umbrella protection against bugs, here you have a way. [1] http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/ [2] https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/stable/std/panic/fn.catch_unwind.h...
  - blub 8y ago
    That's a thought provoking article, and I see no problem with the proposed error management technique as a whole, for that particular project. This however is a crypto library designed to run on consumer OSs, as part of programs which will likely offer much more functionality that generating random numbers. In general, a bug is a software fault, which is a passive flaw in the program, introduced by a programmer. Faults can manifest and cause the program to behave in an uninteded way, which in turn can lead to failure - the program can no longer perform its function. Any point on the fault -> error -> failure chain can be an intervention point. The relevant point for this discussion is the detection of errors and preventing them from becoming system failures, and if not possible, handling those gracefully. Let's agree not to discuss recovery attempts and assume that the system is instead moved directly to a safe state when such a bug/error is detected. A crash-only safe state is simple and quite easy to implement, but whether it's the best approach for a particular software depends on the dependability requirements of that software. Abandoning the current operation and returning to the top level execution context is an alternative that shouldn't be so easily dismissed. In the BoringSSL case, there doesn't seem to be a reason to abort. The error condition is known, can be detected and failure can be returned just as easily. Panicking is also fine, if the parent program can react to it.
    - 8y ago
vkjv 8y ago
The `miscreant` library also does this: https://github.com/miscreant/miscreant https://github.com/miscreant/miscreant. It's really effective. For example, any method that requires a one time pad takes ownership. This allows the borrow checker to validate that you don't accidentally use an OTP more than once.

mrath 8y ago

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 8y ago
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 :).
- mrath 8y ago
  > it would be wonderful to see one of them totally implemented in Rust Yes definitely. Crypto libs are so critical that building on something like BoringSSL is still good win. There were attempts made to build pure rust crypto libs, some of them are not maintained and some are a bit granular. I think pure rust lib similar to BoringSSL is going to be quite an effort
- briansmith 8y ago
  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/6d86e5e7851181efc9ed3bf15765c0b59bb1.pdf https://pdfs.semanticscholar.org/3887/6d86e5e7851181efc9ed3b.... 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.

psergeant 8y ago

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

chme 8y ago
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/chacha/asm/ https://boringssl.googlesource.com/boringssl/+/master/crypto...
floatboth 8y ago
Worse: why does it need Go?
mlindner 8y ago
Perl is used to generate the final assembly files so they can be adapted between different x86_64 variants/systems/assemblers.

Animats 8y ago

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 8y ago
https://github.com/ctz/rustls https://github.com/ctz/rustls
- Animats 8y ago
  "ring exposes a Rust API and is written in a hybrid of Rust, C, and assembly language."

polskibus 8y ago

Is rust getting more popular inside Google in production use?

mlindner 8y ago

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.