Live data from Hacker News

MEGAChat now includes end-to-end encryption

mega.nz

21–30 of 98 posts

Re: MEGAChat now includes end-to-end encryption

#21
post #16
post #8

Earlier quoted context omitted.

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.

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...

> 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]

Re: MEGAChat now includes end-to-end encryption

#23
post #14

Earlier quoted context omitted.

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 pr…

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…

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

Re: MEGAChat now includes end-to-end encryption

#24
post #4

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 conside…

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 d…

> 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.

Re: MEGAChat now includes end-to-end encryption

#25
post #14

Earlier quoted context omitted.

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…

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…

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.

Re: MEGAChat now includes end-to-end encryption

#26
post #4

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 conside…

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 pr…

You can always compile the programs yourself - you will have to pay for a dev account for iPhone (I think) but Android is free and you can sideload the new app you trust.

Re: MEGAChat now includes end-to-end encryption

#27
post #14

Earlier quoted context omitted.

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 pr…

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…

Reproducible builds are on our very-near-future roadmap at Cyph, which will be important to mitigate a hypothetical scenario in which we somehow lose our minds and deploy code that differs from the GitHub repo.

We control the whole packaging/signing framework (WebSign), so there isn't any need for us to wait on a third party to roll this out.

Re: MEGAChat now includes end-to-end encryption

#28
Since no one else has explicitly brought this up: https://tonyarcieri.com/whats-wrong-with-webcrypto (also see Matasano's "JavaScript Cryptography Considered Harmful", etc.). There is nothing that a service like this will protect you from that you don't already get while using TLS in just about every insecure/non-E2EE chat service.

If you're looking for actually secure communication that runs as a Web app, my startup Cyph (cyph.com) is the only option that exists. This is because we put in the time to build it correctly; the root page of our application is a permanently pinned (TOFU) bootstrap that validates/executes signed application packages, and the scheme to accomplish this was rigorously vetted in a 12-day audit.

Edits:

* Here's how it works: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...

* Here's Cure53's audit report: http://cyph.team/cure53report

Re: MEGAChat now includes end-to-end encryption

#29
post #28

Since no one else has explicitly brought this up: https://tonyarcieri.com/whats-wrong-with-webcrypto (also see Matasano's "JavaScript Cryptography Considered Harmful", etc.). There is nothing that a service like this will protect you from that you don't already get while using TLS in just about every insecure/non-E2EE chat service. If you're looking for actually secure communication that runs as a Web app, my startup…

> the scheme to accomplish this was rigorously vetted in a 12-day audit.

Vetted by whom? It would help build trust if there was a public report on the strength of your implementation available somewhere.

Re: MEGAChat now includes end-to-end encryption

#30
post #14

Earlier quoted context omitted.

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…

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…

No builds are not easy to reproduce bit by bit as there are much more factors as the actual source.

For example:

  - compiler version used
  - date / timestamps at the time of compile
  - build id's
A good article on this can be found here: https://blogs.kde.org/2013/06/19/really-source-code-software
Post reply on HN