Hacker News new | ask | show | jobs
by bromquinn 2053 days ago
Serious question. How does one know that any secure communications provider is secure? I use tools like Signal and protonmail, but this article has me thinking that those might as well be government ops.

Presumably the governments who purchased systems from Crypto AG had people educated in security do some due diligence on Crypto AG's products before purchasing them. If they didn't realize that the products were compromised by the US, what chance do I have?

8 comments

This is why the UNIX philosophy of distributing only source code and building locally for apps is important. You can never 100% know for sure if that code doesn't have a security backdoor, but at least you have the opportunity to self audit.
Reproducible build [0] is the modern solution to this problem, it generates the same binary output on everyone's computer by carefully controlling the compiler version and input data to the build system, thus allowing users to independently verify that an official binary is a faithful build from its source code. Although it's not a silver bullet (compiler bootstrapping is still vulnerable), but still greatly increases the level of confidence. Signal adopted reproducible build since 2016 [1].

[0] https://reproducible-builds.org/

[1] https://signal.org/blog/reproducible-android/

Did you read this part?

> You can never 100% know for sure if that code doesn't have a security backdoor

How does compilation methodology help with analyzing millions of lines of code?

Did you read this part?

> This is why the UNIX philosophy of distributing only source code and building locally for apps is important. You can never 100% know [...], but at least you have the opportunity to self audit.

My comment was a reply to "distributing only source code and building locally for apps is important", and I pointed that reproducible builds enabled an alternative method to achieve the same without requiring everyone to rebuild from scratch (which is arguably worse from the perspective of uncertainty). And that's all. I didn't have anything to say on the audit question.

But if you want to nitpick, yes, this reply is incomplete, and to defend my comment properly, I should've quoted the first (and only the first sentence) from the comment which I was replying to clarify my point. On the other hand, I think it would be painful to do a full-time proofreading of every single comment I'm going to make.

Now this makes sense. The original comment did not. Thanks.
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Ken Thompson “Reflections on Trusting Trust”

https://dwheeler.com/trusting-trust/

David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers

In particular see the new section on that page, "Real-world application of DDC".

Sure, but I don’t have time to read the EULAs that come with the stuff I buy as it stands, and that’s arguably easier to read and shorter than it would be to read all of the source for a service that I want to use. Not only that, but to be fully confident, you would need to review the source code after every single update.

As an example, OpenSSL is open source and widely used, yet even they missed heartbleed.

Of course. None of us, individually, have the time to do that. Collectively, however, we at least have the ability to do so and that, in and of itself, is a big reason for TLAs and such to not try to hide backdoors in products.

Being open source doesn't magically make software perfect or free of bugs.

> Presumably the governments who purchased systems from Crypto AG had people educated in security do some due diligence on Crypto AG's products before purchasing them.

Presumably they didn't. The article states "employees in the engineering and research departments repeatedly identified vulnerabilities in the products’ designs that they were mysteriously prevented from fixing", which implies that all it takes is for competent people to view the source code to expose the sort of fraud that was happening here.

The difference is that the operation of the Crypto AG machines was secret. Only the employees of the company had access. The operation of some contemporary systems is available to the whole world in the form of source code. In some cases multiple entities with no particular connection actually work on that source code. The trick is in insuring that the source code is the only thing that contributed to the program you are running.

As a fairly extreme example, consider what it would take to backdoor GnuPG. It is distributed to multiple platforms/OSes, most of which allow anyone to check both the signatures on the source code and then recreate the binaries.

If you use GnuPG on a system with any unverified-build and audited for security compliance software / hardware, can you be certain GnuPG is behaving as expected?
For what it's worth, Debian's gnupg2 package builds reproducibly[0]. That doesn't mean that the Debian-specific patches[1] have necessarily been widely audited though, even if the upstream code itself has enough eyes on it.

Also it's not exactly clear how an end user would discover that the Debian package they installed had a different checksum from the version that was reproducibly built, or if sufficiently independent teams are re-creating these checksums and have a way of notifying people of discrepancies.

[0] https://tests.reproducible-builds.org/debian/rb-pkg/unstable...

[1] https://sources.debian.org/src/gnupg2/2.2.20-1/debian/patche...

You don't need the other software on a system to be audited for security compliance. You just need to know that it is not actively malicious. So any run of the mill Linux or BSD not running proprietary software.
> How does one know that any secure communications provider is secure? I use tools like Signal and protonmail, but this article has me thinking that those might as well be government ops.

We need independent crowdfunded external audits for that like the one performed for TrueCrypt.

TrueCrypt Rest In Peace.
Actually AFAIK it still works fine except privilege escalations (which do not concern users caring about security and using Qubes OS).
VeraCrypt is what most moved to iirc.

I still actually wonder what actually happened to TrueCrypt. Did a dev get threatened with a NSA or FBI NSL? Did they get asked to implant a bug so they shut it down instead? So many questions.

Conspiracy theory me says it was the NSA. From their home page warning.

> WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues.

The phrase “not secure as” is interesting as the first letter spell out NSA.

Also, the first letters of "unfixed security" are "U.S." which could be another hint.

Plus, "Using TrueCrypt" -- "UTC". According to Wikipedia, UTC is "a successor to Greenwich Mean Time" -- Greenwich, London, England. GCHQ is in England! So, obviously, it was a partnership between NSA and GCHQ!

Surely we can come up with even more irrefutable evidence^W^Woutrageous theories if we devote a few minutes to it.

This is actually theoretically solveable if you can guarantee who is sending/receiving message, no undetecatble eavesdropping.

https://en.wikipedia.org/wiki/Quantum_key_distribution

Seriously, this is why I strongly encourage people to find alternatives to Signal. The program even ties an unique short identifier which cannot be changed at will by the user, a phone number, to the account. There are alternatives.
I use signal because it's "good enough" and has a lower barrier to entry for less technical people, but having reviewed MM's stance on many issues, I honestly wouldn't be surprised to find out he or his company are a sort of Adrian Lamo 2.0 (obviously a bad comparison but I think you get my meaning). The bottom line is that if you are trying avoid nation states... and this is going to go against almost everything you have been taught and heard... you should probably be rolling your own crypto. It might be more doable than you think, but once again you run into the problem of how do you get others to adopt? I first heard this stance from former NSA technical director William Binney, and balked at first, but after ruminating on it for some time I think he has a point. Especially when so many of these crypto compromises happen because there is a central org thats easy to focus target (the main weakness in MM's position), vs having no central org or even being on any radar other than NSA data hoovers. Autoanalysis of comp'd communication systems wouldn't work if they don't have your crypto-comms in the list, but the thing to be aware of there is the ability for them to "walk the cat back" on comms if they do break it later.

Don't forget also that these organizations heavily participate in forum ops to sway opinion on these topics [1] so operating by consensus can be very dangerous imho. I remember one particular example being the allegations about the FBI paying contractors on ipsec to backdoor it [2]. Which was then met with all kinds of "analysis" about how it wasn't true, and that sort of became the consensus response for a while after, except a year or so later I found a post by one of the devs explaing further detail and it became obvious to me that ipsec had been backdoored and they had just engaged in "consensus cracking". Of course only a few years later Snowden leaks confirmed that ipsec was weak by design and had been being intercepted for quite some time. Also worth noting that while Snowdens doc were released in 2013, the actual docs were mostly from ~2007 era. Think about how much tech has changed since then, and then imagine just how much more powerful the systems are today. Not just the technical systems, but the organizational structures designed to prevent any kind of truly secure crypto from emerging.

1. https://archive.is/JlBgE

2. https://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-T...

PS. Also worth noting that Eben Moglen talked about how after the gov lost the crypto wars, he heard a chilling comment about how basically they wanted to do away with anonymity also. I think it's worth noting that anonymity and crypto are hand in hand tech, and if you comp one pivoting into the other is much easier. The gov has worked on comping both quite extensively.

People are vetting Signal, so unless you are the target of a directed attack against you, you are better off.

The Crypto AG phones were from a different era.

Signal is probably safe for the data[†], but as we know, the NSA cares even more about metadata – and since Signal's centralized servers are (all?) located in California…

[†] - then, considering stuff like this, even vetted open source code might be at risk (remember that the NSA can afford the best programmers in the world !) :

http://underhanded-c.org/

http://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thom...

If you're worried about metadata, then you're probably best off publishing encrypted gists. Yes you have to poll to get the update, but it's better than getting hit by timing analysis.
They don't care more about metadata, it easier for them to collect.
What people? Vetting how? The problem remains: If you don't read and understand all the code (which is basically impossible for most people), then you have to trust some source of information, which in turn is based on some other source etc.

In short: You can basically never know for sure if any complex product is completely secure. You can make guesses, and the more research you do, the closer you get to an answer. At some point, you have enough information to deem a solution "secure enough" for a specific use.

For regular users, it's mostly a question of belief.

I'm pretty sure anything in the app store is crackable.
https://en.wikipedia.org/wiki/FinFisher

<< FinFisher malware is installed in various ways, including fake software updates, emails with fake attachments, and security flaws in popular software. Sometimes the surveillance suite is installed after the target accepts installation of a fake update to commonly used software.[2] Code which will install the malware has also been detected in emails.[17] The software, which is designed to evade detection by antivirus software, has versions which work on mobile phones of all major brands .>>

no backdoor is needed when a users behaviour will let you in. it helps greatly when the service provider co-operates

What argument are you making?

Putting something into the App Store somehow makes the app itself vulnerable?

Or, the App Store tends to attract already vulnerable software?

Probably both. If the NSA thought it unbreakable, the app would not be easily available to the public.
An iOS backdoor is the way to go. Otherwise the NSA has to monitor an endless cycle of new apps.
Not if there is a backdoor added to all apps on the app store automatically.