6 ms·

Explain to me the trust chain of a crypto messaging app that you DO think is safe and secure. Seriously, pick one, let's talk about it. Let's compare and contra

Explain to me the trust chain of a crypto messaging app that you DO think is safe and secure. Seriously, pick one, let's talk about it. Let's compare and contrast. Or would you prefer to parrot the same tired old arguments that pop up on the HN comments every time the concepts "web browser" and "cryptography" are used together?

chpp 12y ago
Thinking about the answer to this hurts my brain. Ultimately, with the amount of money and resources available to the "bad guys", I can't imagine something as truly uncrackable. But I am just a lowely infrastructure guy that builds VPNs, lots of smart folks out there :)
williamcotton 12y ago
Here, I'll speed it up for you with this conclusion: Unless people are downloading from source, verifying signed checksums, and building their crypto applications from source they are just as susceptible to any of the issues that browser crypto is. Prebuilt executable? Can't be trusted. A modified version could have been substituted at download time for a particular user. Web site where signed checksums are published? Can't be trusted. It could have been hacked or altered. Checksum embedded in executable which checks itself at run time? Can't be done. Trust is the issue. Trust NEVER goes away. The only way to know for sure is if you compile all your own code. But wait, remember Ken Thompson on Trusting Trust? You had better be building your own compilers as well... So basically you're saying that no one but computer experts who build their entire toolchain from scratch should be using any sort of application that uses cryptography.
- schoen 12y ago
  Those problems are quite serious. A positive step is that they've been increasingly recognized as serious by people who develop and publish software, so there are significant transparency efforts underway now to try to make it possible to meaningfully tell where software came from, whether it corresponds to published code, and whether it's the same thing everybody else is using. (Along with Mike Perry from the Tor Project, I gave a talk about some of these issues at Mozilla recently, which was pretty well-received. Tor has been very interested in making sure that compromises of their infrastructure won't compromise the software their users get, and that the developers can't be coerced into giving users backdoored versions; see Perry's "Deterministic Builds Part One: Cyberwar and Global Compromise", for example.) To look at this from another angle, all of these issues are terrible gaps in software security, and terribly exciting opportunities for people to add backdoors (maybe more likely bugdoors), but now we have some tools and ideas that can start to address them!
  - williamcotton 12y ago
    Great! Can we now stop pretending that browser crypto is the only thing is susceptible to these issues?
- upperechelon 12y ago
  Actually that's not what I'm saying at all. I'm critiquing the implementation of this for several reasons: -The JS crypto can be trivially MiTMed. Your approach of checksumming the JS you outlined in another comment using external servers is laughably terrible -The OTR is pointless. The keys aren't being verified so, again anyone could MiTM the key exchange and trivially intercept messages, even if there was no JS. This is the main point of the app, and it's completely broken. -The entire application is relying on the security of the TLS PKI, which is horribly, horribly broken. This opens it up to attack by a huge number of people. -It's being run on a shared server, with access to the keys by the real owners. Not to mention VM memory-leaking attacks by other residents, etc. Having your entire application logic hosted online and delivered to your users every time they access the service has security ramifications, whether you'd like to believe it or not. So basically what YOU'RE saying is trusting 1 developer and trusting millions of people is the same because at some point you cannot verify every bit in the executable. Using browser crypto is worse than executables for the same reason PFS is better than non-PFS, you can't retro-actively hack or MiTM something. If both parties already have the executables stored locally (or delivered securely by an offline medium like USB stick and verified) the only way to intercept the data is compromise both end-points. TL;DR your hyperbolic "trust as slippery slope" argument is dumb
  - williamcotton 12y ago
    All I'm doing is defending use cases for the Web Crypto API. Your arguments are just as hyperbolic, BTW. Meeting up in person with USB sticks for software updates? And questioning the security of TLS? And is JS checksumming more or less laughably terrible than publishing a checksum of an executable on a web site? And does your JS MiTMed scenario depend on broken TLS? You're going to need to do more than just call something "laughably terrible". I'd prefer if you took the conversation about JS checksumming to the specific thread so as to not complicate things. Software will always have updates and they happen automatically with increasing frequency on consumer computing environments like iOS, Mac and Windows. BTW, just who are you anyways and why are you so intent on making me look like a fool for attempting to discuss viable web-based cryptography? I see that your user account is brand new. Why would anyone be pursuing the Web Crypto API? Have you broached these issues with the W3C working groups? Don't you think they'd like to know that their work is futile? Shouldn't some manager on the Chrome team have stopped them from implementing such a pointless protocol? And no, I don't think "trust as slippery slope" is a stupid argument because we have to deal with that issue every day with every aspect of consumer computing. With all of the security holes in Windows, TLS, OpenSSL, SSH and in practically every other day-to-day usage of crypto... yet somehow people can still safely and securely do all sorts of things. There is a spectrum between "totally secure" and "usable by normal people". Your refusal to acknowledge this spectrum is asinine and attacking me for mentioning it is uncalled for. Wanna talk about trust? I don't trust you and I don't trust your approach to these arguments. I don't trust your faux-elite sounding hacker nickname. Maybe you or who you work for is threatened by the average person having end-to-end encryption in web applications? Maybe you're a marketer who needs that data. Maybe you're the NSA. Maybe you want to come across as an all-knowing crypto guru and charge obscene hourly rates to companies who you've scared shitless. Maybe you're just a troll armed with the same tired old arguments I've been hearing for years. Who knows. Again, you're using a brand new account. No one knows who you are or what your agenda is... "trust as slippery slope" indeed...

chpp 12y ago

Thinking about the answer to this hurts my brain. Ultimately, with the amount of money and resources available to the "bad guys", I can't imagine something as truly uncrackable. But I am just a lowely infrastructure guy that builds VPNs, lots of smart folks out there :)

williamcotton 12y ago

Here, I'll speed it up for you with this conclusion: Unless people are downloading from source, verifying signed checksums, and building their crypto applications from source they are just as susceptible to any of the issues that browser crypto is. Prebuilt executable? Can't be trusted. A modified version could have been substituted at download time for a particular user. Web site where signed checksums are published? Can't be trusted. It could have been hacked or altered. Checksum embedded in executable which checks itself at run time? Can't be done. Trust is the issue. Trust NEVER goes away. The only way to know for sure is if you compile all your own code. But wait, remember Ken Thompson on Trusting Trust? You had better be building your own compilers as well... So basically you're saying that no one but computer experts who build their entire toolchain from scratch should be using any sort of application that uses cryptography.

schoen 12y ago
Those problems are quite serious. A positive step is that they've been increasingly recognized as serious by people who develop and publish software, so there are significant transparency efforts underway now to try to make it possible to meaningfully tell where software came from, whether it corresponds to published code, and whether it's the same thing everybody else is using. (Along with Mike Perry from the Tor Project, I gave a talk about some of these issues at Mozilla recently, which was pretty well-received. Tor has been very interested in making sure that compromises of their infrastructure won't compromise the software their users get, and that the developers can't be coerced into giving users backdoored versions; see Perry's "Deterministic Builds Part One: Cyberwar and Global Compromise", for example.) To look at this from another angle, all of these issues are terrible gaps in software security, and terribly exciting opportunities for people to add backdoors (maybe more likely bugdoors), but now we have some tools and ideas that can start to address them!
- williamcotton 12y ago
  Great! Can we now stop pretending that browser crypto is the only thing is susceptible to these issues?
upperechelon 12y ago
Actually that's not what I'm saying at all. I'm critiquing the implementation of this for several reasons: -The JS crypto can be trivially MiTMed. Your approach of checksumming the JS you outlined in another comment using external servers is laughably terrible -The OTR is pointless. The keys aren't being verified so, again anyone could MiTM the key exchange and trivially intercept messages, even if there was no JS. This is the main point of the app, and it's completely broken. -The entire application is relying on the security of the TLS PKI, which is horribly, horribly broken. This opens it up to attack by a huge number of people. -It's being run on a shared server, with access to the keys by the real owners. Not to mention VM memory-leaking attacks by other residents, etc. Having your entire application logic hosted online and delivered to your users every time they access the service has security ramifications, whether you'd like to believe it or not. So basically what YOU'RE saying is trusting 1 developer and trusting millions of people is the same because at some point you cannot verify every bit in the executable. Using browser crypto is worse than executables for the same reason PFS is better than non-PFS, you can't retro-actively hack or MiTM something. If both parties already have the executables stored locally (or delivered securely by an offline medium like USB stick and verified) the only way to intercept the data is compromise both end-points. TL;DR your hyperbolic "trust as slippery slope" argument is dumb
- williamcotton 12y ago
  All I'm doing is defending use cases for the Web Crypto API. Your arguments are just as hyperbolic, BTW. Meeting up in person with USB sticks for software updates? And questioning the security of TLS? And is JS checksumming more or less laughably terrible than publishing a checksum of an executable on a web site? And does your JS MiTMed scenario depend on broken TLS? You're going to need to do more than just call something "laughably terrible". I'd prefer if you took the conversation about JS checksumming to the specific thread so as to not complicate things. Software will always have updates and they happen automatically with increasing frequency on consumer computing environments like iOS, Mac and Windows. BTW, just who are you anyways and why are you so intent on making me look like a fool for attempting to discuss viable web-based cryptography? I see that your user account is brand new. Why would anyone be pursuing the Web Crypto API? Have you broached these issues with the W3C working groups? Don't you think they'd like to know that their work is futile? Shouldn't some manager on the Chrome team have stopped them from implementing such a pointless protocol? And no, I don't think "trust as slippery slope" is a stupid argument because we have to deal with that issue every day with every aspect of consumer computing. With all of the security holes in Windows, TLS, OpenSSL, SSH and in practically every other day-to-day usage of crypto... yet somehow people can still safely and securely do all sorts of things. There is a spectrum between "totally secure" and "usable by normal people". Your refusal to acknowledge this spectrum is asinine and attacking me for mentioning it is uncalled for. Wanna talk about trust? I don't trust you and I don't trust your approach to these arguments. I don't trust your faux-elite sounding hacker nickname. Maybe you or who you work for is threatened by the average person having end-to-end encryption in web applications? Maybe you're a marketer who needs that data. Maybe you're the NSA. Maybe you want to come across as an all-knowing crypto guru and charge obscene hourly rates to companies who you've scared shitless. Maybe you're just a troll armed with the same tired old arguments I've been hearing for years. Who knows. Again, you're using a brand new account. No one knows who you are or what your agenda is... "trust as slippery slope" indeed...