The Further Democratization of QUANTUM

From my book Data and Goliath:

...when I was working with the Guardian on the Snowden documents, the one top-secret program the NSA desperately did not want us to expose was QUANTUM. This is the NSA's program for what is called packet injection­ -- basically, a technology that allows the agency to hack into computers. Turns out, though, that the NSA was not alone in its use of this technology. The Chinese government uses packet injection to attack computers. The cyberweapons manufacturer Hacking Team sells packet injection technology to any government willing to pay for it. Criminals use it. And there are hacker tools that give the capability to individuals as well. All of these existed before I wrote about QUANTUM. By using its knowledge to attack others rather than to build up the Internet's defenses, the NSA has worked to ensure that anyone can use packet injection to hack into computers.

And that's true. China's Great Cannon uses QUANTUM. The ability to inject packets into the backbone is a powerful attack technology, and one that is increasingly being used by different attackers.

I continued:

Even when technologies are developed inside the NSA, they don't remain exclusive for long. Today's top-secret programs become tomorrow's PhD theses and the next day's hacker tools.

I could have continued with "and the next day's homework assignment," because Michalis Polychronakis at Stony Book University has just assigned building a rudimentary QUANTUM tool as a homework assignment. It's basically sniff, regexp match, swap sip/sport/dip/dport/syn/ack, set ack and push flags, and add the payload to create the malicious reply. Shouldn't take more than a few hours to get it working. Of course, it would take a lot more to make it as sophisticated and robust as what the NSA and China have at their disposal, but the moral is that the tool is now in the hands of anyone who wants it. We need to make the Internet secure against this kind of attack instead of pretending that only the "good guys" can use it effectively.

End-to-end encryption is the solution. Nicholas Weaver wrote:

The only self defense from all of the above is universal encryption. Universal encryption is difficult and expensive, but unfortunately necessary.

Encryption doesn't just keep our traffic safe from eavesdroppers, it protects us from attack. DNSSEC validation protects DNS from tampering, while SSL armors both email and web traffic.

There are many engineering and logistic difficulties involved in encrypting all traffic on the internet, but its one we must overcome if we are to defend ourselves from the entities that have weaponized the backbone.


And this is true in general. We have one network in the world today. Either we build our communications infrastructure for surveillance, or we build it for security. Either everyone gets to spy, or no one gets to spy. That's our choice, with the Internet, with cell phone networks, with everything.

Posted on April 24, 2015 at 8:55 AM • 46 Comments


miceApril 24, 2015 9:30 AM

Does Quantum work with blind injection or just Mitm, wondering if they use a mix of waterhole, syn,ack guessing based on,cpu speed(windows server is incremented by tick count, then wrapped around to zero), times port probailty etc could pretty much anything that does use tcp could be attacked remotley.

Would adding code in higher levels of the network stack say http inbed code that cant be guessed, and can be started from the client side, say send a header part that the server just ingones but keeps repeating in sequncel packets.

Sent from a phone(spelling)

Rufo Guerreschi April 24, 2015 9:43 AM

"end-2-end encryption" is a very bad term to use when telling people and IT security experts what we need to do. It overwhelmingly is used to describe services that igbore end-point vulnerabilities beyond point of encryption.

Spaceman SpiffApril 24, 2015 9:51 AM

I have to agree with Rufo about end-point vulnerabilities. Phishing attacks. Malware infected web sites. Bogus certs. And the list goes on. As the Buddha curse says, "May you live in interesting times!"...

Andrew WallaceApril 24, 2015 10:14 AM

"The one top-secret program the NSA desperately did not want us to expose was QUANTUM."

Maybe that is just what the NSA wanted a naive journalist to think to ensure that the journalist would publish the material.


David Churcher, GCHQ Youth Outreach BranchApril 24, 2015 10:20 AM

While we're waiting for encryption, it's getting easier for wronged states and organizations to cost out countermeasures to NSA sabotage

and assign state responsibility for restitution and compensation.

Satisfaction is still not quantifiable but it would have to include prosecution for serious crimes such as 'targeting' indiscriminate killing of noncombatants.

EricApril 24, 2015 10:26 AM

It's basically sniff, regexp match, swap sip/sport/dip/dport/syn/ack,
set ack and push flags, and add the payload to create the malicious reply

I did this for an opt-in, white-hat application to run in the user's home router. You will also need to deal with the sequence numbers of course. And, quite often, you'll need to set the timestamp options since some target stacks have heuristics around that. But yeah, it's not that hard.

Shouldn't take more than a few hours

Well. It took me a couple weeks to get the program to beta-quality. But then again, I don't have entire websites dedicated to my superpowers like Bruce does. :)

End-to-end encryption is the solution.

And unfortunately also breaks my (again: opt-in, white-hat) application, which is a transparent, predictive in-home HTTP cache for streaming entertainment. I can work around it when the viewer is a PC browser (since I can have the user install new certs to their OS). But when they are using other devices like their iPhone or Smart TV or whatever, I'm pretty out of luck. And my users will be sad.

It raises a big question about what will happen in general to transparent HTTP caches when the whole universe goes to SSL. Bruce, have you thought about that at all?

JarthApril 24, 2015 10:49 AM

Encryption ? What about ipsec-like encapsulation based on some dynamic scheme ? Provides identity, integrity and will not freak out as many people and not create a false sense of security. Also, it will permit mixed pages encrypting what is privacy sensitive.

rgaffApril 24, 2015 10:53 AM

@ Andrew Wallace "naive journalist"? Is that the best argument you can come up with to find some way to disagree here?? LOL

gordoApril 24, 2015 10:54 AM

On the Fox-IT Blog from a couple of days ago, some nice background and how-to, including detection:

Deep dive into QUANTUM INSERT
Posted on April 20, 2015 by lennarthaagsma

Summary and recommendations

QUANTUMINSERT (QI) is actually a relatively old technique. In order to exploit it, you will need a monitoring capabilities to leak information of observed TCP sessions and a host that can send spoofed packets. Your spoofed packet also needs to arrive faster than the original packet to be able to be successful.

Any nation state could perform QUANTUM attacks as long as the traffic passes through their country or possesses other capabilities to get the required TCP session data.

QUANTUMINSERT could be used for lateral movement within internal networks.

Detection is possible by looking for duplicate TCP packets but with different payload and other anomalies in TCP streams.

The usage of HTTPS in combination with HSTS can reduce the effectiveness of QI. Also using a content delivery network (CDN) that offers low latency can make it very difficult for the QI packet to win the race with the real server.

Deep dive into QUANTUM INSERT


Our focus for this article will be on performing and detecting one specific attack in the QUANTUMTHEORY[2] toolset called QUANTUMINSERT (QI). While this weakness in TCP has been known about for a long time, the NSA has allegedly deployed this attack successfully against targets..We will explain the attack, how it can be performed, and how you can detect it using Intrusion Detection Systems like Bro, Snort and Suricata. The code we used to test this attack is available on our GitHub page.

keinerApril 24, 2015 10:54 AM

Again: The use of the word "democratic", just because something is becoming common is absolute and utter nonsense.

Is tax fraud "democratic" just because everybody does it?

Kyle RoseApril 24, 2015 11:02 AM

"It raises a big question about what will happen in general to transparent HTTP caches when the whole universe goes to SSL."

Homercles cares not for beans.

Transparent HTTP caches have been a thorn in the sides of web developers for two decades now. Good riddance.

I appreciate the problem you are trying to solve is one where non-cooperative caching is actually legitimate and useful and requested by users, but the more common and far more problematic case has been transparent caches not requested by users but instead put in place by cheap ISPs that don't want to pay for bigger pipes to handle traffic the way users and content providers intend. Banishing those to the dustbin of history is a feature, not a bug.

I'm genuinely curious: what is the use case for your application? I.e., a bunch of people behind a slow pipe all watching the same movie on Netflix or something?

Ray DillingerApril 24, 2015 11:50 AM

I've been assuming that pretty much every government in the world does this. I mean, seriously. They're governments. They can't possibly *NOT* do this.

But I really wish you'd stop using the word "Democratization" when you mean "Proliferation." This has absolutely nothing to do with responsible citizens choosing the future course of their government. And saying so is sort of an insult to the institution of Democracy.

In fact every government does this - Democratic, Communist, Socialist, Autocracy -- you name it. Not just Democracies. And besides governments, every criminal and commercial institution that thinks it can get away with it. NONE of which are democratic.

gordoApril 24, 2015 12:09 PM

@ Ray Dillinger

I've been assuming that pretty much every government in the world does this.

Yes. Some have even established training programs:

National Centers of Academic Excellence in Information Assurance (IA)/Cyber Defense (CD)

The initial National CAE in IA Education (CAE/IAE) program was started by NSA in 1998, with DHS joining as a partner in 2004 in response to the President’s National Strategy to Secure Cyberspace.

But, to your point: There's a definite irony in Mr. Schneier's use of the word.

EricApril 24, 2015 12:14 PM


what is the use case for your application?

Some users have trouble using streaming entertainment because either (a) their pipe is too slow (think wireless ISP customers living perhaps in rural areas, or oversubscribed DSL folks) or (b) their monthly data caps are too low (think satellite ISP subscribers with a 10GB monthly cap) but they have late-night free zones.

In either case, imagine predicting what they're going to watch tomorrow, downloading it in the middle of tonight to an in-home cache, and then serving the bytes out of the cache when they go to watch it. Some people who could never use streaming entertainment before are able to because of my app. Others simply see a nice bump in quality (e.g. from low-def to HD) or a cost savings (because their ISP lets them download stuff in the middle of the night for a lower price per byte, for example).

a bunch of people behind a slow pipe all watching the same movie on Netflix or something?

My app predicts viewing on a per-subscriber basis. That is, when you install my app, I predict what you specifically are going to watch -- I don't do any kind of aggregate prediction across subscribers.

The app is also a great way for ISPs with overburdened access or transit networks to make their networks more efficient. The daily consumption curve today is very peaky -- lots of usage from 7pm to 10pm, and mostly idle in the wee hours. And a huge percentage of the peak is streaming media -- think 30% to 60%, depending on whom you ask. The consumption curve is also getting "peakier" over time. This means networks generally are getting less efficient over time, since the ISP generally has to build to the peak demand, not to the average.

My app offsets the byte delivery to off-peak times, meaning the ISP's other peak-time subscribers (even those without my app installed) see a benefit.

Today, all of this depends on me being able to see what the subscriber is watching. That's how I do all the prediction stuff as well as the redirect to the cache. If I can't get in the middle then I can't do it.

put in place by cheap ISPs that don't want to pay for bigger pipes

I know people like to dump on ISPs, sort of seeing them as uniformly big evil behemoths. The reality is that the universe of ISPs is a lot more varied than the broad picture you paint here. A lot of my customers are small wireless ISPs (WISPs) with only a couple hundred subscribers in primarily rural areas, who are just working their asses off to get decent service to their customers.

One customer of mine told me over a beer about having to decide between paying for groceries one night a few years ago and filling up his truck's gas so he could go out and do a couple new subscriber installs. He went and did the installs.

He doesn't want to install a transparent cache because he's a mustache-twirling evil billionaire who wants to upgrade his yacht and go drive it over baby dolphins. He wants to install it because it makes him a bit more efficient and he thinks it'll make his subs happier. He would like to add access network capacity, but sometimes the capital to do so is 6 or 12 months away from materializing. And sometimes, adding more networking equipment outside the home simply doesn't help -- e.g. he is beaming them a 900MHz radio wave to poke through a tree cover, so the bandwidth can't get high enough to deliver HD streaming video.

And this guy is not an atypical WISP CEO. This is a commonplace example.

So I would say don't blame the technology as a whole for specific people's specific evil uses of it. Blame those specific people's specific evil uses of it. Also, don't conflate incompetence with evil. Obviously, most transparent caches are trying to actually be transparent, and when they fail they fail by accident. That may be a thorn in the side of web devs, but the answer may not be to punt the whole idea, it may just be to make better transparent caches.

Obviously I'm biased here since, you know, I sell a transparent cache for a living :). But that doesn't mean I'm wrong.

Nick PApril 24, 2015 12:21 PM

@ Bruce

I agree with Ray that proliferation of weapons is much more accurate than democratization. An example of democratization was hacktivism via DDOS: attacks that got stronger based on how many individuals participated. Tools like QUANTUM developed by malicious individuals or states, often in secret, are the opposite of democratic. They're just weapons exploiting infrastructure that's intentionally left insecure by both the government and the market. Highly damaging weapons that even college students can build and that our enemies are already using. The conclusion, protecting our infrastructure, becomes even stronger in this light.

gordoApril 24, 2015 1:09 PM

@ David Churcher, GCHQ Youth Outreach Branch

My apologies for missing your link to the Fox-IT blog prior to my posting of same!

RE: "While we're waiting for encryption...cost[ing] out countermeasures"

IETF Begins To Work On Designing A Surveillance-Resistant Net
from the but-that's-the-easy-bit dept

Axl Pavlik, the managing director of Europe's Internet Registry (RIPE NCC), notes that you can never stop surveillance completely, but you can make it more expensive....

tyco bassApril 24, 2015 2:19 PM

"Democratization" is not "democracy." One of the meanings of "democratize" is "make accessible to everyone." (Demos = the populace.)

Kyle RoseApril 24, 2015 2:40 PM

@Erik: good response. I appreciate the detail.

That's a tough situation. I sympathize with users and ISPs in that situation. That said, your solution still seems like a limited-application hack intended to buy time rather than a real solution to the problem of having too little capacity relative to demand.

But given the realities of the situation, it seems like content providers would have an incentive to help solve this problem because every user that has to cancel because of lousy quality means less income for them. I wonder if the Netflixes, Googles, and Akamais of the world have thought about co-locating cheap but intelligent caching/pre-fetching servers in small ISP data centers?

I know that doesn't help your business specifically. But I imagine having the prediction model built by the content providers or CDNs themselves, and incorporating prediction across subscribers and maybe even predicting locally based on global viewing data filtered down to matching demographics, would probably be optimal within the bounds of what's possible with the small pipe problem.

Your business specifically is okay in a world of H/2 opportunistic security in which you can act as a MITM, but in a world of authenticated TLS everywhere your only solution is to cooperate with content providers. The whole point of authenticated TLS is to defeat exactly the sort of inspection and injection your service is providing: unfortunately, the RFC for "scoring based on evil intent" hasn't been completed yet, so the protocols have to be safe and block everything. ;-)

David Churcher, GCHQ Hands-on Internship ProgramApril 24, 2015 5:51 PM

@gordo, that article is a great source for lots of points.

Re: make surveillance more expensive

And meanwhile NSA is making communications more expensive. Even the interim countermeasures in the link run into money at scale. Lex specialis and state responsibility principles allow NSA's victims to recoup the costs from the US government. The prior pattern is, a country takes the US to court or arbitration; the US settles up to abort the case and avert a direct precedent and, Ka-CHING! $$$! It won't be a satellite state like Germany or Belgium, though. Some G-77 states will probably go first.

Nicholas WeaverApril 24, 2015 11:16 PM

Apologies for the typo. When I sent an email describing how to build this to Bruce, I said swap syn/ack, I meant to say seq/ack, and then add packet length to ack (although the latter isn't necessary in many cases, TCP stacks can be remarkably tolerant, they will just think the data was sent by the other side before it received the message).

That is the problem with describing how to code in email: there is no compiler and
regression tests to catch typos.

Also, whats remarkable about the Great Cannon and why it interested us is it is more than QUANTUM (the Chinese equivalent to QUANTUM is the great firewall).

QUANTUM can only add packets, but the cannon is a full Man-in-the-Middle, able to remove packets as well. This is a remarkably important addition, as it allows very nasty things like man-in-the-middle'ing email (and stripping STARTTLS).

Finally, NSA's QUANTUM is actually not that much more sophisticated than the schoolboy version. The big limit of the schoolboy version is it doesn't reassemble TCP flows, so if the trigger is split across multiple packets, the injector won't trigger. [1]. The NSA's version has the same limitation!

[1] Robust TCP stream reassembly is hard. IDSs do it, but its in many ways the most important part of an IDS: reassembling the traffic as the client would.

DuckyApril 24, 2015 11:48 PM

I'm surprised governments haven't mandated a front-door / back-door into HTTPS yet. That way the NSA and China can continue to carry out their QUANTUM attacks on encrypted traffic.

The justification for the HTTPS front-door / back-door will be hunting down terrorists and for the safety and security of the citizenry, of course.

miceApril 25, 2015 1:11 AM

Would like to say about some blind tcp hijacking experments on a local lan.
I had three box, a target winxp, a linux os(slackware), and a windows 2k7

I mangered to inject one packet into the stream, by send a ack and guessing the seqnum by increment a randomish value picked from packets sent to the server and basic statical anlzed it to prodect the current number based on guessing the ghz and time of packet travel withen the program, the value got incremented to one quator 16bit number, I did the same thing with acknum, I was getting 8,10 hits by cheating and sniffing the sport number of the target, otherwise I contiune loss the race.

The second stage was to remove the weakness of sport, so I targeted the dns authority server to the win2k7 box, by asking for a none cached address, in real life, if I lost the race, would just needto wait ten minutes and then try again, the authroither servers were selected buy picking four, as the lan gave that much speed advgudge to have four, it would be easyer targeting a smaller address down the tree, as the win server if it didnt have a record for a adress but got asked for one and then injected with attacker address a spoofed email, to local resources would pink twice and rediect to the attacker.

All in all a better stactical anlyze of seqnum generation would open the door up.

THE defensive messure, if you are going for speed and just using the tick count of the cpu, add three lines of asmble and hardcode a offset that gets add if the lowest sig bit it one, with a random value loaded to code on windows install, would add 16bit extra work, but only 20-200 millionth of a second delay.

ScatterbrainApril 25, 2015 2:54 AM

There are already tools. Bro does TCP reset injection. Cyberprobe does TCP payload injection.

miceApril 25, 2015 4:03 AM

Scatterbrain, back then there was nemisis and latter tcprelay, so not to many options for injection, the Ids part is abit strange TIME, one packet to exploit and one to check if successful, after two years if the autopwn as not said successful move on.

Just some ramblings, not in the game anymore.

Nicholas WeaverApril 25, 2015 8:27 AM

Bro's rst tool actually allows payload injection. I build a full suite, including a web interface for searching, some of the NSA's for-Marina metadata extraction, full take, and packet injection using Bro as the sensor.

keinerApril 25, 2015 11:19 AM


: to make (something) available to all people :

Democracy is about participation.

Not about consuming (plastic bullshit or whatever). Using the term "democracy" to describe consumerism is a typical neolib perversion of the term, to distract from participation in politics and society and make people think they have "democracy" if they all can buy the same Apple trash and other stuff.

philApril 25, 2015 3:44 PM

If quantum-insert is trying to inject packages by being faster than the original package, wont the original also still arrive? Can't intrusion systems then be made that wait a bit for the other to arrive, compare contents, sound alarm when two packages differ?

gordoApril 25, 2015 4:00 PM

@ keiner

Not everyone votes in any democracy, therefore, said states are not democracies?

If voting is compulsory, is that democratic?

Here's one sense of meaning maybe closer to the phenomenon being considered:


The term democratization refers to the broadening accessibility of online
surveillance through a plurality of tools and services that could previously
only be afforded by governments and large companies. This trend reverberates
both in the private and public spheres, and corresponds to a wide range of
rationalities sustained by business-oriented ventures, non-governmental
organizations (NGOs), and social units such as families and groups of friends.
Low barriers of entry to the world of online surveillance are responsible for
this democratization. Contrary to other mass media such as television or
newspapers, the marginal costs for the distribution of information on the
Internet are very low, because expensive proprietary infrastructure such as
satellites, fibre-optic cables, printing presses, and delivery routes are not
required (Benkler, 2006). All providers of Internet services share the same
infrastructure and the same data transfer protocols, also known as TCP/IP
(Lessig, 2006, pp. 143–146). Therefore, large investments in capital assets are
not required to start disseminating information, as millions of bloggers have
found out. (p. 265)


Hacking the panopticon: Distributed online surveillance and resistance
Benoît Dupont
Surveillance and Governance: Crime Control and Beyond. 2008, 257-278

HeyApril 26, 2015 11:23 AM


It sounds like what you described is some sort of social analysis tool. It scrutinizes people's viewing behaviors in order to predict fetch when they opt-in to your app. As you've said, this can apply to all sorts of social behaviors, search engine results being one. Neat trick.

But as the old saying goes, prediction is the mother of all farkups. B-)

philApril 26, 2015 1:40 PM

@matt: maybe not (easily) for a MOTS attack but packet injection using a MITM attack (like used with China's Great Cannon GitHub attack), it should be possible to block the original package from ever arriving, no? I read on the FoxIT website that duplicate sequence numbers are used to detect if content differs. They talk about TTL and other IP header anomalies as detection method (but those don't sound very robust as a detection method to me). That CheckQuantumInsert of stream_quantuminsert-snort- looks to me like only checking the sequence number duplication. Maybe I missed the code for checking TTL an others anomalies?

DaveKApril 29, 2015 7:37 AM

@Bruce, have you heard the ludicrous suggestion being bandied about by the WSJ that Snowden may in some way have 'given' QUANTUM to the Chinese, as now manifest in the Great Cannon?

[Commentary at based on the original at which I haven't read directly because of registration wall.]

Perhaps you'd like to write a rebuttal of the inane suggestion that the Chinese somehow wouldn't have been able to implement attacks that have been well understood since dsniff and ettercap released around the turn of the century without outside help?

KayHApril 29, 2015 6:14 PM

Sadly encryption alone will not achieve the security that is wanted on the Internet. Much of internet activity involves a user interacting with websites, people and organisations that the user knows nothing about and has no reason to trust. If the communicator in question is hostile, as will sometimes be the case, end to end encryption simply provides a private tunnel for executing attacks.

Nick PApril 29, 2015 8:12 PM

@ all
re "democratize"

Oh yeah, I forgot about that other definition. I rarely use the word lol. Thanks to above posters for that and the links. The usage makes more sense now. So, they're democratizing surveillance the same way that meth's manufacturing, distribution, and use was democratized, right? Anything spreading and cheap is democratized. Seems to cheapen the word a bit but at least it makes more sense now.

Only concern now is effectiveness. Metaphors are supposed to make things easier to understand. One word metaphors more so. This one took discussion and research papers to justify. Doesn't that imply something about its effectiveness on the general population? Or am I worrying over a non-issue here? "Cheap, mass availability of surveillance" would be my alternative for layperson effect. More words, but clear meaning. Any other suggestions?

Clive RobinsonApril 29, 2015 8:38 PM

@ Nick P,

Sometimes words realy don't mean what people think they mean, or the word does a 180 in "common parlance".

Two words to think about "manufacture", "terroristic"...

Manufacture actually means "to make by hand" (the root of manual and manufacture are the same).

Terroristic behaviour and terrorist in general originally applied to kings and tyrants who used it to keep the "subjects" subjugated. Not to groups of subjects trying to achive political ambitions through fear and violance against an established sovereign governance.

Oh and that little word "trusted" means one thing to most people but almost entirely the opposite to ICTsec systems and practitioners.

Clive RobinsonApril 29, 2015 9:30 PM

@ KayH,

Sadly encryption alone will not achieve the security that is wanted on the Internet

No, that's because encryption is to security, what bricks are to houses, just a small part of the overall system.

With regards "trusting unknowns" it's a human failing that we do with other humans, and sometimes people get hurt / conned. That translates fairly well to the Internet or other wide area network where there is not single controling entity that is trustable in human terms.

Many many years ago Bruce made a comment about crypto being the easy part and key managment being harder. Well it's a bit of an understatment in that part of key managment involves "trust mechanisms" and we appear to be no further ahead on this than we were a hundred years ago during the First World War.

The issue is also one that precedes that by several centuries in both business and statecraft, and the very imperfect solution of then is what we still have today which is "reputation" or lack thereof.

The traditional human way was to either build up a trust relationship a little bit at a time, or through the recomendation of either intermediaries we trust already or by some entity with standing in the community such as a guild.

This sort of works in the physical world when freedom of movment is very limited and those we trust have faces that can not be changed and thus can be recognised and any harms they might commit become recognised by others who can apply corrective actions on the breach of trust.

In the non physical world of information where local has no meaning and the image presented is effectivly infinitely variable, such traditional methods fail.

Finding replacments is an ongoing process that appears glacial in progress, and is far from solved either in theory or practice. The first atsempt at this via a hierarchical authority has with CA's been shown to be a failure for various reasons.

Importantly the reasons for the failures is not the PubKey crypto its self but the way it's used and human failings.

Currently many new ideas that are not based on hierarchical organisations are based on the likes of asymetric crypto for identity proof and shared key protocols to cover multiple entities.

That said none of them actually solve the problem of initial trust, or stoping a trusted party wilfully breaking trust in the future.

KayHApril 30, 2015 2:23 AM

That is all true, but only partly addresses the problem. As in the real world, we sometimes want to communicate with people we don't trust so we have to be guarded in the way we interact. Crypto (including key management) does nothing to provide that guardedness of interaction in the cyber world that is needed to defend against attacks from people we cannot identify or don't fully trust.

That is an even harder problem because it depends on many things, including the platform(s) you work on, any devices you use to protect it from attack, and the organisations that build and maintain this 'trusted' system, the apps you have installed, the mechanisms you use to filter the data you receive to remove or discard (possible) attacks on those applications... I could go on.

This is the really hard problem because what constitutes an attack in some data depends on the applications and services that process it - and these are highly complex and constantly changing. By strictly limiting the apps and services that process data from people you don't trust, you can make the problem more manageable, but crypto plays at most a peripheral role in resolving this.

Oh, and by the way, it's the sender of the data that decides what apps are needed to process it - if you want the experience the sender is offering, you open yourself up to attacks!

Er - just like the real world...

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient, an IBM Company.