6 ms·

It sounds reasonable? If anything this highlights the problem with all the new encrypted communications options, even highly technical people can't really know

by jpgvm 11y ago

It sounds reasonable? If anything this highlights the problem with all the new encrypted communications options, even highly technical people can't really know how good it is from a cursory look. Just because it says end to end encryption and uses some nice ciphers it doesn't mean the implementation is not critically flawed. I use Signal right now (from Moxie Marlinspike/Whisper Systems) and would only really consider alternatives if they were endorsed by other cryptographers I know because I really just don't have a strong enough grasp of how all the machinery interacts.

treenyc 11y ago
It is great that Whisper Systems/Signal implement cryptography properly. However, the NEWER versions of Signal requires access to your contact to work. For many users that is a show stopper. Implement a way for user to search by User ID and allow user to find each other by ID in addition to phone number.
- Tepix 11y ago
  Not on iOS. It's not Signal's fault that Android permissions are a mess. Google has no interest in providing good privacy to their customers. They only want to appear to provide privacy. In reality, they want to know everything there is to know about everything and everyone. To improve their service, of course...
  - lelf 11y ago
    > Not on iOS Tried just now. It does require it and doesn't work without it. Sorry! Signal requires access to your contacts. We do not store your contacts on our servers. [Give access]
- Freak_NL 11y ago
  The requirement of a phone number is strange and disconcerting from a privacy standpoint. It is a red flag for me. A well-designed encrypted chat-protocol should work on any modern networked computing device, not just smartphones or computing devices linked to a smartphone.
- brbsix 11y ago
  Recent updates also show disconcerting "Joe is on Signal!" messages for everyone in your contacts (who is registered with Signal) regardless of whether or not you've had any contact with them. They've stated that this is not a security issue (I don't recall the specifics) but it was pretty disturbing nonetheless. I'll definitely be paying closer attention and consider switching to an alternative if this trend continues.
  - asddubs 11y ago
    Why specifically are you worried about that?
    - brbsix 11y ago
      I've recommended Signal (then TextSecure) to a number of non-technically savvy friends as a trustworthy app that takes security seriously. Moxie is somewhat unique in this respect, among the sea of proprietary apps put out by larger shops. Upon seeing these "X is on Signal" messages, I had a number of people contacting me with concerns. At least the outward appearance is that Signal is somehow leaking contact data to their servers. Presumably it is also alerting people to the fact that "Joe" is a Signal user, despite no communication with that user having taken place. I realize that phone numbers are probably hashed before being sent, with only local contact data being displayed, but it has people concerned nonetheless. It starts to err more towards convenience, ease of use, and network building above security.
      - cyphar 11y ago
        I think we should push for Axolotl (the cryptosystem used by Signal, which is an improvement on OTR) support in Ricochet and get a Ricochet phone app. Ricochet uses Tor hidden services to anonymise your social graph, which is something you don't do with Signal (not to mention that Signal does identity key lookups with phone numbers). I'm not sure there's a low-latency way to do VOIP anonymously. The best method I know of is to literally record and send audio files, which have a few seconds of latency.
      - asddubs 11y ago
jimktrains2 11y ago
While you can't know without looking at the code, my first-pass test is asking how keys are handled and if the code handling those keys is coming from an untrusted source (in this case the server as JS)(for the sake of this discussion I will admit I implicitly trust Debian and the gpg folks). If there isn't a good answer to key management, or my key is handled by JS, then it's a no-go for me. If there is a half-way decent answer to key management, I ask what the threat vectors the system was designed for are. If a broad political statement is made, then I walk away. While it doesn't actually vet the technical merit of the code, I feel it catches a lot of funniness.
- biokoda 11y ago
  Probably the best key handling method is employed by Biocoded app. It uses the same encryption protocol as signal (Axolotl ratchet) and it only stores half of the decryption key locally. The other half is on the server.
- pdkl95 11y ago
  > a good answer to key management The problem with key management is that everyone tries to solve the management problem with a single solution. A single method will always have to make choices about the threat model, which can only truly be known by the user. A single user can even have more than one threat model, depending on what they are doing. What we need instead is some sort of configurable layer that allows the user to specify how keys should be managed by selecting what they want to trust. They could use a default delegation to a public trust root (the PKI model, no configuration needed) for most things. Receiving a call from the bank could instead be authenticated with the key they got when they physically walked into the local branch. Chat with their immediate friends who can exchange keys on their phone when they meet up in person is easy, and a web of trust can extend that to a friend-of-a-friend. People understand the concept of vouching for someone, and over time more than one method can be used to cross-check. Key management shouldn't be "PKI vs web-of-trust vs out-of-band-keybase-style vs manual-key-exchange vs ..."; it should be "all of the above, with the chain-of-trust exposed". Anything else is making assumptions about what the user's current needs.
pointernil 11y ago
Is there any information on the guaranties Moxie Marlinspike/Whisper Systems provide on the Apps downloaded from the App-Store? I get that their source is open and reviewed and trusted but what is this worth when there is no way to tell if users are actually using their version/builds when installed from App-Stores. Same holds true for the necessary servers they maintain. Don't get this wrong please: this is still probably THE best solution right now, which simply as well has its security limitations, right? Is there any work ongoing on a kind of "verification process" for Apps like these? How can an end-user tell if the binaries running on their device are untempered with? /sorry for hijacking ;)
- hannob 11y ago
  The solution is called reproducible builds. I'm aware f-droid is working on these, but most of the work is currently happening more in the Linux distribution space (Debian is leading that cause). I hope in the future we will be able to say "if it doesn't have a reproducible build process it's not to be considered trustworthy". (Also: I think this question is mostly independent from the disagreements between moxie and f-droid - they were regarding other issues.)
  - alkonaut 11y ago
    Aren't builds typically reproducible? What makes builds non-reproducible? I know the Debian folks are very enthusiastic about reproducible builds, and for a huge system I can see that things can vary -- but what tends to be varying in the case of individual components? If I build a library from the same revision of a source tree I expect the exact bits to come out, if the same compiler version was used? When does it not? Is it a problem with C/C++ in particular, where toolchains are complex? Or would non-reproducible also be a problem e.g for a Java library? Googling reproducible builds mainly gets you Debian info, not a general description of the issue
    - sandworm101 11y ago
      A build is not reproducible where it incorporates both open and closed code. A company may "open source" some important stuff (encryption algorithms) but keep enough code closed that the final build cannot be duplicated from the "open" code. It is therefore difficult to judge whether the open code has actually been adopted properly, or whether any closed code hasn't created new bugs.

by jpgvm 11y ago

treenyc 11y ago

It is great that Whisper Systems/Signal implement cryptography properly. However, the NEWER versions of Signal requires access to your contact to work. For many users that is a show stopper. Implement a way for user to search by User ID and allow user to find each other by ID in addition to phone number.

Tepix 11y ago
Not on iOS. It's not Signal's fault that Android permissions are a mess. Google has no interest in providing good privacy to their customers. They only want to appear to provide privacy. In reality, they want to know everything there is to know about everything and everyone. To improve their service, of course...
- lelf 11y ago
  > Not on iOS Tried just now. It does require it and doesn't work without it. Sorry! Signal requires access to your contacts. We do not store your contacts on our servers. [Give access]
Freak_NL 11y ago
The requirement of a phone number is strange and disconcerting from a privacy standpoint. It is a red flag for me. A well-designed encrypted chat-protocol should work on any modern networked computing device, not just smartphones or computing devices linked to a smartphone.
brbsix 11y ago
Recent updates also show disconcerting "Joe is on Signal!" messages for everyone in your contacts (who is registered with Signal) regardless of whether or not you've had any contact with them. They've stated that this is not a security issue (I don't recall the specifics) but it was pretty disturbing nonetheless. I'll definitely be paying closer attention and consider switching to an alternative if this trend continues.
- asddubs 11y ago
  Why specifically are you worried about that?
  - brbsix 11y ago
    I've recommended Signal (then TextSecure) to a number of non-technically savvy friends as a trustworthy app that takes security seriously. Moxie is somewhat unique in this respect, among the sea of proprietary apps put out by larger shops. Upon seeing these "X is on Signal" messages, I had a number of people contacting me with concerns. At least the outward appearance is that Signal is somehow leaking contact data to their servers. Presumably it is also alerting people to the fact that "Joe" is a Signal user, despite no communication with that user having taken place. I realize that phone numbers are probably hashed before being sent, with only local contact data being displayed, but it has people concerned nonetheless. It starts to err more towards convenience, ease of use, and network building above security.
    - cyphar 11y ago
      I think we should push for Axolotl (the cryptosystem used by Signal, which is an improvement on OTR) support in Ricochet and get a Ricochet phone app. Ricochet uses Tor hidden services to anonymise your social graph, which is something you don't do with Signal (not to mention that Signal does identity key lookups with phone numbers). I'm not sure there's a low-latency way to do VOIP anonymously. The best method I know of is to literally record and send audio files, which have a few seconds of latency.
    - asddubs 11y ago

jimktrains2 11y ago

While you can't know without looking at the code, my first-pass test is asking how keys are handled and if the code handling those keys is coming from an untrusted source (in this case the server as JS)(for the sake of this discussion I will admit I implicitly trust Debian and the gpg folks). If there isn't a good answer to key management, or my key is handled by JS, then it's a no-go for me. If there is a half-way decent answer to key management, I ask what the threat vectors the system was designed for are. If a broad political statement is made, then I walk away. While it doesn't actually vet the technical merit of the code, I feel it catches a lot of funniness.

biokoda 11y ago
Probably the best key handling method is employed by Biocoded app. It uses the same encryption protocol as signal (Axolotl ratchet) and it only stores half of the decryption key locally. The other half is on the server.
pdkl95 11y ago
> a good answer to key management The problem with key management is that everyone tries to solve the management problem with a single solution. A single method will always have to make choices about the threat model, which can only truly be known by the user. A single user can even have more than one threat model, depending on what they are doing. What we need instead is some sort of configurable layer that allows the user to specify how keys should be managed by selecting what they want to trust. They could use a default delegation to a public trust root (the PKI model, no configuration needed) for most things. Receiving a call from the bank could instead be authenticated with the key they got when they physically walked into the local branch. Chat with their immediate friends who can exchange keys on their phone when they meet up in person is easy, and a web of trust can extend that to a friend-of-a-friend. People understand the concept of vouching for someone, and over time more than one method can be used to cross-check. Key management shouldn't be "PKI vs web-of-trust vs out-of-band-keybase-style vs manual-key-exchange vs ..."; it should be "all of the above, with the chain-of-trust exposed". Anything else is making assumptions about what the user's current needs.

pointernil 11y ago

Is there any information on the guaranties Moxie Marlinspike/Whisper Systems provide on the Apps downloaded from the App-Store? I get that their source is open and reviewed and trusted but what is this worth when there is no way to tell if users are actually using their version/builds when installed from App-Stores. Same holds true for the necessary servers they maintain. Don't get this wrong please: this is still probably THE best solution right now, which simply as well has its security limitations, right? Is there any work ongoing on a kind of "verification process" for Apps like these? How can an end-user tell if the binaries running on their device are untempered with? /sorry for hijacking ;)

hannob 11y ago
The solution is called reproducible builds. I'm aware f-droid is working on these, but most of the work is currently happening more in the Linux distribution space (Debian is leading that cause). I hope in the future we will be able to say "if it doesn't have a reproducible build process it's not to be considered trustworthy". (Also: I think this question is mostly independent from the disagreements between moxie and f-droid - they were regarding other issues.)
- alkonaut 11y ago
  Aren't builds typically reproducible? What makes builds non-reproducible? I know the Debian folks are very enthusiastic about reproducible builds, and for a huge system I can see that things can vary -- but what tends to be varying in the case of individual components? If I build a library from the same revision of a source tree I expect the exact bits to come out, if the same compiler version was used? When does it not? Is it a problem with C/C++ in particular, where toolchains are complex? Or would non-reproducible also be a problem e.g for a Java library? Googling reproducible builds mainly gets you Debian info, not a general description of the issue
  - sandworm101 11y ago
    A build is not reproducible where it incorporates both open and closed code. A company may "open source" some important stuff (encryption algorithms) but keep enough code closed that the final build cannot be duplicated from the "open" code. It is therefore difficult to judge whether the open code has actually been adopted properly, or whether any closed code hasn't created new bugs.