diff options
Diffstat (limited to 'web/blog/posts/the-smu-problem.md')
| -rw-r--r-- | web/blog/posts/the-smu-problem.md | 151 |
1 files changed, 0 insertions, 151 deletions
diff --git a/web/blog/posts/the-smu-problem.md b/web/blog/posts/the-smu-problem.md deleted file mode 100644 index f411e31160..0000000000 --- a/web/blog/posts/the-smu-problem.md +++ /dev/null @@ -1,151 +0,0 @@ -After having tested countless messaging apps over the years, being -unsatisfied with most of them and finally getting stuck with -[Telegram](https://telegram.org/) I have developed a little theory about -messaging apps. - -SMU stands for *Security*, *Multi-Device* and *Usability*. Quite like -the [CAP-theorem](https://en.wikipedia.org/wiki/CAP_theorem) I believe -that you can - using current models - only solve two out of three things -on this list. Let me elaborate what I mean by the individual points: - -**Security**: This is mainly about encryption of messages, not so much -about hiding identities to third-parties. Commonly some kind of -asymmetric encryption scheme. Verification of keys used must be possible -for the user. - -**Multi-Device**: Messaging-app clients for multiple devices, with -devices being linked to the same identifier, receiving the same messages -and being independent of each other. A nice bonus is also an open -protocol (like Telegram\'s) that would let people write new clients. - -**Usability**: Usability is a bit of a broad term, but what I mean by it -here is handling contacts and identities. It should be easy to create -accounts, give contact information to people and have everything just -work in a somewhat automated fashion. - -Some categorisation of popular messaging apps: - -**SU**: Threema - -**MU**: Telegram, Google Hangouts, iMessage, Facebook Messenger - -**SM**: -[Signal](https://gist.github.com/TheBlueMatt/d2fcfb78d29faca117f5) - -*Side note: The most popular messaging app - WhatsApp - only scores a -single letter (U). This makes it completely uninteresting to me.* - -Let\'s talk about **SM** - which might contain the key to solving SMU. -Two approaches are interesting here. - -The single key model --------------------- - -In Signal there is a single identity key which can be used to register a -device on the server. There exists a process for sharing this identity -key from a primary device to a secondary one, so that the secondary -device can register itself (see the link above for a description). - -This *almost* breaks M because there is still a dependence on a primary -device and newly onboarded devices can not be used to onboard further -devices. However, for lack of a better SM example I\'ll give it a pass. - -The other thing it obviously breaks is U as the process for setting it -up is annoying and having to rely on the primary device is a SPOF (there -might be a way to recover from a lost primary device, but I didn\'t find -any information so far). - -The multiple key model ----------------------- - -In iMessage every device that a user logs into creates a new key pair -and submits its public key to a per-account key pool. Senders fetch all -available public keys for a recipient and encrypt to all of the keys. - -Devices that join can catch up on history by receiving it from other -devices that use its public key. - -This *almost* solves all of SMU, but its compliance with S breaks due to -the fact that the key pool is not auditable, and controlled by a -third-party (Apple). How can you verify that they don\'t go and add -another key to your pool? - -A possible solution -------------------- - -Out of these two approaches I believe the multiple key one looks more -promising. If there was a third-party handling the key pool but in a way -that is verifiable, transparent and auditable that model could be used -to solve SMU. - -The technology I have been thinking about for this is some kind of -blockchain model and here\'s how I think it could work: - -1. Bob installs the app and begins onboarding. The first device - generates its keypair, submits the public key and an account - creation request. - -2. Bob\'s account is created on the messaging apps\' servers and a - unique identifier plus the fingerprint of the first device\'s public - key is written to the chain. - -3. Alice sends a message to Bob, her device asks the messaging service - for Bob\'s account\'s identity and public keys. Her device verifies - the public key fingerprint against the one in the blockchain before - encrypting to it and sending the message. - -4. Bob receives Alice\'s message on his first device. - -5. Bob logs in to his account on a second device. The device generates - a key pair and sends the public key to the service, the service - writes it to the blockchain using its identifier. - -6. The messaging service requests that Bob\'s first device signs the - second device\'s key and triggers a simple confirmation popup. - -7. Bob confirms the second device on his first device. It signs the key - and writes the signature to the chain. - -8. Alice sends another message, her device requests Bob\'s current keys - and receives the new key. It verifies that both the messaging - service and one of Bob\'s older devices have confirmed this key in - the chain. It encrypts the message to both keys and sends it on. - -9. Bob receives Alice\'s message on both devices. - -After this the second device can request conversation history from the -first one to synchronise old messages. - -Further devices added to an account can be confirmed by any of the -devices already in the account. - -The messaging service could not add new keys for an account on its own -because it does not control any of the private keys confirmed by the -chain. - -In case all devices were lost, the messaging service could associate the -account with a fresh identity in the block chain. Message history -synchronisation would of course be impossible. - -Feedback welcome ----------------- - -I would love to hear some input on this idea, especially if anyone knows -of an attempt to implement a similar model already. Possible attack -vectors would also be really interesting. - -Until something like this comes to fruition, I\'ll continue using -Telegram with GPG as the security layer when needed. - -**Update:** WhatsApp has launched an integration with the Signal guys -and added their protocol to the official WhatsApp app. This means -WhatsApp now firmly sits in the SU-category, but it still does not solve -this problem. - -**Update 2:** Facebook Messenger has also integrated with Signal, but -their secret chats do not support multi-device well (it is Signal -afterall). This means it scores either SU or MU depending on which mode -you use it in. - -An interesting service I have not yet evaluated properly is -[Matrix](http://matrix.org/). |