3 ms·

Again, that whole point of end-to-end encryption that allows it to eliminate the need to trust the vendor only works if the vendor isn't the one supplying said

Again, that whole point of end-to-end encryption that allows it to eliminate the need to trust the vendor only works if the vendor isn't the one supplying said end-to-end encryption. Please don't make arguments that "Signal does this or that you can trust them", you do not eliminate the need to trust them this way at all. If you do have to trust them not to spy on you, it's not a proper "end-to-end" encryption, simple as that, it's effectively the same thing as a regular TLS encryption to the servers, where you have to trust them not to spy on you on the servers. And in either case that trust will be eventually violated, because there is no incentive not to, but plenty of pressure and incentives to violate it. I don't know what's so confusing about it. You like Signal and trust them, that's fine, but I don't trust them or anything coming from the US, I really would like to eliminate such trust. Claiming that I don't have to trust them is unproductive and a lie.

maqp 7y ago
>Again, that whole point of end-to-end encryption that allows it to eliminate the need to trust the vendor only works if the vendor isn't the one supplying said end-to-end encryption. That doesn't make any sense whatsoever. Vendor supplies the E2EE, users and experts review it, and then if it changes, review changes. Third parties can trivially make edits to their forks and that's the easiest backdoor possible. How can you not see that. >Please don't make arguments that "Signal does this or that you can trust them", you do not eliminate the need to trust them this way at all. I already explained there are technical measures in place that allow you to verify the build you're using yourself. You're clearly not a subject matter expert here so I suggest you move on. > If you do have to trust them not to spy on you, it's not a proper "end-to-end" encryption, simple as that You're arguing from the wrong premise. You don't have to trust them. >it's effectively the same thing as a regular TLS encryption to the servers, where you have to trust them not to spy on you on the servers. if Signal was doing an active MITM attack against their own encryption, that would be eavesdropping which is a felony in the US. >And in either case that trust will be eventually violated, because there is no incentive not to, but plenty of pressure and incentives to violate it. And somehow random repository maintainers are immune to pressure and incentives. I get it, you're trolling. >I don't know what's so confusing about it. If you really stretch those brain cells of yours you might understand it one day. >You like Signal and trust them, that's fine, but I don't trust them or anything coming from the US, I really would like to eliminate such trust. Again, you don't have to trust Signal. >Claiming that I don't have to trust them is unproductive and a lie. So you ignore the concept of reproducible builds and just establish an opinion with average-joe level reasoning. I won't waste my time further.
- zzzcpan 7y ago
  > there are technical measures in place that allow you to verify the build you're using yourself. There are no technical measures for Signal in place that allow anyone to verify the build all ends of said end-to-end encryption are running nor any technical measures to ensure the software they are running won't be updated with compromised end-to-end encryption by the vendor in the future. The measures I talk about address both points by removing trust from the vendor and distributing it across many independent entities. > if Signal was doing an active MITM attack against their own encryption, that would be eavesdropping which is a felony in the US. It's not just legal anywhere in the world, it's what a lot of software already does. Anyway, if end-to-end encryption requires the exact same level of trust as TLS, there is no point in it. It's only useful in truly open source messengers, not Signal, Whatsapp or other binary blob centralizedly controlled messengers.
  - maqp 7y ago
    >There are no technical measures for Signal in place that allow anyone to verify the build all ends of said end-to-end encryption There is no technical measure in existence that allows that for any application. This is called a nirvana fallacy. > nor any technical measures to ensure the software they are running won't be updated with compromised end-to-end encryption by the vendor in the future. That applies to all software that requires automatic software updates, i.e. networked TCBs. You want something that doesn't require updating, you use stronger model like TFC. >The measures I talk about address both points by removing trust from the vendor and distributing it across many independent entities. And users are going to compare diffs of multiple vendors for every update to see nothing malicious was added? Give me a break. >It's not just legal anywhere in the world, it's what a lot of software already does. Extraordinary claims require extraordinary proofs. >Anyway, if end-to-end encryption requires the exact same level of trust as TLS, there is no point in it. And this is the general whataboutism propaganda I run into all the time. "There is no perfect E2EE model, therefore using it doesn't matter". Forward secrecy and risk of legal trouble are two perfectly valid reasons to use just opportunistic E2EE, even if you don't authenticate the keys. May the rest of the community credit your "ideas" with the silence they deserve.

maqp 7y ago

>Again, that whole point of end-to-end encryption that allows it to eliminate the need to trust the vendor only works if the vendor isn't the one supplying said end-to-end encryption. That doesn't make any sense whatsoever. Vendor supplies the E2EE, users and experts review it, and then if it changes, review changes. Third parties can trivially make edits to their forks and that's the easiest backdoor possible. How can you not see that. >Please don't make arguments that "Signal does this or that you can trust them", you do not eliminate the need to trust them this way at all. I already explained there are technical measures in place that allow you to verify the build you're using yourself. You're clearly not a subject matter expert here so I suggest you move on. > If you do have to trust them not to spy on you, it's not a proper "end-to-end" encryption, simple as that You're arguing from the wrong premise. You don't have to trust them. >it's effectively the same thing as a regular TLS encryption to the servers, where you have to trust them not to spy on you on the servers. if Signal was doing an active MITM attack against their own encryption, that would be eavesdropping which is a felony in the US. >And in either case that trust will be eventually violated, because there is no incentive not to, but plenty of pressure and incentives to violate it. And somehow random repository maintainers are immune to pressure and incentives. I get it, you're trolling. >I don't know what's so confusing about it. If you really stretch those brain cells of yours you might understand it one day. >You like Signal and trust them, that's fine, but I don't trust them or anything coming from the US, I really would like to eliminate such trust. Again, you don't have to trust Signal. >Claiming that I don't have to trust them is unproductive and a lie. So you ignore the concept of reproducible builds and just establish an opinion with average-joe level reasoning. I won't waste my time further.

zzzcpan 7y ago
> there are technical measures in place that allow you to verify the build you're using yourself. There are no technical measures for Signal in place that allow anyone to verify the build all ends of said end-to-end encryption are running nor any technical measures to ensure the software they are running won't be updated with compromised end-to-end encryption by the vendor in the future. The measures I talk about address both points by removing trust from the vendor and distributing it across many independent entities. > if Signal was doing an active MITM attack against their own encryption, that would be eavesdropping which is a felony in the US. It's not just legal anywhere in the world, it's what a lot of software already does. Anyway, if end-to-end encryption requires the exact same level of trust as TLS, there is no point in it. It's only useful in truly open source messengers, not Signal, Whatsapp or other binary blob centralizedly controlled messengers.
- maqp 7y ago
  >There are no technical measures for Signal in place that allow anyone to verify the build all ends of said end-to-end encryption There is no technical measure in existence that allows that for any application. This is called a nirvana fallacy. > nor any technical measures to ensure the software they are running won't be updated with compromised end-to-end encryption by the vendor in the future. That applies to all software that requires automatic software updates, i.e. networked TCBs. You want something that doesn't require updating, you use stronger model like TFC. >The measures I talk about address both points by removing trust from the vendor and distributing it across many independent entities. And users are going to compare diffs of multiple vendors for every update to see nothing malicious was added? Give me a break. >It's not just legal anywhere in the world, it's what a lot of software already does. Extraordinary claims require extraordinary proofs. >Anyway, if end-to-end encryption requires the exact same level of trust as TLS, there is no point in it. And this is the general whataboutism propaganda I run into all the time. "There is no perfect E2EE model, therefore using it doesn't matter". Forward secrecy and risk of legal trouble are two perfectly valid reasons to use just opportunistic E2EE, even if you don't authenticate the keys. May the rest of the community credit your "ideas" with the silence they deserve.