Schneier on Security

Nate • November 9, 2015 6:41 PM

I don’t see any use case for blockchain technology at all, sorry.

It is a protocol designed for one purpose: to achieve probabilistic (assuming less than 50% centralisation) consensus among hostile mutually non-trusting actors, many of whom are active in organised crime, most of whom are involved in obvious scams, and all of whom are motivated by millions of dollars of potential gain. To try to achieve trust, it not only doesn’t scale, it is designed to anti-scale – to aggressively consume computing and power resources in a attempt to remain decentralised.

But that didn’t work. Economics of scale, an exponential technology race, greed, and the block mining reward designed into the protocol have forced mining to consolidate into an oligoply. There is no longer any point to the blockchain. It consumes vast resources to generate no trust, because the economics of mining concentrates power in fewer and fewer hands.

In one respect it’s working admirably well. It was designed to emulate the operations of capital markets on a rare commodity like gold, and it’s doing exactly what Marx pointed out over a century ago that capital always does: centralise power and reduce freedom.

This is the opposite of what the blockchain is claimed and believed to do, sure. But a technology is what it does, and it was designed to emulate capital accumulation, and that’s what it’s doing. It’s a great object lesson on why the free market cannot remain free without regulation, but not much more.

A ‘trusted private blockchain’ would be a contradiction in terms. If you have privacy and trust, you don’t need the vast inefficiency of a blockchain – which is just as well, because as observed, it doesn’t work.

tldr: Just use a database instead.

Nate • November 10, 2015 3:42 PM

@Nick P: Ooh, thanks for that Fabric link. I’ve been tossing around ideas somewhat similar to this for ages. I’m interested in anyone trying to build a decentralised compute/store cloud.

Basically I see three major, huge design flaws in Bitcoin and the blockchain:

1. Proof of work as a security principle is FATALLY flawed. It anti-scales – it aggressively fights scaling by consuming resources – and yet it can still be trivially gamed by hostile actors simply by throwing more resources at it until the biggest oligarch (the one with their own chip foundry and powerstation, or who can steal power) wins. Sorry, but that’s a failure, not a solution.
2. Storing every transaction in one shared public log file means there’s no privacy, AND that the log file grows continually on the order of the number of transactions per day in the entire world. That’s not scalable, and it eliminates privacy.

As the Silk Road case demonstrated, transactions on the Bitcoin blockchain are ‘prosecution futures’. Don’t use blockchain technology for anything illegal, or anything you would like to remain private. Everything you do is broadcast to everyone. It may be ‘pseudonymous’ but unless you’re absolutely obsessive about operational security, it’s very easy to trace the links.

A much better solution would be one that didn’t require broadcasting an entire ledger to the whole planet and storing it forever.

1. Sequential verification of transactions across the entire blockchain means a huge bottleneck and it’s why Bitcoin’s tps is so slow. Again, this is laughably poor engineering compared to what transaction processing systems were doing in the 1960s even. There needs to be a way of doing most transactions in parallel and only syncing the ones that have dependencies that really need to be done in serial.

I do think that we need a messaging network over the Internet that is:

1. distributed (so anyone can publish and receive)
2. persistent (stores messages, doesn’t discard them immediately)
3. publish-subscribe based (so you only get the messages you care about)
4. allows anyone to publish arbitrary data (not limited to 140 char text!)
5. cryptographically secured (so no-one can spoof or change your messages)
6. can do computation as well as dumb messaging (so we don’t need Javascript)
7. is functionally pure (so no side effects, and uses functional reactive programming for I/O)

What we don’t need are the three flaws of Bitcoin’s blockchain: exponential resource consumption as more nodes come online (and its corollary, that anyone with sufficient hardware outlay can spoof the network), unfiltered public broadcasting, and enforced serialisation

@Gerard van Vooren:

I agree that S-expressions are a much better base for a fundamental syntax than HTML’s SGML/XML. I like that a fairly simple mapping between them exists: SXML. https://en.wikipedia.org/wiki/SXML

My feeling is that we need not so much new programming languages but new data representation languages. Because we have so much data now that needs to persist through multiple systems.

A data representation language that wants to be used for a long time across multiple systems needs to have as little syntax as possible, because a huge problem for ‘bit-rot’ is that different serialisation syntaxes can corrupt data at the syntax level, and each have very different escaping semantics. Bad handling of syntax escaping is one of the worst security problems to solve – witness SQL’s issues with embedded quotes, which come from a (bad) choice in ASCII to have only a single straight quote character, so there’s no way to detect and reject mismatched quotes.

If we used parens rather than quotes to delimit strings, the SQL quote injection issue would go away. But we can’t use parens to delimit arbitrary strings in most Lisps, because, on top of the minimal S-expression base of (.) they reserve a whole bunch of punctuation characters.

Syntax is important, and I wish we paid a LOT more attention to it than we currently do. We could eliminate whole classes of errors.

Nate • November 10, 2015 4:40 PM

Gah. That last part was broken by, you guessed it, syntax escaping issues. I mean to write

Why don’t we already have [include] tags in HTML5?

but of course I used angle brackets and so it vanished, silently, with no error.

This is EXACTLY the kind of foundational syntactic stuff we need to fix, folks, before we can build the tottering Internet tower any higher. Add up all these little data corruption and bitrot issues and it becomes a nightmare, especially for security.

Nate • November 10, 2015 7:47 PM

An alternate syntax I’ve been playing with to solve this data representation problem is a very slight extension of S-expressions. Take dotted-pair lists, and instead of just one value after the dot, allow multiple values. This can represent a table or dictionary structure with arbitrary keys AND collapses to a simple sexp list in the case of single values.

(. (loves . (alice bob) (bob carol))
(believes alice (loves bob alice) 50))

or, if we rewrote it in object-oriented format:

(. (alice . (loves bob) (believes (bob loves alice) 50)
(bob loves carol))

The underlying data model for all nodes in this structure is a binary relation: ‘a set of cons pairs’. You could represent SQL tables, Prolog predicates, text files, functions, relations. I reckon it would serve as a minimal but universal data structure for almost anything. It would at least be a small step up from S-expressions (adding the idea of logical AND / set union / parallelism), and two small steps up from ‘unstructured sequence of ASCII or Unicode characters’. It could store more than SQL or CSV could. And it wouldn’t be as noisy and restrictive as either JSON or XML.

Binary relations are extremely well studied in mathematics. But an interesting result is that this data model (set of cons pairs, or binary relation) is just slightly MORE expressive than computing’s favourite data structure: ‘dictionary’, ‘table’, ‘object’ or ‘function’. It has the ‘nil’ element – required to properly represent lists – which there’s simply no equivalent for in, eg, a function, or a dictionary. That’s a subtle but VERY important difference. What does it mean? I’m not sure, but it’s definitely not nothing. It may even represent something like ‘logical truth’ (I’m pretty certain that the empty set is a good match for ‘logical falsehood).

This is the sort of thing I’m talking about when I say the foundations of computing are unclear. There are very deep mathematical structures that, if we followed, would make our lives much easier; and when we ignore them, make our lives hard. Instead we tend to hack things up that almost work and solve some problems but aren’t mathematically solid and 100% correct. And that means they’ll fall apart when we lean on them too hard. And because they fall apart, we end up proliferating a huge array of mutually incompatible partial solutions where one correct solution would be enough.

Remember, a deep problem (maybe THE deep problem) in computing is not just representing data correctly enough to solve one problem and then throw it away. It’s finding a represention for data that can persist for a long time and be useful for a number of DIFFERENT problems. During its entire lifetime this data should be easy for both humans and computers to read, take a minimum of mental effort to parse, and not subtly lose information in each transformation between systems.

I don’t believe we’ve come close to solving that yet, which is why I find it an interesting problem to think about.

Nate • November 11, 2015 4:18 PM

Specifically, the thing I think is missing from the Kanren family is Prolog’s very close data-code equivalence – something which is a deep strength of Lisp.

As I understand it, Kanren is an ’embedding’ of logic programming in Scheme – usually done with macros that convert relations into functions – which means that a Kanren relation can’t typically access the raw logic assertions of the database. This is in line with the doctrine of functional programming that data shouldn’t be unnecessarily shared, and that’s good as far as it goes. But it seems to somehow miss the most beautiful thing about Prolog. As Will Byrd (miniKanren) describes:

https://stackoverflow.com/questions/28467011/what-are-the-main-technical-differences-between-prolog-and-minikanren-with-resp

“One very interesting feature of Prolog is that Prolog code is itself stored in the global database of facts, and can be queried against at run time. This makes it trivial to write meta-interpreters that modify the behavior of Prolog code under interpretation. For example, it is possible to encode breadth-first search in Prolog using a meta-interpreter that changes the search order. This is an extremely powerful technique that is not well known outside of the Prolog world. ‘The Art of Prolog’ describes this technique in detail.”

This means a Prolog predicate is not just like a dynamically-bound old-school Lisp function – it’s even more like an old-school Lisp macro (or FEXPR, actually, for the history fans – https://en.wikipedia.org/wiki/Fexpr . I feel like John Schutt is much more correct here than Mitchell Wand, and that a wonderful, deep tool was lost when FEXPRs were unjustly vilified and burned in the 1980s.)

This deep access to the underlying source code makes old-school Prolog absolutely wonderful for someone writing a domain specific language or knowledge representation system, where everything in the source file or knowledge base should be exposed, guts and all.

It’s less wonderful for someone who’s used to the modern functional or object-oriented programming doctrine that nothing should know anything about anything that it doesn’t need to know, that source should irreversibly compile down to an opaque system object, and that decompiling or reverse engineering is morally suspect and a security breach.

I’d love to somehow square the circle between these two very different ideals, which is quite possibly impossible. But they both feel like important required features of a sensible, secure, user-driven operating system: 1. The user should get full access to the system at all levels. 2. Nothing should break unless you intend and have the rights to break it.