You are viewing content from a past/completed QCon

Presentation: Maintaining the Go Crypto Libraries

Track: 21st Century Languages

Location: Liberty, 8fl.

Duration: 11:50am - 12:40pm

Day of week: Wednesday

Share this on:

What You’ll Learn

  1. Hear about some of the features of Go’s cryptographic libraries.
  2. Listen about some of the challenges developing and maintaining such libraries, balancing the need for new features with the desire to reduce complexity.

Abstract

The Go programming language ships with a full suite of cryptographic libraries written in Go, including a TLS stack.

We will look at how that came to be, and what it enabled. The choice to keep it focused on carefully curated subsets of sprawling protocols like TLS was both a necessity, and its greatest value. We will explore how a focus on developer usability is important in ensuring the security of the ecosystem, and how that requires difficult targeting decisions.

We will talk about the challenges in maintaining it and keeping it secure, safe, useful and modern. In particular, we will see how security, scope and maintainer resources are on a balance, and what tools we can deploy to tip the scale.

Question: 

What is the focus of your work today?

Answer: 

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.

Question: 

What's the motivation for the talk?

Answer: 

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.

Question: 

What makes the crypto TLS library so good?

Answer: 

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.

Question: 

How do you choose the features not to implement?

Answer: 

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.

Question: 

How would you describe the persona and the level of the target audience?

Answer: 

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.

Question: 

What do you want attendees to walk away from a talk with?

Answer: 

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.  

Speaker: Filippo Valsorda

Cryptogopher @Google

Qcon

Filippo Valsorda works on the Go team at Google, where he owns the cryptographic libraries and acts as the primary security coordinator. Previously, he worked at Cloudflare, where he built their DNSSEC and experimental TLS 1.3 stacks, and maintained their Go DNS server, which was authoritative for 40% of the Alexa top 1M. He built mkcert and the Heartbleed test, and writes at filippo.io and twitter.com/FiloSottile.

Find Filippo Valsorda at

2019 Tracks

Monday, 24 June

Tuesday, 25 June

Wednesday, 26 June