Presentation: Maintaining the Go Crypto Libraries

My main focus is ensuring the security of the Go language ecosystem. I am the primary security coordinator for the Go project and I maintain and own all the crypto libraries in the standard library and in the golang.org excrypto repository. Even when developing the crypto libraries the main focus is to keep the ecosystem secure. So the crypto libraries are a means to that end.

The crypto libraries are fairly unique in how they came to be. Most other crypto libraries went for completeness and maybe performance as their main goals. The crypto libraries were made originally by Adam Langley to be a subset of functionality that allows application developers to develop safe applications. That has a number of interesting consequences in terms of how they were developed, in terms of how they're maintained and in terms of how the Go system gets to use them. The talk will focus on that.

That's very good to hear, of course. The language of course helps, Go does everything it can to be clear and it's a language optimized for readability. So of course when dealing with things like cryptography it's useful to have the language be as clear and as uncomplicated as possible because you already have enough complexity in the subject matter. On top of that it implements limited subsets of functionality to keep complexity down. It can focus on developing what is there more effectively. And it focuses on being safe to use and having safe APIs even internally so that even when developing the internals of the library you will find comments and documentation about how to use the internals. So, yes, primarily by keeping complexity down and by benefiting from the fact that the language helps. We've learned a lot from all the older libraries both in what to do and what not to do.

That's the hardest part of my job. I tried to formulate that in terms of four priorities: security, safety, usefulness, and moderness. And they tried to keep them approximately in this order. First and foremost, things need to be secure. If I don't feel like we have the maintainer capacity to verify that an addition is secure and to keep it in time, that's just a first barrier to adding features. If a feature is not possible to expose in a safe way, it's something that is easily misused and hard to provide to application developers in such a way that it will not cause trouble. That's another barrier. And then it comes down to figuring out what's useful to the ecosystem and what's not. That indeed is the hardest part because of course anybody who needs a feature will find it useful. I often say that everybody wants their own proposal accepted and everybody else rejected because they do appreciate the lack of complexity and the fact that they don't have to twist 100 knobs to configure the libraries. I would conclude by saying that I think application developers appreciate the simplicity but at the same time of course sometimes they need to get something done that involves compatibility. The hardest choices are the ones that require making a tradeoff between adding complexity and supporting compatibility with other systems.

The target audience is any developer that has found themselves either in two positions: one that of maintaining a library where they had to control complexity and limit additions and be that annoying person that has to reject requests, or any developer who does or has used crypto libraries and understands more of what goes into the design of one, and anybody who has had negative or positive experiences using crypto APIs.

As we're talking about an understanding of what the philosophy of the Go crypto libraries is, an understanding of the fact that they can rely on the Go crypto libraries, but also I want to give them more visibility to the value of saying no in software development because it's easy to measure and we often celebrate complexity, but sometimes simplicity requires as much work but is much less visible and much less acknowledged.