Tweet

Lea Kissner

9 Jul, 14 tweets, 4 min read

@yonatanzunger

Non-cryptographers should be scared of crypto libraries. I'm not happy with that state (not every company has a friendly local cryptographer! or even an unfriendly one!), but that's sadly the state of things.

A story about my friend @yonatanzunger messing up, then suggestions.🧵

@humuinc

Yonatan went off to work for @humuinc several years ago (though he's at @Twitter now) and, being a small startup at the time, there were unsurprisingly zero cryptographers.

So one day I get a message from him asking what crypto library he should use, to which I replied "WHY???"

The reason I replied with serious "oh no" in my heart was that people screw up using crypto libraries all the time. So I wanted to know what he wanted to do with said library.

And what he wanted to do was encrypt some data and put it in a cookie so users couldn't mess with it.

The crypto-savvy among you are already cradling your aching heads in your hands. For the rest of you, let me explain where Yonatan went wrong: encryption does not (necessarily) stop anyone from *changing* the encrypted data. It stops people from *seeing* the encrypted data.

... let's just say that the design he had worked out didn't get better from there. So I explained a bunch of cryptography, he learned a great many new and interesting things, and Humu got to have secure cookies.

@Twitter

Everyone wins, but only because Yonatan happened to have a friend with a literal PhD in crypto. Not everyone has a crypto buddy, though!

(I cannot be everybody's crypto buddy. I have a job where I spend my time doing many interesting work things @Twitter. 😁)

Context: Yonatan is one of the smartest people I know. He's pretty dang good with computer stuff. Many folks can vouch.

If he can't use a crypto library without shooting himself vigorously in the foot, almost nobody can. And we also know this for two other reasons:

1. A huge percentage of the bad crypto-related vulnerabilities are because someone used the crypto wrong, or the wrong crypto, rather than the underlying crypto being bad. Check the CVE database; I don't have a pointer to a real study, but I'm willing to bet on it.

2. A whole plethora of papers at SOUPS studying how developers use crypto libraries. Spoiler alert: there's a lot of cut-and-pasting of (often bad) code off Stack Overflow. When you don't let them do that, they tend to mess up.

So ideally you would have a crypto library that is aligned around specific use cases like "I'm going to put this in a cooke, don't let anyone change it" or "I want to send this information secretly to <Alice>" or "this is going in a URL it's got to be small".

But here are a few heuristics:
1. If you ever ask a non-cryptographer to choose a crypto algorithm, that is bad. Especially if 3DES is an option.

2. They don't usually know what public or symmetric key encryption is, but they *really* care about whether you need to make a live call every time you do something (e.g. decryption, validation)

What are your other design guidelines for crypto libraries?

Opinionated design is often necessary to get good design, crypto libraries are a really good example of this thank you for coming to my crypto library rant.

@XorNinja

BTW, the discussions in my mentions are: a) making me so happy (these are incredibly smart people like @XorNinja and @SchmiegSophie and @FiloSottile who are dedicated to reducing these issues) and b) a really good Illustration of why this is still hard for developers. 😅

• • •

Missing some Tweet in this thread? You can try to force a refresh

This Thread may be Removed Anytime!

Twitter may remove this content at anytime! Save it as PDF for later use!

More from @LeaKissner

Lea Kissner

@LeaKissner

29 Jun

I realized today that I had never talked publicly about something really important about the design of access control systems: design their semantics to be reverse-indexable.

This is a much spicier take than it sounds like, but there's a good reason. 🧵 [1/]

Right now, access control systems are built so you can show up and say "I want access to object X", the system looks up the access control rules for object X, and then figures out whether you should have access. [2/]

With the exception of a few corner cases, the semantics of access-control system you build should be able to be turned upside down. For this you want a reverse index (which wikipedia calls an "inverted index").

en.wikipedia.org/wiki/Inverted_… [3/]

Read 9 tweets

Lea Kissner

@LeaKissner

10 Jun

@Facebook

It's time to kick off an entire session about data deletion at #PEPR21 (It's hard!) with "Deletion Framework: How Facebook Upholds its Commitments Towards Data Deletion" from Benoît Reitz, Facebook

That's right, come one come all, this is @Facebook' data deletion framework.

We can't expect people to write their own data deletion logic.
* They often don't know how to do it well and write bugs
* The deletion logic and data definition may drift apart over time

So we get annotations that people put on their storage

Annotations example. There are multiple different types of edges, like "deep" saying when a post is deleted, the comments should also be deleted.

If it's a "shallow" edge, it should delete the association but not the object (e.g. a post is deleted but not the whole user)

Read 23 tweets

Lea Kissner

@LeaKissner

10 Jun

It's time to talk about consent at #PEPR21 starting with "Designing Meaningful Privacy Choice Experiences for Users" by Yuanyuan Feng, Carnegie Mellon and Yaxing Yao, University of Maryland

Notice and choice is a legal framework. There are privacy notices which tell people about the practices. The controls let people have limited controls.

But in practice the controls are usually difficult to find, overly simplified, and sometimes manipulative using "dark patterns"

Dark patterns manipulate people into making choices they might not otherwise make. For example, the terms/policy are linked in tiny type and there's only one button: sign up. Any choices are hidden behind this, which is suboptimal.

Or the pre-selected options may not be good.

Read 14 tweets

Lea Kissner

@LeaKissner

10 Jun

Next up at #PEPR21: Cryptographic Privacy-Enhancing Technologies in the Post-Schrems II Era

from Sunny Seon Kang, Data Privacy Attorney

Going to provide context on CJEU case C-311/18, aka "Shrems II"

This launched companies into a whole tizzy because they said that folks needed "supplementary measures". What the heck is that?

Without Privacy Shield, you can't transfer data from the EU to the US (thanks, Shrems I), because the US isn't considered to have "adequacy" [essentially strong enough protections under the law. People were pissed about Snowden]

Read 16 tweets

Lea Kissner

@LeaKissner

10 Jun

@Google

First up at #PEPR21 "Privacy for Infrastructure: Addressing Privacy at the Root" by Joshua O’Madadhain and Gary Young from @Google.

Because hey, privacy is a full-stack problem, from humans and the societies they build all the way down to the hardware. Infrastructure is key.

Both Josh and Gary have been at Google for "a while" (I think that's about 15 years each) and are both wizzes when it comes to privacy, especially in infrastructure.

Infrastructure is systems that provide other systems or products with capabilities [not the security kind]

Types:
* storage systems
* network systems
* data processing systems
* server frameworks
* libraries
* system integrations
* etc.

Read 29 tweets

Lea Kissner

@LeaKissner

3 May

More and more folks want to hire privacy engineers. This is great! You almost certainly need them! But, just like security, privacy engineering is a whole field.

So for the folks who want to hire or become a privacy engineer, a rundown of the current rough types I see. (Big🧵)

First off, let's talk about the two things that people want out of a privacy engineer: (1) privacy-respecting products and systems, (2) compliance.

Compliance is making sure that all the correct paperwork is filled out showing that you followed the rules. Here's the thing...

Compliance is necessarily reactive. It's responsive to failures of the past. If you're doing new things, then you're likely to hit new failure modes. For you, compliance isn't going to be sufficient. Because when things go really wrong, no one cares about paperwork.

Read 26 tweets

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!