Hacker News Reader

Comment by brenden2 | Hacker News Reader

If I can compile audited code from source myself, without any backdoors, then I can be reasonably assured there aren't any backdoors (excluding perhaps hardware level backdoors--but that's why we do the encryption in software).

Implementing hardware backdoors that are opaque to end users is theoretically possible, but more difficult in practice. You could, for example, build a screen/monitor that just captures everything on the screen and forwards it to some other entity, but in practice it's not so easy because of bandwidth limitations, etc. I suppose it would be much easier to create a physical keyboard that phones home over a mobile network, although it would only give you half the conversation.

*edit: added the word "audited".

View on HN

> If I can compile the code from source myself, without any backdoors, then I can be reasonably assured there aren't any backdoors

Where does that leave the rest of society? Having open source software and hardware is not enough, we also need laws that prohibit mass surveillance and support our efforts to uphold human rights.

Relying on laws leaves a lot of wiggle room for bad actors, slippery slopes, and political opinions changing over time. Laws are based on trust in institutions (do you _really_ trust large governments?).

Laws are probabilistic, whereas math & source code is deterministic. You can verify that computer code does what it says it does. Laws depend on enforcement and complicated judicial systems (based on humans) to interpret and apply the laws, which means they can effectively change over time, and the goalposts are never stationary.

I agree that laws are not enough, independent verification must be possible. But your right to use secure software, and to audit it without risking to spend your life in prison or being killed, is ensured by laws.

This is why moving the goalposts and further normalizing surveillance is extremely dangerous. The rights that you enjoy today are not universal, and can obviously be eradicated in less than a generation.

Agreed! Thankfully software is protected by the 1st amendment in the US[1]. If not for that, I don't know where we'd be.

[1]: https://www.eff.org/deeplinks/2015/04/remembering-case-estab...

It isn't either-or. You can have reasonable laws that protect people's rights and privacy, and compile and check the source if you wish to do so.

Yes, and we should strive to use all tools for a defense in depth of our rights. Laws are the first line of defense, then politics/media, then technology from software to hardware, and finally trust in our fellow humans and ourselves. That way if one (temporarily) fails, we can fall back to the others while repairing the breach.

There is no deterministic, technological solution to the problem that all technological solutions can be banned and its users threatened with draconian punishment.

There is no mathematical escape hatch from society. All we have is a messy assortment of technological mitigations that change the cost of surveillance.

These mitigations work best in combination with constitutional rights that limit what the government of the day can do, triggered by the latest outrage in the news.

Auditing a large codebase is also probabilistic. Oversights happen, and there are ways to write code that looks like it does the intended behavior while also doing a second, nefarious thing. See https://www.ioccc.org

the backdoor could be in the hardware - the logical conclusion of your position is that we should all fabricate our own computers from scratch so that we're sure that they're secure.

This is clearly a straw man, no one wants to do this, or is suggesting that we do this. But at some point, even the most hardened OSS advocate has to trust someone (usually the hardware manufacturer). You cannot verify that the device you're on doesn't spy on you, you have to rely on the manufacturer's word that it doesn't. And the manufacturer's suppliers, of course, because the manufacturer is trusting them.

Somewhere along the stack, we all have to draw a line and say "beyond this point, I trust that I am not being spied on". You choose to draw that line at the hardware point. Others choose to draw the line at the software point.

Sadly it means the rest of society being under surveillance and actual criminals with day-to-day privacy.

And been that way since the days slavery was politically correct rather than having to jump through all the debt slave hoops it has to now.

That's a weird way too see things. You are pretty much saying that wearing a bulletproof vest won't save you from the bullet, but laws forbidding to kill people somehow magically will. Well, I suppose you also could literally say that and I kinda can see where are you coming from, but I think it's somewhat delusional.

Proper law enforcement (mind the "enforcement" part) can make a neighborhood safe enough so that nobody tries to shoot you and you won't need to wear vests. But in the end of the day, if you are messing with bad people in the bad neighborhood: bulletproof vests are real, laws are not.

And when you are talking about government enforcing the laws that are supposed to forbid uncontrollable government agencies to do what they do: well, government kinda is bad people in the bad neighborhood.

The most concerning thing about mass surveillance and mass manipulation isn't the direct impact to some hypothetical enemy of the state (although that is concerning, people in that situation are more or less a lost cause), it's that public discourse and democracy can be pushed around by some small controlling group.

>If I can compile the code from source myself, without any backdoors, then I can be reasonably assured there aren't any backdoors (excluding perhaps hardware level backdoors--but that's why we do the encryption in software).

Not necessarily. Have you ever heard of Ken Thompson's backdoored C compiler?

https://softwareengineering.stackexchange.com/questions/1848...

>Re-write compiler code to contain 2 flaws:

>When compiling its own binary, the compiler must compile these flaws

>When compiling some other preselected code (login function) it must compile some arbitrary backdoor

>Thus, the compiler works normally - when it compiles a login script or similar, it can create a security backdoor, and when it compiles newer versions of itself in the future, it retains the previous flaws - and the flaws will only exist in the compiler binary so are extremely difficult to detect.

It's not necessarily a viable attack method today, but it's the lesson behind it that's important. Anything can be compromised.

Source code availability isn’t really a solution to the trust problem. Sure, it allows for an audit, but the practical truth is that few people are qualified to perform those audits and few of them have a sufficient incentive to spend their time doing so.

So you still just invest trust in the maintainer or — if you’re lucky — the third party auditing firm who was paid to review the code.

That you can review the code doesn’t mean that anyone does so. At least not in an exhaustive and relevant way.

Closed source or open, the problem is made even worse now that we live in a Package Manager culture where even the simplest applications adopt dozens of dependencies.

I’m not saying that you should trust Facebook and their closed source applications, just that you’re not really all that safer trusting anyone else just because their source code is available.

I'm not sure I'd surmise the dependency of users to be an entire culture in and of itself. Plus, I feel like this splits hairs; going down the rabbit hole of "well who is checking the open source code" and "well who is checking the person checking the open source code" leads to endless complexity, especially when the move in question is more symbolic than substantive. If WhatsApp did not use e2e encryption by default (and they didn't), then there was possibility of governments reading the communications anyway. Does this new announcement really lessen the security and privacy of the users? To me, it sounds like they are making the policy clearer to the public, since US / UK governments have not explicitly made press releases telling citizens which of their communications will be monitored. While I am very much a proponent to end-to-end encryption for ALL communications, I think this move isn't going to sacrifice privacy that users previously had.

> If WhatsApp did not use e2e encryption by default (and they didn't)

Correct use of past tense. In the present, e2e encryption is by default.

> Does this new announcement really lessen the security and privacy of the users?

Yes it does, since e2e encryption is enabled by default now. Best I can tell, there’s no way to disable it either.

Your assumption how backdoors work is very limited/wrong, I am afraid.

You assume that you actually understand the code well enough to identify the backdoor - e.g. as some sort of function that will bypass authentication when some secret hardwired password is provided (to give a dumb example).

However, to give a real world example of backdoored crypto, it is nothing of the sort. For example, the issue with the potentially backdoored Dual_EC_DRBG pseudorandom number generator has been known since 2004 at least - but the algorithm has been standardized by ISO/NIST and used for years until the potential backdoor issue was widely publicized following the Snowden leaks and the standard was withdrawn.

Good luck finding something like that only by reading code unless you are expert in crypto and mathematics. If you were only auditing code whether or not it matches the published, supposedly correct, standard (or algorithm description), you would never find this. The backdoored code was working completely fine, exactly as intended. But the weak random number generator allowed an adversary with sufficient computing resources to break the encryption.

Yes, it is theoretically possible to create backdoors that are hard or impossible to detect, if you start 20 years ago and subvert the standards used by the entire industry.

An improvement in security and privacy isn't limited to "make it impossible, even theoretically, for anything bad to ever happen OR you've accomplished nothing". Most back doors aren't inserted by competent NSA-level actors 20 years in advance. Most are "whenever a message passes through, send a copy to this third party". They are inserted by court order for a specific case due to the government becoming interested late in the game due to a specific case. For example, when terrorists start using some secure email service, the government tries to force the service to allow them to snoop on the relevant conversations. Open sourcing the code would allow you (with the help of the community) to detect these sorts of attempts when the product involves end-to-end encryption.

So while having the source and a community auditing changes to that source doesn't prevent every possible attack against your privacy, it prevents almost every one that is plausibly detectable, which is literally as good as you can do.

Would you trust you can find any innocent 'bug' that could lead to a privilege escalation? Decades of vulnerabilities in software, open source or closed, would contradict that believe?

Reflections On Trusting Trust:

https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...

Yep, it's a super difficult problem. Having the source code available, and being able to validate the builds yourself makes everything a lot easier.

It's one of the reasons the Debian project has worked so hard at reproducible builds: https://wiki.debian.org/ReproducibleBuilds/About

Bugs can certainly occur (like Heartbleed etc) but the alternative (closed source opaque binary blobs) is much worse.

The Nix project has been a spectacular help in this regard.

No ordinary person is capable of building anything from source.

I used to use Gentoo, and I built my entire OS from source. I'm not extraordinary in any way, I'm just an ordinary person who has a deep interest in software and computers.

Which is, in itself, extraordinary. It can't be the solution for most of humanity.

I'd wager that fewer than 1/100,000 humans on the planet could feasibly build Gentoo from source.

I've done two "stage one" builds of Gentoo. I'm not super skilled but, I had a lot of time and reference material. My bet is that folks could but would not want to. There is significant time cost.

Also, I'm still using one of those original builds on my laptop - upgraded of course...still mad love for my daily driver.

>folks could but would not want to.

And so they never learned, and so they "can't".

In the same way, I can't use Gentoo or vim or compile either or ski or... :D

It's a pretty automated process. I'd estimate 1/10 of all people who can use a computer and install software at all could do it if they wanted to and had sufficient time.

Check out Nix. Deterministic source derivations of pretty much anything you might want to build, trivially re-buildable from source by anyone. It takes seconds to install the "Nix Shell" on pretty much any of the modern OSes.

Now, to avoid the "Reflections On Trusting Trust" exploit, building the C compiler toolchain from known-good "root" compiler/linker toolchains, and then comparing the output vs. self-compilation is quite a bit harder.

Define "ordinary person", as plenty of people here have. However, there's very little difference between downloading a reproducible system that compiles everything on your machine and downloading a binary with a known checksum from a perspective of trust.

I like this as a good counterpoint: https://www.schneier.com/blog/archives/2006/01/countering_tr...

If you have multiple compilers and they all aren't infected in exactly the same way (e.g. one is not infected, or they have different types of infections) then you can detect there's a problem with them.

Just because it's open source doesn't make it trustworthy or bug free. Are you going to audit tends of thousands of lines of code to find an obscure vulnerability that a state actor has gotten added in a way that's not obvious?

Do you think?

As soon as you’re building something written in, say, Javascript, then any semblance of assurance goes out of the window.

JS is an easy target. What about C or C++? You could audit the code but have you also audited your compiler? What if you used Visual Studio?

Code is an easy target. Can you trust the auditors themselves and in the absence of that, your own ability to detect a vulnerability?

The only bulletproof solution is to not use software.

That said, most of us are not as important or recognisable as we believe we are. The layperson won’t have a good reason to isolate their computer and install an airlock between their aluminium-lined office and the rest of their house.

This is just an updated version of the story about the US government scanning your emails for keywords after 9/11. They don’t even need to actually do it, they just need to say they do and most people will monitor their communications.

> If I can compile audited code from source myself, without any backdoors, then I can be reasonably assured there aren't any backdoors

Many people can compile code from source. Not so many people have the ability to audit code for obscured backdoors. The number of people that are capable to audit and have the time that is necessary to do it is practically nil.

No, you would also have to audit the entire codebase.

You could also decompile the Whatsapp APK and do the same thing (it's Java after all).

WhatsApp contains significant amount of native code, making it much more difficult to analyze.

> No, you would also have to audit the entire codebase

Look no further than the OpenSSL Heartbleed vulnerability

How are you going to get that source code onto your phone, when loading unauthorized code becomes illegal? Who are you going to talk to, when everyone else is using the approved apps? Try to think ahead a little. This arrogant naive thinking is how geeks lose and politicians get it wrong while you're not paying attention and then everyone ends up living with the consequences.

Debian's OpenSSL fiasco. For the record, I use, like and support Debian, OSS and free software but we must not spread myths

You're neglecting how a group of ignorant lawmakers could simply pass a law that forces secure-boot so your computer can only run proprietary OSes. Then they can force OS makers to only allow app store installs.

>If I can compile audited code from source myself

That assumes you can get the code. If it's illegal to distribute non-backdoored software, the code might be hard to get, for example Github might be forced to take it down.

Yes of course. The old argument that Linux is free of backdoors because it is open source. It's such a ridiculous claim. Software systems on that scale are so complex, there is NO way whatsoever to make sure there isn't a backdoor in there. I would go as far as saying that OpenSource software by definition is more vulnerable to backdoors than closed source software, exactly because the source code is available and anyone with some credibility can make patches. It is the dreamland scape of the NSA.

Hacking into closed source code is much more dangerous (politically) for them and also more difficult.

The thing with closed-source is that the binaries can be backdoored by the vendor on behalf of the NSA. This is not a new practice. With open-source code this venue is less likely to work and needs an additional layer of deception. Sure the NSA may manage to plant vulnerabilities, but flaws will not be persistent in the same way as when they're planted in cooperation with a vendor.

There's currently a push for reproducible builds which further hardens distros against such attacks.

Reply on news.ycombinator.com