7 ms·
Global Encryption Day: Demand End-to-End Encryption in DMs
- deleted 4y ago[deleted]
- pabs3 4y agoKind of meaningless if you can't trust the software running on your device though, since it could be scanning locally or relaying to remote services.
- fsflover 4y agoSo run free software?
- sschueller 4y agoLike signal that still refuses to put their client on fdroid?
- edf13 4y agoAre you confident enough to audit the free software yourself - or pushing the trust back to someone else?
- mindslight 4y agoOur modern society couldn't exist without some trust, but there are huge differences in types of trust and the trustee's underlying motivations. Trusting the community to audit is like trusting the scientific method. Anyone can find and point out a flaw, which can then be verified by everyone. That's an idyllic description, and the process is quite imperfect, but it's the best we've got. Meanwhile, trusting a surveillance company to self police is like trusting a quack medicine healer.
- threeseed 4y agoEvery free software will have dozens or even hundreds of transitive dependencies. It literally isn't possible for an ordinary person to audit all code. At some point you have to blindly trust.
- fsflover 4y agoThere us a huge difference between you alone trusting a piece of software and the whole community verifying it at random.
- pabs3 4y agoIt isn't enough to run free software, all your contacts need to do that as well. It is the old gmail problem highlighted by Mako Hill: https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours https://mako.cc/copyrighteous/google-has-most-of-my-email-be...
- fsflover 4y agoYou are right: You also need to promote free software among your friends and help it to improve.
- einpoklum 4y agoExactly. Demand an open source for every encryption app - or at least those offered to the public en masse. It's not enough that a FOSS alternative _exists_; it needs to be the case that closed-source encryption is not considered as an actual encryption "end".
- jstanley 4y agoThis is an instance of the trope "if you can't solve everything, you shouldn't solve anything". It is fallacious because you'll never get there if you're not allowed to make incremental advances.
- jv0010 4y agoIt's mind blowing e2e is not a standard. I guess the equivalent is looking back and realising cars and homes did not have locks at one stage
- sebzim4500 4y agoGiven how everyone uses TLS nowadays, a better analogy would be for the dealership to retain a copy of the key to your car after you buy it. Which would probably upset people but isn't as bad as having no lock at all.
- Linosaurus 4y agoThe analogy breaks down a little here. We don’t want the dealership to keep the key, but we do want them to give us a new one if we lose it. So afaik we trust the manufacturer to keep the info, and to keep sufficient logs that anyone that abuses it to steal cars can be caught. I don’t think the way this is works can be extended to communications apps though.
- 100001_100011 4y agoHow do you know if the Signal client running on your phone right now doesn't include a backdoor? Sure it's open source. But how do you know how it was compiled? What if someone changed the open source before shipping it to the app store?
- i_am_proteus 4y agoHow do you know that the AES instruction set on your device's processor doesn't include a backdoor? Sure, the algorithm is public, but how do you know how it was implemented?
- upofadown 4y agoAES starts with 16 bytes and then encrypts it to 16 bytes. So there is no good place to hide extra data. Even a single bit that did not meet the AES spec for the key in use would produce complete garbage at decryption. So attempts to leak the key would at least leave a mark.
- dividuum 4y agoUnless it’s a timing based leak..
- bertman 4y agoThis is called "Reproducible Builds". https://signal.org/blog/reproducible-android/ https://signal.org/blog/reproducible-android/
- 100001_100011 4y agoReproducible builds are for developers. As a user I didn't build the app on my phone. I have a phone with Signal on it. Tell me what I should do to verify it's running the open source Signal code.
- bertman 4y ago
- mr_mitm 4y agoRemember when Zoom claimed that meetings were E2EE yet you could join the meeting by phone and no one batted an eye for at least one or two years? Noticed how no regular person cares when the "security code" of a chat partner changes in WhatsApp or Signal? Not to mention no regular person uses self-compiled apps for that, even if it were possible. E2EE is close to becoming a cargo cult, because done properly key management and identity verification are a usability nightmare. It will always remain a toy for a niche audience. Most people just don't care, and the non-technical people that do care are happy with a green lock appearing somewhere. I do hope to be proven wrong, though.
- twstdzppr 4y agoSo what you're saying is, we can just put a green lock in the UI and call it a day.
- rini17 4y agoWe can put some thought into how to set up the third parties to be trusted with our keys. Curretly it's very haphazard. And it's not avoidable. Even Phil Zimmerman, inventor of PGP, won't accept PGP encrypted mail because he claims to have lost his private key. The outrage "own your private keys or bust!" is much easier tho.
- sleepless 4y agoDo you happen to know which OS Phil was using, when he lost his private key and what the exact circumstances were? This is a nice story to be told, but without details it is not worth that much.
- rini17 4y agoWhy does it matter? Private keys are being compromised or lost under all kinds of circumstances and regardless of the OS.
- twstdzppr 4y ago
- threeseed 4y agoWhich is why many of us are firmly against RCS. End to end encryption is critically important and no messaging standard should exist that doesn't include it.
- fgiox 4y agoRCS does include end-to-end encryption though. https://support.google.com/messages/answer/10262381 https://support.google.com/messages/answer/10262381
- sneak 4y agoNo, it does not. Google’s proprietary implementation implements Google’s proprietary encryption system. RCS does not.
- fgiox 4y agoWhile this is currently only in Google's and Samsung's Messages apps, it's basically just the Signal protocol implemented as an RCS extension. It will most likely end up formalised in the next standard release of RCS.
- threeseed 4y ago> It will most likely end up formalised in the next standard release of RCS Based on what evidence. If it hasn't been added after all these years it doesn't seem likely it will be added soon.
- CJefferson 4y agoAs I understand it, if we had true end-to-end encryption, I would have to make sure I kept a set of keys, copied them between every computer and phone I used for chatting, and if I lost those keys I'd lose all my messages? Honestly, for most people I don't think that's functionality they would want, at least without us getting much better at interfaces and usability. Standard ways of storing keys, for example in a password manager, would be a good start (does this already exist and I've missed it?)
- mr_mitm 4y ago> As I understand it, if we had true end-to-end encryption, I would have to make sure I kept a set of keys, copied them between every computer and phone I used for chatting, and if I lost those keys I'd lose all my messages? Unless you made an unencrypted backup, then yes, that's true and that is the reason why Telegram decided against E2EE by default. According to them their users prefer easy cloud access to their messages over security.
- iggldiggl 4y ago> According to them their users prefer easy cloud access to their messages over security. And likewise with e-mail, PGP et al. break some features that rely on your mail server having access to the full message contents, like content-based message filtering (spam or otherwise) and server-side search.
- rmnclmnt 4y agoUsing a password manager in a sensible manner already goes a long way! Most synchronized E2EE services only ask for a master passphrase to encrypt your keys before storing them server side (e.g Bitwarden, Keybase, ProtonMail). Then you only need your password manager to recall the passphrase when synchronizing a new device! People need to learn again how the devices in their pocket work and the risks for not doing things properly!
- sigwinch28 4y ago> and if I lost those keys I'd lose all my messages? Only if the developers of the software insist on encryption at rest in addition to transit encryption. For example, you don’t lose the ability to open files you have already downloaded via HTTPS just because the client or server certificate later expires.
- anthk 4y agoMail and GPG. For IM's, tox. Or Jabber+Omemo.
- Ptchd 4y agoBriar Project appear to be a good E2EE messaging app. https://briarproject.org/how-it-works/ https://briarproject.org/how-it-works/
- LinuxBender 4y agoWhat I find intriguing is that E2EE was significantly more common long ago than it is today. Multi-protocol chat clients would utilize the OTR libraries meaning 'off the record' and even auto-negotiate with folks over AIM, MSN, ICQ, IRC and others to assist in showing fingerprints and sharing public keys which could be done over the platform or out of band if one so wished. I would have expected that by today that not only would this be more common but that the technology would have significantly advanced by now. Instead the opposite appears to be true. People are instead using apps that pinky promise to E2EE things and depend on the chat service to handle the trust mechanism for them which in my view entirely defeats the intent and purpose of E2EE. I assume the motivation is the desire to capture and monetize every conversation, especially the private conversations and/or to comply with national security letters. I've heard people try to rationalize this with because non technical people but non technical people were utilizing OTR just fine. What could realistically be done to reverse this in a way that puts the control back into the individuals hands? i.e. Even if all the kings horses and all the kings men wanted your messages they could only pound sand again and again.
- jll29 4y agoThis may be due to policy activism on the side of governments. I think asking service providers to use more E2EE is not the right approach. Governments' intelligence agencies do not shy away from infiltrating commercial vendors (from Yahoo! to the infamous Crypto AG - https://en.wikipedia.org/wiki/Crypto_AG https://en.wikipedia.org/wiki/Crypto_AG). 1. People should diversify across many, in particular smaller platform, so that surveillance cannot be done as it becomes a scale & long tail problem. 2. People should use P2P E2EE protocols and GPG-encrypted emails. The single biggest step forward would be easier ways to set up public key encrypted email part of e.g. Mozilla Thunderbird and other clients. But in parallel an attitude change is needed, for the receiving end needs to know how to open an encrypted email.
- georgyo 4y agoI used OTR, but I would not say that it was _more_ common, as that was just a layer over a non E2EE platform like the ones you listed. Using OTR meant using a non-standard client, installing the plugins for it, and configuring it. Worse, all parties you wanted to chat with had to do it as well. Which means it was almost always a novelty feature among nerdy friends and no one else. Because most people did not have it installed, having it auto negotiate always was a non-starter. It meant people who didn't have it would recieve cryptic messages from you at the start of each session and then complain to you. So most of the time it was completely manual process of enabling it for _some_ chats, and this leaks a massive amount of data. It basically declares that for this particular chat sometime might have been interesting. Often the chat log would include a plain text message like "Let's switch to OTR". Unlike you I could not get any non-technical friends to care about OTR enough to install it. I have difficulty even today getting people interested in Signal. I still hear arguments like "I'm not that interesting, they can look" and "I've got nothing to hide"