5 ms·

do you know even with source, backdoors can be hidden? open source is a must to even begin to work to verify any claims of security.

tptacek 11y ago
Your comment here is incoherent. I agree: source can easily lie. How does that make it the gold standard for verification? The reverse-engineering of the actual shipped binary (for instance, the ARM code lifted to LLVM) seems like a safer analysis target. But, what do I know.
- jamesdwilson 11y ago
  I actually in agreement with what you are saying about viewing the shipped binary, but source is a must also. ideally it is a reproducible build to verify the source created the binary.
  - tptacek 11y ago
    You keep saying "source is a must" but you have yet to explain why that is the case.
    - jamesdwilson 11y ago
      fair enough! https://www.schneier.com/blog/archives/2016/03/possible_govern.html https://www.schneier.com/blog/archives/2016/03/possible_gove... i think this is why source is a must. if a user compiled and installed the app themselves, and hypothetically had the entire stack above it be similarly open, then it would prevent the kind of attack mentioned. do you agree? if the source is closed anywhere in the stack, or pushed out in a walled garden as it is currently, then it allows the vulnerability mentioned.
      - swombat 11y ago
        Just in case you don't know, tptacek is a world-class security/cryptography expert who happens to hang around and share his wisdom here. You appear to be assuming he's someone thinking one or more levels lower than you. I think it would be smarter for you to assume that he fully understands your argument but is thinking one or more levels higher than you.
        jamesdwilson 11y ago
        agreed, i had no idea. i am humbled.
        tptacek 11y ago
        What's worse is that I am nowhere close to the best crypto security person on HN, and (unlike me) the best crypto people here don't brag about it.
        ComodoHacker 11y ago
        Could you share some links about Snowden & Cryptocat story you mentioned above?
        wglb 11y ago
        Here is one reference: https://en.wikipedia.org/wiki/Cryptocat https://en.wikipedia.org/wiki/Cryptocat. Additional googling will show more.
        ComodoHacker 11y ago
        Well I asked because googling showed me very little. Basically Greenwald and Snowden used Cryptocat during some online interview.
        tptacek 11y ago
        Is there something more you're looking for?
      - tptacek 11y ago
        I understand what you're saying. I don't think source is bad thing! Source is good. But I think you're a little confused here. The cryptographic building blocks of the new WhatsApp protocol are available in source code. You can get source for the Signal Protocol (fka Axolotl). You can get source for the Noise framework. WhatsApp borrowed these tools from a very open secure messaging project. You're unhappy that the source code for the fully assembled messaging product WhatsApp isn't available. I understand that, too. But you've overplayed your hand by arguing that not releasing WhatsApp source is fatal to its security. Even if WhatsApp had done that, the overwhelming majority of its users (in fact: basically all of them) would be installing binaries. If WhatsApp is so evil that they've backdoored their product, it is "supervillain monologuing for an hour while the hero escapes"-grade stupid to leave that backdoor in their source code. Consider that carefully when you trust binaries from open source companies, by the way! In reality, source code does very little to resolve the government backdoor problem. If you want to ensure that your secure messenger hasn't been backdoored, reverse engineer and/or instrument the build you're actually running. Nobody does this, of course. But while lots of people glance at source code for crypto applications, I think they're pretty much just kidding themselves. Having the source code makes them feel safer, but it doesn't actually make them safer.
        zanny 11y ago
        > Nobody does this, of course. Every Linux distribution out there compiles everything in their repo by hand. If you use an AUR package of almost everything on Arch, you are building the software by hand locally from source. You can pull build scripts from launchpad, the Suse OBS, or almost every distros package repository (they all have automated build systems for everything, and you can do it all yourself). Oh, and there is a little distro called Gentoo some people use where you literally build everything from source yourself. So nobody builds open source software from source, besides the millions of people who do it all the time. Sure, it is a tiny fraction of total users, but there is a dramatic difference between "nobody" and "somebody" just like there is a dramatic difference in confidence between "were using this secure crypto, trust us, its there! its not just something else masquerading as secure crypto that we have backdoors all over!" versus "here is the source, go build it yourself if you don't trust us". The value is not in everyone building from source themselves, just like my confidence in my software is not in auditing every line myself. It is in the general freedom of information on the security, and by offering the information to test it myself I will have inherently more trust in a project even if I never take advantage of that source availability myself - even if nobody ever does find exploits in the disclosed code, there is still trust a proprietary vendor can never have that I implicitly give free software projects because it is much more precarious to backdoor transparent software than a black box, and by just making the box transparent at all you add value.
      - feld 11y ago
        iOS is not completely open source, so how do you know that Apple isn't scraping your screen or the iOS keyboard isn't sending your characters? Also, Apple's push messaging subsystem gets a copy of (most) of the message too so Apple could be doing evil things there too! OH NOES!
        jamesdwilson 11y ago
        i agree! the full stack needs to be opened.
        revkia 11y ago
        What about their hardware?
        jamesdwilson 11y ago
        yes, the hardware too. you're reinforcing my claims, not negating them.
    - AgentME 11y ago
      I can't reply to your other comment for some reason, so I'm replying to this one. >If WhatsApp is so evil that they've backdoored their product Unless they want to go the way of Lavabit, every company is evil when kindly asked to be. (Well, maybe it helps when you have the weight of Apple, but that wasn't even a NSL if we heard about it.) >it is "supervillain monologuing for an hour while the hero escapes"-grade stupid to leave that backdoor in their source code. And if they don't, a reproducible build process will cause someone to notice the binary doesn't match up and sound the alarm, somewhat similar to how a warrant canary works even if not everyone is checking it. (Sure, the company could always go back on their open source promise for other reasons, but at least everyone is left with a last known-likely-good inspectable and forkable version.)
      - simoncion 11y ago
        > I can't reply to your other comment for some reason... Try clicking on the timestamp for the comment when you have this trouble. A reply box should appear.
  - jsmthrowaway 11y ago
    You have made this point seven or eight times that I have seen and it is bordering on cultish repetition. It is definitely spam at the least. We heard you. You're wrong, you became personal in your wrongness and accused a guy who does security for a living of not understanding E2E (do you?), and it's probably time for you to take a break. I implore you to do so. Post haste.
    - jamesdwilson 11y ago
      i apologize. i'll try to be more sensible in my posts. it is just really frustrating sometimes.
- danjoc 11y ago
  >The reverse-engineering of the actual shipped binary (for instance, the ARM code lifted to LLVM) seems like a safer analysis target. Reverse engineering binaries is only permitted under the DMCA for the purpose of interoperability, AFAIK.[1] If so, that would make reverse engineering to verify stated security claims illegal in the United States. I'll just assume I'm wrong here for the sake of argument though. Reverse engineering sounds much less friendly than providing actual source code. It's much easier for me to compare changes from version to version with source control, commit comments, and diffs. Then all I need is a reproducible build to verify that the output matches the binary being shipped. Do you have some reverse engineering tools you would suggest? Obviously the one's I'm familiar with are not as good as yours. Links to those would be greatly appreciated. [1]https://www.eff.org/issues/coders/reverse-engineering-faq https://www.eff.org/issues/coders/reverse-engineering-faq
  - tptacek 11y ago
    The LoC DMCA rules explicitly exempt security research. It's possible the EFF needs to update this page.
crazy1van 11y ago
> open source is a must to even begin to work to verify any claims of security. I think this is losing sight of what source code actually is. It's the easier to read and easier to edit way to define what a person wants the computer to do. But, it isn't actually the exact instructions the computer executes.

tptacek 11y ago

Your comment here is incoherent. I agree: source can easily lie. How does that make it the gold standard for verification? The reverse-engineering of the actual shipped binary (for instance, the ARM code lifted to LLVM) seems like a safer analysis target. But, what do I know.

jamesdwilson 11y ago
I actually in agreement with what you are saying about viewing the shipped binary, but source is a must also. ideally it is a reproducible build to verify the source created the binary.
- tptacek 11y ago
  You keep saying "source is a must" but you have yet to explain why that is the case.
  - jamesdwilson 11y ago
    fair enough! https://www.schneier.com/blog/archives/2016/03/possible_govern.html https://www.schneier.com/blog/archives/2016/03/possible_gove... i think this is why source is a must. if a user compiled and installed the app themselves, and hypothetically had the entire stack above it be similarly open, then it would prevent the kind of attack mentioned. do you agree? if the source is closed anywhere in the stack, or pushed out in a walled garden as it is currently, then it allows the vulnerability mentioned.
    - swombat 11y ago
      Just in case you don't know, tptacek is a world-class security/cryptography expert who happens to hang around and share his wisdom here. You appear to be assuming he's someone thinking one or more levels lower than you. I think it would be smarter for you to assume that he fully understands your argument but is thinking one or more levels higher than you.
      - jamesdwilson 11y ago
        agreed, i had no idea. i am humbled.
        tptacek 11y ago
        What's worse is that I am nowhere close to the best crypto security person on HN, and (unlike me) the best crypto people here don't brag about it.
        ComodoHacker 11y ago
        Could you share some links about Snowden & Cryptocat story you mentioned above?
        wglb 11y ago
        Here is one reference: https://en.wikipedia.org/wiki/Cryptocat https://en.wikipedia.org/wiki/Cryptocat. Additional googling will show more.
        ComodoHacker 11y ago
        Well I asked because googling showed me very little. Basically Greenwald and Snowden used Cryptocat during some online interview.
        tptacek 11y ago
        Is there something more you're looking for?
    - tptacek 11y ago
      I understand what you're saying. I don't think source is bad thing! Source is good. But I think you're a little confused here. The cryptographic building blocks of the new WhatsApp protocol are available in source code. You can get source for the Signal Protocol (fka Axolotl). You can get source for the Noise framework. WhatsApp borrowed these tools from a very open secure messaging project. You're unhappy that the source code for the fully assembled messaging product WhatsApp isn't available. I understand that, too. But you've overplayed your hand by arguing that not releasing WhatsApp source is fatal to its security. Even if WhatsApp had done that, the overwhelming majority of its users (in fact: basically all of them) would be installing binaries. If WhatsApp is so evil that they've backdoored their product, it is "supervillain monologuing for an hour while the hero escapes"-grade stupid to leave that backdoor in their source code. Consider that carefully when you trust binaries from open source companies, by the way! In reality, source code does very little to resolve the government backdoor problem. If you want to ensure that your secure messenger hasn't been backdoored, reverse engineer and/or instrument the build you're actually running. Nobody does this, of course. But while lots of people glance at source code for crypto applications, I think they're pretty much just kidding themselves. Having the source code makes them feel safer, but it doesn't actually make them safer.
      - zanny 11y ago
        > Nobody does this, of course. Every Linux distribution out there compiles everything in their repo by hand. If you use an AUR package of almost everything on Arch, you are building the software by hand locally from source. You can pull build scripts from launchpad, the Suse OBS, or almost every distros package repository (they all have automated build systems for everything, and you can do it all yourself). Oh, and there is a little distro called Gentoo some people use where you literally build everything from source yourself. So nobody builds open source software from source, besides the millions of people who do it all the time. Sure, it is a tiny fraction of total users, but there is a dramatic difference between "nobody" and "somebody" just like there is a dramatic difference in confidence between "were using this secure crypto, trust us, its there! its not just something else masquerading as secure crypto that we have backdoors all over!" versus "here is the source, go build it yourself if you don't trust us". The value is not in everyone building from source themselves, just like my confidence in my software is not in auditing every line myself. It is in the general freedom of information on the security, and by offering the information to test it myself I will have inherently more trust in a project even if I never take advantage of that source availability myself - even if nobody ever does find exploits in the disclosed code, there is still trust a proprietary vendor can never have that I implicitly give free software projects because it is much more precarious to backdoor transparent software than a black box, and by just making the box transparent at all you add value.
    - feld 11y ago
      iOS is not completely open source, so how do you know that Apple isn't scraping your screen or the iOS keyboard isn't sending your characters? Also, Apple's push messaging subsystem gets a copy of (most) of the message too so Apple could be doing evil things there too! OH NOES!
      - jamesdwilson 11y ago
        i agree! the full stack needs to be opened.
        revkia 11y ago
        What about their hardware?
        jamesdwilson 11y ago
        yes, the hardware too. you're reinforcing my claims, not negating them.
  - AgentME 11y ago
    I can't reply to your other comment for some reason, so I'm replying to this one. >If WhatsApp is so evil that they've backdoored their product Unless they want to go the way of Lavabit, every company is evil when kindly asked to be. (Well, maybe it helps when you have the weight of Apple, but that wasn't even a NSL if we heard about it.) >it is "supervillain monologuing for an hour while the hero escapes"-grade stupid to leave that backdoor in their source code. And if they don't, a reproducible build process will cause someone to notice the binary doesn't match up and sound the alarm, somewhat similar to how a warrant canary works even if not everyone is checking it. (Sure, the company could always go back on their open source promise for other reasons, but at least everyone is left with a last known-likely-good inspectable and forkable version.)
    - simoncion 11y ago
      > I can't reply to your other comment for some reason... Try clicking on the timestamp for the comment when you have this trouble. A reply box should appear.
- jsmthrowaway 11y ago
  You have made this point seven or eight times that I have seen and it is bordering on cultish repetition. It is definitely spam at the least. We heard you. You're wrong, you became personal in your wrongness and accused a guy who does security for a living of not understanding E2E (do you?), and it's probably time for you to take a break. I implore you to do so. Post haste.
  - jamesdwilson 11y ago
    i apologize. i'll try to be more sensible in my posts. it is just really frustrating sometimes.
danjoc 11y ago
>The reverse-engineering of the actual shipped binary (for instance, the ARM code lifted to LLVM) seems like a safer analysis target. Reverse engineering binaries is only permitted under the DMCA for the purpose of interoperability, AFAIK.[1] If so, that would make reverse engineering to verify stated security claims illegal in the United States. I'll just assume I'm wrong here for the sake of argument though. Reverse engineering sounds much less friendly than providing actual source code. It's much easier for me to compare changes from version to version with source control, commit comments, and diffs. Then all I need is a reproducible build to verify that the output matches the binary being shipped. Do you have some reverse engineering tools you would suggest? Obviously the one's I'm familiar with are not as good as yours. Links to those would be greatly appreciated. [1]https://www.eff.org/issues/coders/reverse-engineering-faq https://www.eff.org/issues/coders/reverse-engineering-faq
- tptacek 11y ago
  The LoC DMCA rules explicitly exempt security research. It's possible the EFF needs to update this page.

crazy1van 11y ago

> open source is a must to even begin to work to verify any claims of security. I think this is losing sight of what source code actually is. It's the easier to read and easier to edit way to define what a person wants the computer to do. But, it isn't actually the exact instructions the computer executes.