3 ms·
I'm one of the authors of this piece and I'd like to make clear that it responds mainly to specific suggestions that end-to-end encrypted chat tools could be mo
by schoen 8y ago
I'm one of the authors of this piece and I'd like to make clear that it responds mainly to specific suggestions that end-to-end encrypted chat tools could be modified in very small ways, without impacting the overall communications protocol or requiring the tools to be substantially redesigned.
Since these tools are not in general obfuscated to hide their activities from the users and don't perform extra work to conceal things like how many recipients there are for each message or session, there are lots of possible avenues for noticing anomalies.
We aren't arguing that there is no way to create communications tools that prevent users from detecting if their communications are being intercepted. Instead, we're arguing that those tools wouldn't be simple, straightforward variants on existing end-to-end encrypted messaging systems.
- gweinberg 8y agoI'm not reckless enough to roll my own crypto system, but I know how to defeat at least some of these attacks: always do the work for sending messages to a ghost, even if there is none. That is, when the Cheka isn't actually eavesdropping, just send garbage data to a garbage channel.
- mimi89999 8y agoHow could you prevent users installing their own TLS certificates, changing the ones in the binaries or patching the TLS library form inspecting the data and detecting that a ghost user joined or that the number of keys increased? Also, I think that this is a really bad approach as anybody who manages to compromise the server can add a ghost user. This is a step backwards as E2E won't protect against active attacks anymore.