For a more compelling argument regarding LN, which takes on the linked post, see

http://www.coppolacomment.com/2018/01/probability-for-geeks.html

I can’t imagine how frustrating the past week must have been for you to watch, thanks for sharing all of these.

I’m confused: is the purpose of this thread to stroke your own ego and claim you are smarter than Tom Ptacek and Colin Percival?

…ignoring prior work to only rediscover what was in it the hard way after it does a lot of damage. They usually follow by patting themselves on the back for their “discoveries.

By saying things like this you are downplaying one of the most impressively sophisticated attacks in the history of information security.

“I’m confused: is the purpose of this thread to stroke your own ego and claim you are smarter than Tom Ptacek and Colin Percival?”

You’d be better off asking if the purpose of Thomas’s dismissals of work that spotted and mitigated problems a decade or two ahead of him was about ego or some value to society in ignoring such work. He consistently dismisses any work I bring up in high-assurance security, about the TCSEC that produced highly-secure systems, and so on. Newcomers reading comments of highly-regarded people in security saying that TCSEC or A1-class techniques were useless or “just red tape” would (do) think those security professionals assessed that prior work, saw nothing secure came of it, and are now recommending against it. The truth is those “experts” have usually not read on that prior work, are misrepresenting it (i.e. slandering good researchers), and/or their dismissals or misrepresentations contribute to prior problems re-appearing down the road with all the damaging that brings.

Those same people are often hypocritically saying, like Thomas in recent thread on email encryption, their security advice is about prioritizing avoiding damage to innocent parties. Yet, they’re willing to cause it by suppressing known-good techniques for… ego or social standing? That does piss me off when it happens in any field, esp INFOSEC. I do call it out. Instead of pure flamewars, I try to do so with clear arguments citing hard evidence what I say is true like landmark works talking about cache channels in 1990’s. Interesting enough, knocking out his and other people’s bullshit that way got me my early karma on Hacker News. People kept thanking me in email saying they’d do it but downvote mobs hit them after every dissenting comment. Happened to me, too, sometimes in seconds but usually reversed later in the day. So, I stayed on it (still do) for various myths or fads on these forums needing peer review.

Far as Colin, I told him I respected him, considered his an independent rediscovery of the problem, thanked him for his FOSS work, and was clear I was knocking out misinformation (2005 claim) about when we could’ve spotted cache-based issues. Colin probably just didn’t read or see the early work since the community he entered collectively ignores that work. They’re not ignoring it for scientific reasons given the prior work was the strongest INFOSEC ever produced with methods that consistently outperformed ad hoc stuff mainstream, security community pushes. After seeing that evidence, only reason they’d collectively ignore or suppress it without qualifiers is social: politics, dominant egos, tribal signaling… something other than making us secure. I told Colin people like him having access to that information earlier might help them solve problems earlier with even more effective designs than if they don’t have access to good, prior work. It makes good researchers like him even better than they already are.

So, I keep reinforcing the good, calling out the bad, and generally posting every piece of obscure research I can to folks that might benefit from it to facilitate serendipitous discovery across social or knowledge silos. I’m still working on better solutions to that problem but there’s group politics behind most that vary by group. Work in progress…

“But… there is simply no comparison. This attack is pretty much hands down the most sophisticated attack I’ve ever seen in my life, and I’ve seen people break into TrustZone with a single null byte overflow. The complexity and sophistication of this attack greatly outclasses any previous cache timing sidechannel. Period. End of story.”

I think you’re focusing too much on the developing attacks part of my comment (or these events) than the part about how prior work would help spot attacks and defend against them. The people who I told cpercival about that identified the side channels came up with methods that year to find them in models of software and hardware. There was even tooling for doing it with formal specs, like eg Gypsy Verification Environment, on software side that might have been extended for hardware: software method modeled state transistions; hardware developers often used state models, too. The researchers were saying in 1992 that about every component leaked in those systems with a need to develop leak-resistant versions of them (aka MLS-capable versions in their jargon). They said this was necessary so their VMM project running untrusted workloads side-by-side with secret ones wouldn’t allow secrets to leak to malicious apps using any of those components. Any of that sound familiar?

So, while high-security and CompSci celebrated those works, mainstream security ignored all that. Many even mocked how “impractical” they were for daring find and fix root causes if there was a performance hit or you’d have to buy a non-Intel chip. Then, they rediscovered timing channels in caches talking big like you are now about how smart the attacks or discoveries were that nobody or few had thought about. All the security forums were talking about it. Most still ignored prior work and tech we were posting on same problems to mitigate it at every level in hardware. Mainstream folks were making mitigations that are very tactically-focused on each individual instance of leaks instead of root causes at whole-system level. As they did that, some in CompSci started building on that prior work for hardware and software mixes.

Since mainstream researches piecemeal instead of whole-system, more of the same stuff is found in other components that a basic, covert-channel analysis would’ve found quickly. They still refuse to learn from or use those techniques as seen by fact that most people following DEFCON, etc often have never heard of them. People pushing old methods are pariahs of sorts. And now, another big problem is found that an info-flow analysis on a hardware model might have found (esp model-checking) or prevented by default simply from B3/A1/EAL6/7 designs avoiding constructions they can’t exhaustively analyze (eg AAMP7G versus ARM micros). That last part was and still is a rule in high-assurance development that keeps paying off where we assume it will screw up until we can rigorously show it can’t in all situations with good a model as we can use. Security professionals often argued with me about that, too, with many justifications for not analyzing or containing stuff with high-assurance methods.

In summary, you’re amazed by the fact that people avoiding proven techniques for analyzing hardware interactions for information-flow leaks later discovered in performance-focused, info-sharing-oriented CPU’s that…

1. A shared component known to be a source of leaks without leak mitigation…

2. One or more other components with little to no leak analysis that also have no mitigations…

3. Somehow interact to create a leak someone didn’t see coming. Mitigations might even be costly since 1 and 2 weren’t designed to do this from beginning against recommendations from the 1980’s for high-assurance design of any kind. “Can’t retrofit strong security” we say.

Simplified like I did with Ted’s example, a known-insecure component mixing with maybe-insecure components had insecure result against user expectations it would be secure. You see why I’m not surprised even if I don’t deny the attack itself is clever? I mean, who saw problems like that coming past half a dozen people publishing in 1990-1995 saying that we need covert-channel mitigations in the CPU, memory, I/O, kernels, networking, filesystems, and multi-user apps!? Mainstream security’s focus on highlighting clever attacks instead of root-cause defense is much like those who insist on using C instead of memory-safe, system languages in apps that didn’t need it marveling at a dozen, clever ways their systems are broken by people manipulating known-bad components into new constructions that break security. We might have not anticipated the specifics of the attacks but they leverages known-unsafe primitives instead of known good (or worth trying) techniques. Developers ignored those for “performance,” “popularity,” “we hate FFI’s,” etc. Leaks in hardware/software are like C exploits with most builders telling us it’s not worth their time to look for or prevent them for decades. Then, they make exceptions for each individual attack that becomes massively popular or damaging like recent ones. Then, they fix that attack, earn creds on blog posts or conferences, and go back to whatever they were doing ignoring root causes or whole systems. In rare, rare instances we do see something like Rust get popular addressing big, root causes. Most not addressed, though.

And I bet most of them are still not pulling prior work on spotting all leakage in hardware even now that I brought it up. They sure are talking a ton about how clever the new attack is, though, with them taking turns showing how much better each of them understand the recent reports, what they might do about just that attack ignoring analyses of whole chip, how many systems will fall, how much money will be lost, and so on. There’s you more comments motivated by ego rather than security since most aren’t contributing info to stop the next leaks.

Those of us in high-assurance security are motivated to make secure, correct-by-construction systems with ego coming in when we do it right, esp avoiding problems. It’s so hard to prove a negative against smart attackers (even temporarily) it’s worth being proud of. That’s it. We’re obviously not trying to win popularity contests if we were droning on about covert channels since the 1980’s and CPU channels since 1990’s to a crowd whose majority dismissed us every year for it, made exceptions for some on occasion (eg 2005), and then continued dismissing. If I wanted popularity or ego, ‘d be talking… whatever’s popular in DEFCON, Black Hat, or (for money) cryptocurrencies.

There is a minority that does listen. Even on recent posts, the votes indicate a lot of appreciation for sharing the prior work. I also put together the link above with some of the recent work on finding leaks in hardware. I also tell people regularly about simple, FOSS processors they can build and analyze themselves if Intel/AMD won’t make something to their standards. I enjoy providing people what they need to solve problems, once and for all wherever I can. It helps some of them avoid harm. I’m definitely proud and happy with doing that. I plan to do it better this year, though, since my prior style definitely needs improvement. Focus will be high-security marketing.

I think people take it a bit too far, but the various threats include:

1. Do a crypto op. Do an insecure op. An exploit finds the key leftover from previous crypto op.

2. A variation of sorts of the above, the memory gets reused, leaks, oops.

3. There’s some flavor of kernel bug that leaks memory, and you’d like to narrow the window of vulnerability.

4. Suspend, hibernate, cold boot, etc.

I think the threat model is basically adversary gets a snapshot of memory at some point, so you’d like it to be uninteresting.

It is, indeed, a lot of complexity for a threat model which most don’t need to worry about: naive RAM scrapers which they’d like to trip with the guard pages. A sophisticated attacker with remote code execution can easily sidestep such a defense, because the secrets are still sitting unencrypted in RAM.

A better approach would be to actually encrypt the sensitive information. This is particularly useful for cryptographic keys, because we can e.g. use a key-encrypting-key sitting in XMM registers to decrypt an encrypted data-encrypting-key (DEK) into other xmm registers. That is to say, we can keep an encrypted copy of the DEK in memory, decrypt it into xmm registers when we want to use it, perform cryptographic operations with it, and then we never have to worry about the unencrypted version sitting around in memory in the first place.

Or, if you’re really worried, use something like Intel SGX, or perform encryption using a separate physical device like a TPM, HSM, or Yubikey

Yeah, I haven’t heard anything new since we published this. Also linked in that article is the 2016 Black hat talk which (at least for me) was a really good SEP primer:

https://youtu.be/7UNeUT_sRos

Yeah, I mean, this is somebody who trains journalists in secure comms? So what does that training consist of now? “I recommend you not be a journalist.”?

I don’t understand this comment. You say that the post contains three valid complaints, but he shouldn’t complain, because it’s still better than some other tool. With WhatsApp using Signal’s encryption now, I can’t see much difference between the too: You are still in a walled garden, with your metadata going through google. I don’t get why you ridicule these concerns.

I second the matrix recommendation, though. It’s everything Signal promised to be.

It’s needed to cleanly disambiguate binary data from unicode strings in a content-aware hash setting, provided you want the same digests to be computed for (T)JSON data and e.g. protos. This is particularly important if your document contains fields like cryptographic hashes or public keys. Otherwise, to verify the protos you’d have to round trip all the binary fields to Base64(url) to compute their hashes.

The goal of TJSON is to be a self-describing, schema-free format.

Why would Javascript need to run outside the browser?

Indeed. I can think of a couple problems solved, but I can also think of a few alternative solutions.

Would you mind going into the difference between jails, zones, and chroot or whatever under Linux?

I was at a meetup last night talking about Docker, and I’m not really that convinced.

IME chacha20+poly1305 is the fastest of the default 6.8 ciphers on non-AES (i.e old, or embedded) hardware. Of course, choosing a different cipher on the command line is trivial, and adding more to the server config for internal use (arcfour128) is also pretty easy.

It doesn’t really argue explicitly for the combination, but one of their papers, “Deny capabilities for safe, fast actors” uses objects as the unit onto which a capability model is attached, in order to allow mutability while maintaining safety from data races.

The documentation drops off a cliff at some point

Specifically, the tutorial is blank after the subsection Expressions – Sugar. The sections of the tutorial with content are Getting started, Types, Capabilities, and most of Expressions. The most important missing sections are Actors, Garbage collection and C-FFI.

Dunno the justification for objects; but how do you lockless cooperative multiprocessing that scales seamlessly to many, many cores without actors?

This is the first time I’ve heard of it, but it seems really interesting. I’ve only just read the readme, mind. I have a couple years experience with Akka actors (for Scala / Java) and it had been great. Finding actor code a lot easier to reason about (and test!) than lock based code.

There’s no pain once you understand that you should use channels instead of access to shared data. Like they put it in their docs, “don’t communicate by sharing memory; share memory by communicating”: https://golang.org/doc/codewalk/sharemem/