The more I consider the ramifications of these news reports, the more I realize we need full decentralization and total encryption.
We have the tech: Strong encryption, Tor-like relays, and the blockchain. What we need is a way to make services based on these technologies not just as easy to use but easier to use for the average Jane.
If the internet as we know it is to survive, we have to crack this nut.
That's necessary, but not sufficient. We need both sane policies and technical measures to ensure that nothing less than those policies is possible. If we only have the technology, policy-makers can and will make life difficult both for the users and makers of these technologies; more draconian regimes will simply never allow those technologies to take root to begin with.
I think this needs to be expressed more often. Not only will draconian regimes now allow it, but it's also harder to protect such systems at the ends. I saw a presentation by cperciva at some point that talked about the "Three B's": Bribery, Burglary and Blackmail. So tech should be one of many tools to combat oppressive societal structure - some other ones being more social and legal tools.
The concept of the "three Bs" has been around for longer than I have. In my talk ("everything you need to know about cryptography in one hour") I added a fourth B, "guantanamo Bay", aka. torture.
Force them to intimidate and torture at least one side of every communication they want, instead of letting them intimidate and torture three or four centralized service operators to get everybody's communication.
> The Regulation of Investigatory Powers Act 2000 (RIPA), Part III, activated by ministerial order in October 2007,[20] requires persons to supply decrypted information and/or keys to government representatives with a court order. Failure to disclose carries a maximum penalty of two years in jail. The provision was first used against animal rights activists in November 2007,[21] and at least three people have been prosecuted and convicted for refusing to surrender their encryption keys,[22] one of whom was sentenced to 13 months' imprisonment.
And you were doing so well until you said "the blockchain".
(The singular with a "the" means the Bitcoin blockchain, which is increasingly centralised under a decreasing number of Chinese mining pools. And this is apart from the stupendous list of problems with literally every single aspect of Bitcoin. It may not be a great idea to pin any of our hopes on the digital Cue::Cat.)
Glad someone already said what I was going to say about the Blockchain tech. There's no security in that, especially given the feudal nature of the bitcoin market (now and going forward).
Indeed. I forgot to add: And when the NSA is our threat model, an inviolable record of every transaction ever, that lawyers refer to as "prosecution futures", may not be the technology of choice.
No, we live in a capitalist society - what is needed is a way to monetize such services that is as easy as trading in sensitive personal data behind the guise of "free" services.
Or a different social order (my favorite) - but the first problem is probably much easier to solve in a short time-frame.
We don't have the tech for two important, related things: user-friendly, trust management tools as effective as in person; key management for various, complex scenarios. These two have so many issues that even technical people screw up. I've certainly seen a lot of good work on these. Yet, we're not there yet and getting there is worth a ton of effort by anyone who will try.
We get that, then we might integrate it with our existing technologies to implement and use it. Need the foundation first, though.
It looks better than manual GPG but not quite there yet for majority acceptance. Need a lot more work on visual alternatives to this sort of thing. Whatever is mass market will be easy for them to mentally visualize and connect dots. Implies the solution will likely be visual (eg GUI).
Security must, by its very nature, prevent you from doing insecure things. This manifests as an obstacle to users, so they end up choosing the insecure route (writing down passwords etc etc).
Decentralised systems tend to lose to centralised ones because there's no money locus for advertising, development or curation.
It's not totally doomed; the popularity of Snapchat suggests there is demand for services that don't make everything saved and visible forever.
> Security must, by its very nature, prevent you from doing insecure things.
Disagree. In practice security as a guarantee must do so (e.g. the OpenBSD opinion), but security as a gradient need not (e.g. the web opinion).
If Browser X defaults to the TLS version of a page regardless of what the user requested, but gracefully falls back to the unsecured page without action but with a yellow banner across the URL, does this not increase user security without preventing them from doing insecure things?
The objective is not perfect security but rather increased herd security.
If the minimum security threshold (specifically with respect to encryption) is raised, then we all benefit. Decentralized vs centralized and the feasibility of each are an argument for farther down the road (as long as we don't lock ourselves into one or the other). There's much lower-hanging fruit!
This conflates "security" in the sense of requirements and "security" in the sense of technology. Users already have security requirements; security technology ought to be enabling them.
For instance, encryption lets me back up files to cloud services that I don't trust. Without the technology of encryption, my security requirement would have me not backing up files at all. I wouldn't just decide "oh, whatever" and back up unencrypted files.
SSL lets me access my bank safely (enough) from a coffeeshop wifi connection. Without SSL, I'd walk into a physical bank or ATM. I wouldn't decide "probably nobody's trying to hack me" and connect to my bank in cleartext.
Bad technologies manifest as an obstacle to users, yes. But passwords are pretty much the epitome of bad technology in the security field. (It's a legitimately hard problem, so I'm not claiming that people should be doing other things, but we also shouldn't let ourselves think that passwords are good.)
SSL, for all that the implementation sucked and still sucks, enabled the e-commerce revolution of the mid-'90s.
>encryption lets me back up files to cloud services that I don't trust
Any recommendation on an accessible, audited, client for Windows users? Running some company's random binary, especially when you log in and they can identify you, implies a fair amount of trust. Tarsnap's the best one I know of and it's not really accessible for most users.
Not sure what you mean by "accessible", so I'll go from easiest to least easy:
Truecrypt has been audited, works on Windows, and appears to offer an encrypted file container that you can attach to a Windows drive letter.
What you could do is create the container, let DropBox (or whatever) sync the file containing the container, then perform your file operations within the container.
Depending on your needs, there's also GPG4Win, which comes recommended by the GPG project maintainers. AFAIK, GPG hasn't been subject to an extensive audit, but it is venerable, open source, and developed in the open. (Yeah, so was OpenSSL, I know. ;) )
I don't know that there's a way to make a transparently encrypted container with GPG as there is in TrueCrypt, so I suspect that you'd have to:
* Copy your encrypted files
* Decrypt them
* Edit them
* Reencrypt them
* Copy them to the sync directory.
Sounds like a bit of work to me.
If you were on Linux, you could probably use dm-crypt on a loop device, and just sync the underlying encrypted file, but -again-, I have no idea how much auditing has been done on the underlying code (and this fails your "for Windows users" requirement).
Oh, BTW, I replied to our Erlang thread. If you're interested in taking a second look at Erlang, I link to a few things in the comment that might be interesting to you.
Dropbox isn't audited. They have a poor track record for security (lying about internal access then trying to downplay). So even if you encrypt with truecrypt, you're running the Dropbox binary for uploading, and it can do anything - in short, you're trusting them.
I've not found an open source tool that does block level backups with diff/compression support. Getting the client experience right is hard and not a whole lot of fun, so I'm guessing there's little incentive for companies to open source that valuable part.
Edit: I would ask "How hard could it be to solve 90% of the problem?", but various BigCos have had spectacular failures in recent memory, so I guess the problem is pretty damn hard.
I wonder how terrible using git as the backbone for one's sync software would be.
I had heard about git-annex before, but never had looked into it. This sounds pretty neat! I wonder what its horrifying data-eating failure modes are! :D
Passwords could easily be both strong and memorable if we got rid of ridiculous anti-secure constraints like "password must be at most length X", "password cannot contain a space", etc.
I've heard somewhere of military organizations having people trained to go in an office and search the places people "hide" their password sticky-notes...
You're referring to the limitations imposed by security as a spectrum versus usability (more secure to more usable). I don't think many people consider a lack of privacy to be a "feature" in the usability sense -- that's typically desirable by 3rd parties, not the users.
I do agree with your profit motive. I consider that a potential opportunity rather than a problem.
What we see in practice with all extant implementations of blockchains is increasing centralisation. Because computing hashes is the sort of computation whose efficiency per watt greatly increases with more and more specialised hardware. Thus the Bitcoin situation, where the promise of everyone being able to mine a few coins has become a small number of Chinese mining pools; altcoins do no better.
Most altcoins are Proof of Stake, where mining via computing hashes doesn't take place. "Blockchains" isn't limited to Proof of Work, you can even get non-PoS/PoW blockchains such as Hyperledger.
Total security is not having a computer, or having it off all the time. So in the limit, they must interfere. What you're saying is you refuse to believe we cannot have an acceptable compromise. That I think is reasonable.
Not sure if you've ever heard of Bruce Schneier, but he is regarded by many as the father of modern cryptography. He also happens to know a thing or two about security, and frequently testifies to the US government such as the Senate on cybersecurity related matters.
Schenier's own words:
"""
Designing systems for usability is hard, especially when security is involved. Almost by definition, making something secure makes it less usable.
"""
Feel free to disagree with one of the leading experts in the field, but I doubt you'll end up right.
No denying that, though sometimes I wonder why. For fun google for "bruce schenier $mammal" theres a good chance you'll find a blog post with him putting out an odd analogy.
Then we need to devote actual money to pay students to spend time teaching laypeople or varied ages/economic backgrounds/attention spans how to send secure messages. Or we need some other way to build up a bunch of people who care about and have the skills to resolve that tradeoff.
Define security. Not too long ago it was considered "rude" to have a not world-readable home directory on a unix server.
Today, "everyone" is worried about SIGINT by nation states. Meanwhile, there's little talk about things that can actually protect you from criminals like why is code written so shittily in general and why aren't we using a Rust-like solution for internet facing applications? Why is AV useless and unable to stop well-known malware like cryptocker variants? Why are my desktop/cloud files unencrypted by default? Why phishing scammers are constantly emailing me with realistic looking fake sites? Why doesn't Microsoft have a solution to the "download invoice.pdf.exe" problem?
Yes, Obama reading my "maymays" is bothersome, but that's not what my grandma needs. She needs a better way to get online and not get infected, her identity stolen, etc. So, who gets to define priorities here? You? I'd rather lean towards protecting Grandma's than geeks obsessed with the NSA's data collection program. Morally, I see the former as more important. That's my bias and its as valid as yours. If we can't agree then who can?
> Yes, Obama reading my "maymays" is bothersome, but that's not what my grandma needs.
Grandma needs a phone. A lot of those problems are implicitly disappearing as a majority of tech-illiterate users are moving to mobile platforms, which are far more locked down.
> So, who gets to define priorities here? You?
Those that work on it? Why isn't that obvious? Steps towards fixing either problems are good, so those that work on them get to work on whatever the hell they want, really.
It must have been an exciting surprise for attendees.
I'm glad Snowden said DNS should be encrypted. From the tweet stream provided by @conflictmedia, that was tied for 1st for most re-tweeted, along with making the Internet for users, not spies. (It should be noted that DNSSEC is not encrypted.)
Too bad his appearance wasn't recorded, but HUGE thanks to Niels ten Oever and Rich Salz for tweeting major points!
You know, it's funny because just last week, I chatted with a friend of mine in the UK giving me some pretty crazy rundown of DNS issues he was having. I found out that BT (UK's leading ISP) hijacks DNS for parental control purposes (read: pornblock).
This is by law in the UK. A 2014 amendment to the 2003 Communications Act forces ISPs to do this. Blame the government, not the ISPs.
edit because HN won't let me post a rebuttal to the reply below:
Private corporations can be compelled and coerced by the government in other ways that aren't readily publicized. If you think these companies enjoy wasting resources on porn filter then you're crazy. Wikipedia:
"Prime Minister David Cameron made it clear in July 2013 that his aim was to ensure that by the end of 2013 all ISPs would have a filtering system in place.[13] As a result three of the four major ISPs (TalkTalk, Sky and BT[14]) began applying default filtering to new customers in 2013[15] with the fourth major ISP, Virgin, doing so in February 2014.[16] Default filtering of existing customers was implemented by all four major ISPs during 2014 with the aim of ensuring that the system applied to 95% of all households by the end of the year.[17][18]"
This timing isn't a big coincidence. Elect a better PM (or indirectly elect considering this is the UK) if you don't want such shenanigans.
1. Porn filtering is not law in the UK, that is a common misconception. It was merely encouraged by the government, but ISPs are not forced to offer it. The ISPs absolutely are the ones to blame.
2. DNS hijacking certainly is not mandated by law.
Edit: Here is a post by Adrian Kennard, CEO of Andrews & Arnold ISP in the UK, regarding porn filters:
Separate reply to your edit. [btw, you can click the timestamp in my comment if you are not presented with a reply link]
> If you think these companies enjoy wasting resources on porn filter then you're crazy
I don't know who's misleading you but BT offered parental controls, including adult content filtering, long before the 2013 governmental push. All they did was turn it on by default (it was off by default, before).
And none of this excuses hijacking DNS to offer parental controls. There are far better technical ways to achieve that.
And by the way, I don't live in the UK anymore and I don't like what you're implying with who I may or may not be voting for. I left when it got shit. Voted with my feet.
Sorry I'm a non-devops programmer ;) bad me. What are the better ways? HTTP 403 and friends? (Praying that you won't say "a .exe to fix the browser's access to porn")
Router-level blocklists/firewalling are the most common, but there are other ways. Think of how companies sanely implement their internal web access filters.
This is where I get to plug djbdns and DNSCURVE over DNSSEC. I think DJ has been ahead of the curve (no pun intended) on these things for quite some time. I am currently in the process of migrating from bind9 (and avoiding bind10 like the plague) to djbdns wherever possible. Quirks and lack of updates/extensions not withstanding, it's great so far.
I think that's a mistake. You are using abandoned software: djbdns 1.05 was released in 2001. It even has a published security flaw from 2009, for which the $1000 guarantee was paid by DJB, and yet there is still no official release to fix the issue (there is a patch available from other sources).
There is a fairly healthy ecosystem of BIND alternatives these days, but djbdns is not one of them.
This one? http://article.gmane.org/gmane.network.djbdns/13864 It is a little disappointing he didn't issue a new release with the patch included. Perhaps it can be rationalized that the original fork is abandoned, but distro-maintained forks are fine.
As someone who runs tinydns to serve a few personal domains, I'd be interested to hear of another simple, solid option, if it fixes any concrete problems a recent Ubuntu build of tinydns has.
A major issue with DNSCurve (and, to some extent, DNSSEC) is that you can't really do validation on the client.
Routers frequently redirect anything going to port 53 to a local cache and anything that doesn't look like regular, unencrypted DNS queries, will be dropped on the floor.
It's also fairly common to have routers only support some DNS records, or to be unable to return more than one record type in a response (e.g. no RRSIG records and A records together). Wi-fi access points are particularly good at making any attempt at making DNS more secure next to impossible.
I've been working on DNSSIG, a DNSCurve-like protocol that encapsulates signed responses in TXT and CNAME records, similar to what ip-over-DNS tunnels do. The end result is pretty ugly.
DNSCrypt initially used port 53, similar to DNSCurve, but it turned out to be a terrible idea, as it didn't work for the majority of home users, that had routers redirecting DNS queries.
> (Fully encrypted DNS can only fail in even more ways than dnssec.)
The main reasons DNSSEC fails frequently are:
* pre-computed signatures, rather than online signing
* a demented, overly complex protocol
* signatures that expire rapidly
Maybe tptacek can name some others.
The only DNS encryption people are currently using (DNSCurve/DNSCrypt) does per-packet encryption, with a very simple protocol involving only a single ciphersuite designed by djb, and no signatures. This makes all the difference in the world.
If encryption were so bad then people wouldn't be using TLS, SSH, etc. It's the terrible design of DNSSEC that has poisoned efforts in DNS security.
It's probably time to retire unauthenticated encryption as useless.
Now, if what you meant is that it uses AEAD, that amounts to the same thing as a signature. It has all the same failure modes, namely failure to authenticate.
DNSSEC is a clusterfuck, but if somebody can't put the right public key in the right place, I'm not convinced they'll be able to put the right public key in the right record with DNSCurve either. The exact same thing will happen, and then the solution will be "click here to disable dnscurve".
DNSCurve and DNSCrypt use authenticated encryption.
DNSCrypt is not stuck to "a single ciphersuite designed by djb". The ciphersuite is negotiated (using DNS queries + signed responses in DNSCrypt v2, and TLS in DNSCrypt v3).
Over TCP, it's not limited to "per-packet encryption" either.
The first of those is actually a very important feature. In an age where many organizations outsource their DNS hosting, it's more important than ever to sign your resource records offline.
It's pretty useless to invent a new scheme that gives Amazon and Cloudflare access to your cryptographic keys, so your favorite three letter agency could just go via them instead.
Only you can sign your data, and no one else. That is a feature we cannot compromise on if we face the sort of adversaries mentioned here.
The rapidly expiring signatures is actually a feature too. It serves to avoid the trainwreck that is TLS certificate revocation. But that is a technical problem that may have other solutions. Feel free to suggest one.
If a future DNS improvement (hopefully, blockchain based) starts providing SSL keys to reduce the latency required for an SSL connection on HTTP/2 (skipping the "Connection: Upgrade") and on HTTP/1 (when being redirected from http to https), it would provide advantages and would also encourage encrypted DNS queries.
Well, luckily for humanity this is exactly what I've been coding full time since December of 2014, dedicating my life to. I have been designing it for many years.
The first layer, MORPHiS, is a global secure encrypted distributed datastore that deprecates bittorrent, email and the web so far and is slated for release at the end of this Month!
Sorry for reddit; it is because I keep getting shadow banned here for being pro Snowden, Etc. Do not worry, MORPHiS is designed to deprecate hacker news! Anyways, the website is morph.is but doesn't launch until the 31st of this month. Read the only article in the /r/morphs subreddit for lots of details on MORPHiS!
Agreed. He actually knows little about most of INFOSEC compared to other, serious practitioners. He seems to be a good IT guy, expert on NSA tools, and have anecdotes of what they had trouble hitting. Far as security engineering, I'd trust a source with a good track record of building and breaking stuff similar to what I'm assessing.
People are leaning on him way too much for way too many things. I'm not even saying my statements apply to the article here so much as in general for people interviewing or citing him. Anyone reading posts of high-security engineers pushing strong hardware and software security pre-Snowden would've survived almost everything in NSA's toolbox using such methods. Leads me to add that Snowden seems totally unfamiliar with that stuff and it's unsurprising given his job was SIGINT-related rather than strong INFOSEC.
My only failure was not focusing on clean slate chips and hardware design enough. My priority was software but prioritizing the kind of hardware I've promoted here & elsewhere would've got me further. Makes the software easier to secure. Just was too lazy to learn all the hardware engineering knowledge it takes to (a) do custom hardware and (b) do sub-micron, custom hardware. I'm making amends now, at least.
We have the tech: Strong encryption, Tor-like relays, and the blockchain. What we need is a way to make services based on these technologies not just as easy to use but easier to use for the average Jane.
If the internet as we know it is to survive, we have to crack this nut.