google

mundane

Rust2018–2021

google / mundane

mundane

Mundane is a Rust cryptography library backed by BoringSSL that is difficult to misuse, ergonomic, and performant (in that order).

Security & Privacy Libraries & SDKs

Explore on GitHub Read Hacker News discussions

6Distinct people

7Mentions

0Explicit recommenders

1.1KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Mundane is a Rust cryptography library backed by BoringSSL that is difficult to misuse, ergonomic, and performant (in that order).

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year7 dated mentions

Observed mentions: 2018-11-06 23:06:15 UTC to 2021-08-06 00:10:52 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	3	1	2
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	2	0	2
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	1	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	0	1

What Hacker News says

7 sources

ak217·Aug 6, 2021

Most problems with security specs and libraries that implement them are communication problems. They involve people incompletely describing or understanding their requirements, capabilities, or threat model. Often this also involves providing/using interfaces that are not ergonomic (https://github.com/google/mundane/blob/master/DESIGN.md), which in turn can be caused by the spec trying to do too much (as XML Signature does). I don't know how GPT could help with that. If anything I would expect it to bias toward things it has already seen, which is the opposite of what you want when writing a new spec/library aiming to avoid past mistakes.

In SAML Is Insecure by Design

MrXOR·Dec 15, 2020Submission

Mundane: Rust cryptography library that is difficult to misuse

217 points · Open discussion

mezzode·Nov 8, 2019

https://github.com/google/mundane/blob/master/DESIGN.md was where I first learned about how useful opaque types can be for ensuring the type system does the heavy lifting

In Parse, Don’t Validate

ak217·Mar 4, 2019

Shameless plug of a WebAuthn relying party (RP) library that I implemented recently (Python server, JS client): https://github.com/pyauth/pywarp Having worked with a few different standards before, I was pleasantly surprised by how easy to understand and ergonomic (https://github.com/google/mundane/blob/master/DESIGN.md) the WebAuthn spec was.

In W3C approves WebAuthn as the web standard for password-free logins

lifthrasiir·Nov 7, 2018

> 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. Are you referring to getrandom(2)? Unless you are using `/dev/random` (i.e. GRND_RANDOM) instead of `/dev/urandom` (which by the way you don't need to use [1]), the only case that getrandom(2) blocks or fails is the very beginning of the machine startup where not enough entropy has been collected. It is not something you would expect to occur more or less randomly. [1] https://www.2uo.de/myths-about-urandom > 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. The O

Read the rest

P does explicitly say that it may be justified to make the function's API infallible. They strive to simplify the error case to handle (e.g. verification failure and other recoverable errors are combined to ease the error handling), and they are expected to exercise this right only when there exists no good and reasonable error handling strategy. By the way, it seems that Mundane actually does not panic but aborts the entire process [2] with a rationale that panic handling in Rust is not as trivial. This decision can be problematic by its own, but I found that aborts are only used to guard against generally improbable error cases, e.g. linking or calling to a different library that happens to provide the same set of symbols as BoringSSL. If you say that this should be caught gracefully, uh, I'd say that you should also guard against an invocation failure due to dynamic linkage failure for the sake of user experience... [2] https://github.com/google/mundane/blob/8aaa1c8/src/boringssl...

In Mundane: Rust cryptography library backed by BoringSSL

QuinnWilton·Nov 7, 2018

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 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.

In Mundane: Rust cryptography library backed by BoringSSL

briansmith·Nov 6, 2018Submission

Mundane: Rust cryptography library backed by BoringSSL

120 points · Open discussion