6 ms·

Unless it's opensource, it can't be trusted. Not saying it is enough, but it is a requirement. But that's not enough, any smartphone OS maker (google and apple)

Unless it's opensource, it can't be trusted. Not saying it is enough, but it is a requirement. But that's not enough, any smartphone OS maker (google and apple) can be ordered to install a Trojan by force and keylog everything. So you'd need something like http://www.replicant.us/ http://www.replicant.us/ I guess and compile it yourself if you're completely paranoid. Even then, there could be a keylog in the hardware directly talking to the bios. tl;dr: if you want complete risk-free privacy, a smartphone is probably not what you want. I use a smartphone myself by the way, just saying.

nickpsecurity 11y ago
That's not true: strongest products ever made were high-assurance closed source. There's also been strong FOSS apps. Most apps, open or closed, are insecure due to lack of rigor or specialist skill. Key things are right development, review, and distribution. I broke it down in the essay below: https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639 https://www.schneier.com/blog/archives/2014/05/friday_squid_... Review and identification/possession of what was reviewed are important points. Mass publication or distribution of source hasn't proven to be a determining factor.
- zanny 11y ago
  > strongest products ever made were high-assurance closed source Because we never found the backdoors put in place by the developers does not mean they were not there, and without source access we have absolutely no reason to believe anyone when they say there are none.
  - nickpsecurity 11y ago
    High assurance prevents that by full specs of all success and failure states, modular code, avoidance of dangerous constructs, covert channel analysis, testing of execution paths, pentesting with source, and so on. You could conceivably slip a backdoor in with extra cleverness sure. Yet, whether OSS or closed, you depend on talent of reviewers to find it for you. High-assurance closed has most labor put into that. That's why it was more secure. Aside from activities described above that were mandatory for high assurance security but optional or ignored for the rest.
- mSparks 11y ago
  Fundamentally disagree. They all have code that can be exploited. Not least because software is "not an island" without secure hardware there is no way to prevent the software being exploited. The trick is opensource software running on locked down hardware built in house. You absolutely cannot trust any of the developers. Even Apple has said "we can't be trusted with your keys so we can't keep them". Trusting them to provide a non compromised build of the software they make is no different, that's the whole point of the court case. If it isn't open source you can't build your own secure version.
Matt3o12_ 11y ago
Compiling it yourself is not always necessary. If you are able to reproduce the build yourself (and match hashes of the build), you can be fairly certain that the binary is actually secure even if you did not check it yourself. If it was reproducible, some people would check that and point out if the hashes don't match. You need to have a secure way to get the hashes from the build, though. One way to do it is to fetch the hash from multiple sources (e.g. your mobile phone (not connect over WiFi, of course), your PC (that is connected over Ethernet/WiFi), and maybe a VPN). MITM all these connects at the same time is hard. If you are super paranoid you could always join an IRC and ask for the hashes. Real-time MITM the traffic is probably close to impossible (the attacker needs to read every message, and then decide to change it vs. just serving a different static HTML page). Compiling the source code seems pretty useless to me. I do not want to read the 10000 lines of code such an app might use. There might be just a little line inside some auto-generate GUI code that is malicious and sends the unencrypted message to somebody's servers. And sending malicious source code is not that hard, either.
- nickik 11y ago
  Your essentially argue for network vision for verification. Keybase is doing a interesting thing were they have a Merkel tree and then they put the root of the Merkel tree into the bitcoin blockchain. When you fetch the tree, you can check the validity on the blockchain. They could use public key pinning that people are sure to always hit keybase.io and then verify on the blockchain (I must check if they actually have HPKP activated). An viable attack on that is pretty damn near impossible without actually comprosing the end user device. An viable attack on that is pretty damn near impossible without actually hacking into the end user device.
studentrob 11y ago
True, but this is a part of the issue that can be raised separately from what Obama and the DOJ are talking about. I think we really should stay focused on the legal battle. If the government brings up federal level legislation mandating backdoors in IT companies' products, we're going to need a very educated public to understand how encryption works and what's really at stake. Right now, our head of state is spreading FUD that he believes to be accurate and we know is false. This must be corrected if we are to maintain public safety, and secondarily, a growing economy.

nickpsecurity 11y ago

That's not true: strongest products ever made were high-assurance closed source. There's also been strong FOSS apps. Most apps, open or closed, are insecure due to lack of rigor or specialist skill. Key things are right development, review, and distribution. I broke it down in the essay below: https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639 https://www.schneier.com/blog/archives/2014/05/friday_squid_... Review and identification/possession of what was reviewed are important points. Mass publication or distribution of source hasn't proven to be a determining factor.

zanny 11y ago
> strongest products ever made were high-assurance closed source Because we never found the backdoors put in place by the developers does not mean they were not there, and without source access we have absolutely no reason to believe anyone when they say there are none.
- nickpsecurity 11y ago
  High assurance prevents that by full specs of all success and failure states, modular code, avoidance of dangerous constructs, covert channel analysis, testing of execution paths, pentesting with source, and so on. You could conceivably slip a backdoor in with extra cleverness sure. Yet, whether OSS or closed, you depend on talent of reviewers to find it for you. High-assurance closed has most labor put into that. That's why it was more secure. Aside from activities described above that were mandatory for high assurance security but optional or ignored for the rest.
mSparks 11y ago
Fundamentally disagree. They all have code that can be exploited. Not least because software is "not an island" without secure hardware there is no way to prevent the software being exploited. The trick is opensource software running on locked down hardware built in house. You absolutely cannot trust any of the developers. Even Apple has said "we can't be trusted with your keys so we can't keep them". Trusting them to provide a non compromised build of the software they make is no different, that's the whole point of the court case. If it isn't open source you can't build your own secure version.

Matt3o12_ 11y ago

Compiling it yourself is not always necessary. If you are able to reproduce the build yourself (and match hashes of the build), you can be fairly certain that the binary is actually secure even if you did not check it yourself. If it was reproducible, some people would check that and point out if the hashes don't match. You need to have a secure way to get the hashes from the build, though. One way to do it is to fetch the hash from multiple sources (e.g. your mobile phone (not connect over WiFi, of course), your PC (that is connected over Ethernet/WiFi), and maybe a VPN). MITM all these connects at the same time is hard. If you are super paranoid you could always join an IRC and ask for the hashes. Real-time MITM the traffic is probably close to impossible (the attacker needs to read every message, and then decide to change it vs. just serving a different static HTML page). Compiling the source code seems pretty useless to me. I do not want to read the 10000 lines of code such an app might use. There might be just a little line inside some auto-generate GUI code that is malicious and sends the unencrypted message to somebody's servers. And sending malicious source code is not that hard, either.

nickik 11y ago
Your essentially argue for network vision for verification. Keybase is doing a interesting thing were they have a Merkel tree and then they put the root of the Merkel tree into the bitcoin blockchain. When you fetch the tree, you can check the validity on the blockchain. They could use public key pinning that people are sure to always hit keybase.io and then verify on the blockchain (I must check if they actually have HPKP activated). An viable attack on that is pretty damn near impossible without actually comprosing the end user device. An viable attack on that is pretty damn near impossible without actually hacking into the end user device.

studentrob 11y ago

True, but this is a part of the issue that can be raised separately from what Obama and the DOJ are talking about. I think we really should stay focused on the legal battle. If the government brings up federal level legislation mandating backdoors in IT companies' products, we're going to need a very educated public to understand how encryption works and what's really at stake. Right now, our head of state is spreading FUD that he believes to be accurate and we know is false. This must be corrected if we are to maintain public safety, and secondarily, a growing economy.