5 ms·

That's just an utterly ridiculous proposition. By that logic the entire application would need to be open source, because nobody would start out by targeting t

by ryanlol 11y ago

That's just an utterly ridiculous proposition. By that logic the entire application would need to be open source, because nobody would start out by targeting the crypto if they wanted to spy on someone.

ikeboy 11y ago
Ideally it would be possible to use third party clients to connect, and so anyone could use a fully open source solution if they wanted.
- ryanlol 11y ago
  That's fair! But you need far more than just the crypto code to create a client, I think open source protocol specs would already achieve this. And my main complaint was with the claim that open sourcing their crypto code would somehow make a meaningful difference to the security of these applications to the extent where you could consider all applications that haven't done so "insecure".
  - CaptSpify 11y ago
    I don't think I get your complaint Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. Open-source is a requirement for being considered secure. It doesn't mean they aren't secure if they aren't open-source, but that you shouldn't consider it so, because you don't know if it is or not.
    - CiPHPerCoder 11y ago
      > I don't think I get your complaint > Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. There are two things you can do: 1. Watch the outbound traffic and attempt known-plaintext attacks 2. Reverse engineer the app Neither is particularly difficult. Most Android apps are trivial to break apart using Lobotomy. A large swath of software security folks specialize in binary auditing.
      - ikeboy 11y ago
        Has anyone done that and produced a fully open source app to connect to whatsapp?
        ryanlol 11y ago
        Lots of people. https://github.com/tgalal/yowsup https://github.com/tgalal/yowsup for example
        ikeboy 11y ago
        Looks like WhatsApp isn't so happy about that ... https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people-using-unofficial-clients/ https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people... Do you know if the clients work with the new encryption?
        ryanlol 11y ago
        Yes, axolotl is open source. (However I can't comment on how much it's been modified for the official client)
tremon 11y ago
Even if I were to accept your logic, what's ridiculous about that?
- ryanlol 11y ago
  Open sourcing the crypto code wouldn't be ridiculous, but pointless. What I find ridiculous though was >venders that don't agree to an audit should be considered insecure The same thing applies to every single part of the application, but not equally. No attacker is going to start out by trying to break the crypto, unless it's obviously broken. "Normal" bugs are far more common and often more dangerous (Thing RCE, or in the case of many modern apps: XSS)
  - CiPHPerCoder 11y ago
    > No attacker is going to start out by trying to break the crypto, unless it's obviously broken. Emphasis mine. I agree with ryanlol here. Why bother with active attacks when you can just steal their private key from a code execution? Similar to this, but with the priority flipped: https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/ https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
imaginenore 11y ago
ryanlol is correct though. If you open source just the end-to-end crypto part, it doesn't mean that the there's no backdoor elsewhere - it could easily leak the keys or whole conversations. The second problem is - you don't know if that source is what ended up in the binary. So yeah, unless you can compile the whole thing yourself, it should not be considered secure.
- exo762 11y ago
  Open source client and reproducible builds. Signal already does that. It's not a high bar.
  - ryanlol 11y ago
    That's a completely different from just wanting the e2e crypto source, which is useless by itself. https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/ https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
    - nxzero 11y ago
      What to you are steps towards the mass adoption of universal turnkey state-level OPSEC for everyday use? ___ So, my point that the E2E should be open source is that that code should never be the basis for a business model, so to me, it being open source makes sense. As larger system, that's why I'm saying there needs to be an audit. Also, you mentioned ATP and I agree, which is why to me it is troubling Signal instead of guarding metadata, actively collects it. Please let me know I have missed anything you'd like me to address. And I really would be interested in your thought on the question above in as much detail as you're able to share. Thanks!

by ryanlol 11y ago

ikeboy 11y ago

Ideally it would be possible to use third party clients to connect, and so anyone could use a fully open source solution if they wanted.

ryanlol 11y ago
That's fair! But you need far more than just the crypto code to create a client, I think open source protocol specs would already achieve this. And my main complaint was with the claim that open sourcing their crypto code would somehow make a meaningful difference to the security of these applications to the extent where you could consider all applications that haven't done so "insecure".
- CaptSpify 11y ago
  I don't think I get your complaint Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. Open-source is a requirement for being considered secure. It doesn't mean they aren't secure if they aren't open-source, but that you shouldn't consider it so, because you don't know if it is or not.
  - CiPHPerCoder 11y ago
    > I don't think I get your complaint > Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. There are two things you can do: 1. Watch the outbound traffic and attempt known-plaintext attacks 2. Reverse engineer the app Neither is particularly difficult. Most Android apps are trivial to break apart using Lobotomy. A large swath of software security folks specialize in binary auditing.
    - ikeboy 11y ago
      Has anyone done that and produced a fully open source app to connect to whatsapp?
      - ryanlol 11y ago
        Lots of people. https://github.com/tgalal/yowsup https://github.com/tgalal/yowsup for example
        ikeboy 11y ago
        Looks like WhatsApp isn't so happy about that ... https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people-using-unofficial-clients/ https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people... Do you know if the clients work with the new encryption?
        ryanlol 11y ago
        Yes, axolotl is open source. (However I can't comment on how much it's been modified for the official client)

tremon 11y ago

Even if I were to accept your logic, what's ridiculous about that?

ryanlol 11y ago
Open sourcing the crypto code wouldn't be ridiculous, but pointless. What I find ridiculous though was >venders that don't agree to an audit should be considered insecure The same thing applies to every single part of the application, but not equally. No attacker is going to start out by trying to break the crypto, unless it's obviously broken. "Normal" bugs are far more common and often more dangerous (Thing RCE, or in the case of many modern apps: XSS)
- CiPHPerCoder 11y ago
  > No attacker is going to start out by trying to break the crypto, unless it's obviously broken. Emphasis mine. I agree with ryanlol here. Why bother with active attacks when you can just steal their private key from a code execution? Similar to this, but with the priority flipped: https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/ https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...

imaginenore 11y ago

ryanlol is correct though. If you open source just the end-to-end crypto part, it doesn't mean that the there's no backdoor elsewhere - it could easily leak the keys or whole conversations. The second problem is - you don't know if that source is what ended up in the binary. So yeah, unless you can compile the whole thing yourself, it should not be considered secure.

exo762 11y ago
Open source client and reproducible builds. Signal already does that. It's not a high bar.
- ryanlol 11y ago
  That's a completely different from just wanting the e2e crypto source, which is useless by itself. https://www.bishopfox.com/blog/2016/04/if-you-cant-break-crypto-break-the-client-recovery-of-plaintext-imessage-data/ https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...
  - nxzero 11y ago
    What to you are steps towards the mass adoption of universal turnkey state-level OPSEC for everyday use? ___ So, my point that the E2E should be open source is that that code should never be the basis for a business model, so to me, it being open source makes sense. As larger system, that's why I'm saying there needs to be an audit. Also, you mentioned ATP and I agree, which is why to me it is troubling Signal instead of guarding metadata, actively collects it. Please let me know I have missed anything you'd like me to address. And I really would be interested in your thought on the question above in as much detail as you're able to share. Thanks!