End-to-end encrypted messages need more than libsignal

https://mjg59.dreamwidth.org/62598.html

by tpush • 4 years ago

218 102 4 years ago

mjg59.dreamwidth.org

djbusby3• 4 years ago

Can 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• 4 years ago

I 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• 4 years ago

Right 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• 4 years ago

thaumasiotes3• 4 years ago

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

klooney• 4 years ago

Also, Twitter is a great big centralized system- it seems like it ought to make public key distribution very easy and straightforward.

djbusby3• 4 years ago

Wasn't that what KeyBase was supposed to do?

tptacek18• 4 years ago

This is a blog post relating flaws the author found in systems that naively used libsignal. The "axe" to grind here is that libsignal can be misused.

thaumasiotes3• 4 years ago

The axe to grind here is that whatever the author mentions is, ipso facto, a flaw. I've highlighted an example where the author presents as unreasonable a choice to go with greater security over lesser security, and labels that choice a security issue. This is not a reasoned or reasonable decision on the part of the author. I'm going to generalize the quality of argument here, which is terrible, to whatever else the author says.

Want to make the argument that libsignal can be misused? First, go through all of your examples and make sure they actually show misuse.

javajosh• 4 years ago

A 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!

tptacek18• 4 years ago

See the recent Matrix fiasco for a more vivid example.

2Gkashmiri• 4 years ago

What?

TheCycoONE• 4 years ago

Can you link to whatever you're referring to?

Null-Set• 4 years ago

How 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

threeseed3• 4 years ago

Signal 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/

getcrunk• 4 years ago

What are people’s thoughts on dual licensing in this manner? Is it compatible with foss or no?

samwillis• 4 years ago

I believe they already have a license (it may have expired):

"agreement to license Signal protocol was reached"

https://mobile.twitter.com/bhcarpenter/status/15966919162503...

bsaul2• 4 years ago

IANAL but my understanding is that agpl requires you to publish server code if that code uses code under agpl, because consuming an api is equivalent to distributing the code.Aka that "calling an api which uses agpl code" is equivalent to using the code itself ( which means you should, as an api consumer, have access to the source eventhough you actually downloaded no binary).

e2e means server never does any encryption or decryption so i don't think they'll have any signal code running on their server.

They will however be required to open source their application code.

Edit : and i think open sourcing twitter app would be a stunning move, that elon is totally capable of.

mjg592• 4 years ago

There seems to be a bunch of code in the Twitter app that's licensed from other third parties, so unless they're fine with their code being re-licensed under AGPL it's not possible to release the app under those terms.

eadmund• 4 years ago

"calling an api which uses agpl code" is equivalent to using the code itself

No, not at all. If a server is AGPL-licensed, clients may have whatever license they want. If a client is AGPL-licensed, servers may have whatever license they want. What the AGPL does is provide that if code under the AGPL is used to provide network services, then clients of those servers are entitled to the server source code. You may read the terms here: https://www.gnu.org/licenses/agpl-3.0.en.html

There is no copyright mechanism by which the AGPL could apply to clients of an AGPL server.

Doorstep2077• 4 years ago

Encryption'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• 4 years ago

Why not simply use gpg?

tao_oat• 4 years ago

forward secrecy, for one: https://signal.org/blog/asynchronous-security/

aborsy• 4 years ago

You use hardware keys and don’t care about forward secrecy. Private key never leaks.

For offline file encryption ( pgp isn’t intended for messaging).

upofadown3• 4 years ago

Forward 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

walterbell2• 4 years ago

IETF MLS (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

Review of 2020 draft protocol, 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• 4 years ago

Notably, 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/ZJ4e78obXSdYWnxmsN...

https://github.com/mlswg/mls-architecture/issues/50

walterbell2• 4 years ago

While deniability would be welcome, the last few years have seen rumblings from various Australia/UK/US stakeholders about possible regulation for E2EE messenger intercept, i.e. even encryption would be compromised in that scenario. Hopefully the recent Apple announcement on E2EE iCloud means that regulators have seen the folly of mass interception.

If China (e.g. WeChat) is a predictor of future messaging systems, there may be convergence between messaging and payments. Musk has publicly suggested that Twitter follow in WeChat's footsteps as an "Everything App". If payments and messaging converge, and governments adopt CBDCs for digital legal tender, then we may be looking down the barrel of state-issued digital IDs for online and offline activity.

Linux Foundation is promoting blockchain for both software signing and globally interoperable travel/health credentials. Big tech companies each have their own island of semi-verified identities, depending on their proximity to financial services. It's not clear which groups are willing or able to effectively lobby for pseudonymous digital identity.

bentley• 4 years ago

reputability

The word you’re looking for is “repudiability.”

Although one might say that lacking repudiability could be enough for a messaging system to lack reputability ;)

dane-pgp• 4 years ago

a follow-up IETF project to use MLS for inter-messenger interoperability

It's worth highlighting (as a comment in the linked discussion does) that the EU's newly-passed Digital Markets Act requires interoperability between the messaging apps of large "gatekeeper" platforms.

If Twitter does end up supporting E2EE messaging, it may soon be forced to implement MLS, and if Facebook and Google are really supportive of MLS then soon(TM) most people online will be able to communicate via that technology.

JustSomeNobody• 4 years ago

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.

You have to put trust in the app (and the company that owns that app), though.

In twitter, I type a message in plain text. The twitter app encrypts it and sends it to the recipient. I am trusting Twitter to not encrypt it twice, once with my key and once with there's and capturing their copy in flight.

With current trends at Twitter, I wouldn't trust them an inch.

End-to-end encrypted messages need more than libsignal

Related Stories