12 ms·
End-to-end encrypted messages need more than libsignal
- NotYourLawyer 4y ago
- pcwalton 4y agoThe author wasn't stating whether the bulk of the cryptography community should be aligned with Musk's views. He's saying that they aren't. That's a descriptive statement, not a normative one. I'm not a member of the cryptography community, but the author is a prominent cryptographer [edit: not accurate; see below], and so right now I have every reason to believe that his statement is correct.
- tptacek 4y agoThe author isn't a prominent cryptographer, but he definitely knows a lot of them, and is a prominent security engineer and researcher.
- pcwalton 4y agoThanks for the correction.
- throwaway0x7E6 4y ago>He's saying that they aren't I would like a few examples of who are those people the author considers to be "members of the cryptography community". it's a pretty wild claim considering that we owe the current state of cryptography to 1A, and I assume most people involved in the field are aware of that.
- habinero 4y agoNeither Twitter nor Elon are bound by the 1A, so it's irrelevant. Also, why is the claim surprising? Elon has really only paid lip service to free speech, his actions have been all over the place.
- joshuamorton 4y agoSupporting the first amendment, and thinking Elon's changes to Twitter policy are bad are completely coherent beliefs. Any 1A lawyer will tell you that Twitter has never been bound by the first amendment.
- throwaway0x7E6 4y agoand ISPs are not prohibited by any law from blackholing encrypted traffic in the name of combatting CSAM and hate speech to make the internet safer and more inclusive for everyone would you be cool with it if they did that?
- joshuamorton 4y agoI think that does violate common carrier statues. But even if it didn't, such an ISP would immediately go out of business since like 90+% of web traffic is encrypted. But yeah like if an ISP did that, if be fine with that because multiple ISPs serve my area so I'd pick a different one. Insofar as there are people who only have access to one ISP, I think the common carrier statues apply. (And actually there are ISPs that advertise filtered dns resolvers for that apply even stricter content filtering, and I think that's fine. I just choose not to use those) But Twitter isn't a monopoly in any sense. It's one of the smaller social media sites, and even if you try to exclude Facebook from twitters niche, TikTok, truth.social, and others are similar enough. As has been clearly demonstrated by trump's choice to not return to Twitter.
- NotYourLawyer 4y agoCryptographers as a group are pretty pro-speech and anti-censorship.
- 3np 4y agoJust like not aligning with the views of Donald Trump means you are anti-freedom? /s
- klabb3 4y agoAnecdotal but I’m a stronger-than-most believer in free speech and I don’t think Musk is doing anything other than lip-service and a clever anchoring of free speech as a value that he, quite successfully, associated with himself. It’s textbook manipulative behavior, claim you strongly believe in something early, and then people won’t question it. If you pretend he never claimed to be pro-free speech, and make a judgment of his actions alone, does he feel like someone who genuinely strives towards free speech? He surely wants to be contrarian, but free speech is much more than edginess.
- djbusby 4y agoCan ActivityPub deliver E2E? I've read docs but don't have enough experience to fully grok. Do I still have to figure out key-sharing?
- LanternLight83 4y agoI don't think it's in the spec (because I don't see it implemented), but I also don't see any blocking issues regarding an extension to the spec to provide this (aside from the usual issues with "server-side" E2E and roaming/multi-device access)
- 9wzYQbTYsAIc 4y agoRight now you could PGP encrypt what you post and only share your key with your intended audience, but that would seem to defeat the purpose of publishing activities to the open web.
- franky47 4y agoRelated: https://soatok.blog/2022/11/22/towards-end-to-end-encryption-for-direct-messages-in-the-fediverse/ https://soatok.blog/2022/11/22/towards-end-to-end-encryption...
- thaumasiotes 4y agoSeems like the author has an axe to grind. > When you want to send a message to someone, you ask the server for one of their one-time prekeys and use that. Decrypting this message requires using the private half of the one-time prekey, and the recipient deletes it afterwards. This means that an attacker who intercepts a bunch of encrypted messages over the network and then later somehow obtains the long-term keys still won't be able to decrypt the messages, since they depended on keys that no longer exist. > Since these one-time prekeys are only supposed to be used once (it's in the name!) there's a risk that they can all be consumed before they're replenished. The spec regarding pre-keys says that servers should consider rate-limiting this, but the protocol also supports falling back to just not using one-time prekeys if they're exhausted (you lose the forward secrecy benefits, but it's still end-to-end encrypted). > This implementation not only implemented no rate-limiting, making it easy to exhaust the one-time prekeys, it then also failed to fall back to running without them. Another easy way to force DoS. You just described a security/convenience tradeoff in the use of prekeys. OK. Then, the app's choice to go with security over convenience is a security problem, because you're not allowed to send messages without forward secrecy. For greater security, the app should have allowed messages at a lower level of security. If you want to make the case that someone did the wrong thing, do it in a way where they wouldn't also have been wrong if they did the opposite of what you're complaining about.
- javajosh 4y agoA timely reminder of the non-cryptographic issues you must get right, in addition to the cryptographic ones, in order to build a robustly secured system!
- tptacek 4y agoSee the recent Matrix fiasco for a more vivid example.
- 2Gkashmiri 4y agoWhat?
- ttyprintk 4y agoAn complete break, at most academically: https://news.ycombinator.com/item?id=33009721 https://news.ycombinator.com/item?id=33009721
- TheCycoONE 4y agoCan you link to whatever you're referring to?
- iampivot 4y agoMaybe it's this? https://www.theregister.com/2022/09/28/matrix_encryption_flaws/ https://www.theregister.com/2022/09/28/matrix_encryption_fla...
- Null-Set 4y agoHow is twitter intending to use libsignal? I doubt it would be via the primary AGPL license[1], forcing them to publish the source code of their backend service. Does signal sell private licenses? [1] https://github.com/signalapp/libsignal/blob/main/LICENSE https://github.com/signalapp/libsignal/blob/main/LICENSE
- threeseed 4y agoSignal requires all contributors to license their work to the company [1] So they are able to offer Twitter a non-APGL license. Usually for a sizeable fee. [1] https://signal.org/cla/ https://signal.org/cla/
- getcrunk 4y agoWhat are people’s thoughts on dual licensing in this manner? Is it compatible with foss or no?
- icelancer 4y agoIt's not compatible with FOSS from a dogmatic point of view, but I think it's a pragmatic way forward given how AWS and other actors act. I dual license my company's products in this manner.
- sam_bristow 4y agoEven Stallman isn't completely opposed to selling exceptions to copyleft licences. https://www.fsf.org/blogs/rms/selling-exceptions https://www.fsf.org/blogs/rms/selling-exceptions
- icelancer 4y agoOh wow, I retract my statement then. I wasn't aware of this. I thought for sure RMS wouldn't approve.
- sparkie 4y ago
- Doorstep2077 4y agoEncryption's always hard to get right, so it honestly doesn't surprise me that libsignal isn't enough. Though I've never had good experience with libsignal
- dvh 4y agoWhy not simply use gpg?
- tao_oat 4y agoforward secrecy, for one: https://signal.org/blog/asynchronous-security/ https://signal.org/blog/asynchronous-security/
- aborsy 4y agoYou use hardware keys and don’t care about forward secrecy. Private key never leaks. For offline file encryption ( pgp isn’t intended for messaging).
- hiq 4y ago> You use hardware keys and don’t care about forward secrecy. Private key never leaks. I guess you mean "leak" as in "being copied", which relies on how good the hardware actually is at preventing this, but what if I just lose my hardware key, isn't that the same?
- upofadown 4y agoForward secrecy is somewhat overrated in end to end encrypted messaging. Most people do not want a truly off the record experience but instead keep their old messages around indefinitely. As long as those old messages exist and are accessible to the user they will be just as accessible to any attacker that gets access to the secret key material. The Signal Protocol somewhat excessively provides forward secrecy for each and every message sent. That is sort of pointless while the messages still exist on the screen. Most people would be happy getting rid of their old messages every week or so. You could totally do that in an instant messaging system that used OpenPGP formatted messages. The reason that no one bothers is because few people want to dump their old encrypted emails. No one wants to dump their old encrypted files. Instead they take advantage of the greater security inherent in an offline encryption system and avoid getting their keys leaked in the first place. If you really wanted to do message by message forward secrecy using a hash ratchet using OpenPGP formatted messages you could do that too. There is nothing magical about the Signal Protocol for stuff like that... Relevant discussion: * https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy
- walterbell 4y agoIETF MLS (https://datatracker.ietf.org/wg/mls/about/ https://datatracker.ietf.org/wg/mls/about/) was ratified in September 2022 by messenger service vendors (including Wire, Matrix, Mozilla, Cisco, Google, Facebook), who have been working for several years on an E2EE group messaging protocol to live alongside TLS. MLS is already deployed in production by Cisco WebEx. > Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. There is now a follow-up IETF project to use MLS for inter-messenger interoperability, with Matrix as an early participant, https://news.ycombinator.com/item?id=33420112 https://news.ycombinator.com/item?id=33420112 Review of 2020 draft protocol, https://liu.diva-portal.org/smash/get/diva2:1388449/FULLTEXT01.pdf https://liu.diva-portal.org/smash/get/diva2:1388449/FULLTEXT... > Work is now ongoing to introduce the Messaging Layer Security (MLS) protocol as an efficient standard with high security guarantees for messaging in big groups. This thesis examines whether current MLS implementations live up to the promised performance properties and compares them to the popular Signal protocol. In general the performance results of MLS are promising and in line with expectations, providing improved performance compared to the Signal protocol as group sizes increase.
- saurik 4y agoNotably, this design lacks reputability, which for some reason they didn't even want (as it might be used by "terrorists"), which led to arguments with Ian Goldberg, the developer of Off-the-Record messaging. The arguments on the big tracker about power imbalances were maybe a bit better, but I still personally disagree. https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsNUqGc_qe68/ https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsN... https://github.com/mlswg/mls-architecture/issues/50 https://github.com/mlswg/mls-architecture/issues/50
- 4y ago