5 ms·

you don't know how e2e security works, do you? without the source, it is not verifiable. it could be making a copy and sending it in an encrypted side-channel f

you don't know how e2e security works, do you? without the source, it is not verifiable. it could be making a copy and sending it in an encrypted side-channel for example to their overlords.

tptacek 11y ago
Very angry open source advocate, I understand how frustrating it must be that the current safest mainstream messaging protocol is not open source, but once again: that's not how computer software works. WhatsApp isn't even obfuscated. There are tens of thousands of people who read "closed source" software as a hobby. Later: Also? That's not what the term "side channel" means.
- jamesdwilson 11y ago
  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?
      - 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.
cortesoft 11y ago
Yeah.... I am pretty sure he DOES know how e2e security works.

you don't know how e2e security works, do you? without the source, it is not verifiable. it could be making a copy and sending it in an encrypted side-channel for example to their overlords.

tptacek 11y ago

Very angry open source advocate, I understand how frustrating it must be that the current safest mainstream messaging protocol is not open source, but once again: that's not how computer software works. WhatsApp isn't even obfuscated. There are tens of thousands of people who read "closed source" software as a hobby. Later: Also? That's not what the term "side channel" means.

jamesdwilson 11y ago
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?
    - 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.

cortesoft 11y ago

Yeah.... I am pretty sure he DOES know how e2e security works.