[Cryptography] How to De-Bollocks Cryptography?

[Jon Callas]

> On Aug 5, 2024, at 04:53, Ralf Senderek <crypto at senderek.ie> wrote:
> 
> If you have any idea how to attack the complexity problem,
> hammer it out and post it here, it might be developed into
> a candidate for consent.
> 
> Be practical and be constructive.


The problem with the Einstein quote is one that he knew himself as he said it -- it's a wry aphorism that has no actionable advice.

At best, you're going to get to some "I know it when I see it" which is better than nothing, and then we get into debates when someone else knows it because of what they see, and what they see is the opposite of what you do.

If you have not read Don Norman's "Living with Complexity" <https://mitpress.mit.edu/9780262528948/living-with-complexity/>, do so. It's the most practical and constructive thing I can think of to read about the topic. 

You need to read it yourself, because what resonated with me is not going to be what resonates with you, but one of the things I took away is the idea that simplicity is misleading. There's so-called Tesler's Law, or the Law of Conservation of Complexity -- that you can shove complexity around, but you can't get rid of it.

One of the examples that resonates with me is that in UX design, there are two UX paradigms that are praised from many places for their simplicity. They are (1) the now-traditional direct-manipulation GUI like what Macs, Windows, etc. all have, and (2) the unix command line.

If we look at why they're considered simple by the people that value them, (1) is praised because it has relatively few knobs, but each one has a complex behavior. (2) is praised because it has many knobs, each with limited behavior and you can string them together for complex things.

That tension repeats itself in many places -- do you want few options with a lot of context and complexity behind the scenes, or do you want many options, each of which is simple, but the complexity is how you string them together?

One of Norman's other major points is that the systems we build must mirror the complexity and richness (richness, remember, is complexity we like) of the world. If the world is complex, a simple solution will end up being complexly bent to work within it.

Another way to think of the issue is to consider which is more complex: a Swiss Army knife or a tool roll with a knife, screwdriver, scissors, etc.? Phrasing the same question the other way, which is simpler? Is it one tool with a bunch of things, or a collection of single-purpose tools?

As another thought experiment, let's consider securing a building.

The simplest way to do it is to have only one door into it. Everything goes through one door, so that's obviously simpler. Someone else is going to say that it's simpler to have a door and a loading dock, so the people at the front door are not having to vet deliveries, they deal with employees, visitors, and customers. There are other considerations that come along too, like safety. Fire codes say you have to have multiple exits, so like it or not you have to have those, and it's probably suboptimal to conflate the exit with the loading dock.

Then there are other things, like windows. Surely it's more secure to have no windows, right? Yet should you build such a building, the acid commentary about how horrible the building is it going to have the phrase, "doesn't even have windows" somewhere near the top of the invective about how horrible the design is. The complexity of reality -- that people want windows -- feeds directly into the simplicity or complexity of the security.

I can go on, you get the point.

There's another issue, as well, and that is that we don't do security or cryptography for themselves. We don't go build secure systems. The cliché is that the most secure computer is the one that's turned off. The most secure network is the one that doesn't transmit packets.

We do cryptography in service of something else. I got into cryptography because I was working on collaboration systems. My users complained that they did not want to collaborate where "anyone can steal my ideas." There was no SSL at the time, so I started off on a side-quest to put in a feature to make it so that people could collaborate securely. The real mission people working together, not anything else.

Now at the same time -- yes, absolutely, there are plenty of security systems that have too many fiddly bits that add no value. How many hours do you have for me to rant about it? Nonetheless, a lot of complexity ends up in a system because it's trying to do something complex. Our systems get more complex because we want to do more things with them. 

If all you want is a "focused writing device" that's basically just a typewriter modernized, it doesn't need a lot of security, because it doesn't do much. It would be more secure to have no network and just one writing app. It would be more secure to just not do networking, not do computing. And yet most people reading my words about that are going to roll their eyes and sigh, as if I'm dodging the whole point.

It's easy to say complexity is the enemy of security, and hard to do. And hard to define what complexity is, what security is, (I haven't even mentioned that security is a relationship or a quality not a thing) as well as hard to define what we want the systems to do and be in their relationships with us.

At the end of the day, it's hard to do something actionable with that advice. The whole situation is -- ummm, well -- complex.

	Jon