~yujiri/sufec#4: 
Multi-device support

Is there any way to do this in a peer to peer setting, without exposing information about what devices you have? (I think if conversation partners can see that information, the feature is crippled because it's reduced to a mere UX improvement on having separate accounts for separate devices that are each present in the room.)

Status
REPORTED
Submitter
~yujiri
Assigned to
No-one
Submitted
2 months ago
Updated
16 days ago
Labels
No labels applied.

~yujiri referenced this from #3 a month ago

~yujiri a month ago

I don't think there's any decent p2p solution; we're going to implement this through optional use of a homeserver as was discussed on #3. Copying comment:

My first, naive, idea of this was to simply have all your devices share your private key, your homeserver can't tell the difference between the devices (privacy++, right?), and so it would just store received messages for something like a week to give you time to download it to all devices.

Security--: this means storing messages after all devices have received them, allowing them to be compromised by a key compromise up to a week in the future. I'm not about to accept that after how big a deal I've made out of forward secrecy in planning this protocol.

Another apparent security-- is that if all devices simply share the private key, you can't use one device to revoke another's access if it's lost. My decision to have them all share the private key came after reading about some other solutions for multi-device support (too complex for me to fully understand) that involved each device havings its own long-term key pair and the sender separately encrypting a message to each of your devices, and I thought, "that's a privacy--, I don't want everyone who sends me messages to know how many devices I have and when I add a new one etc".

But on closer reflection I don't think this is a security-- because if one device can revoke another's access, and you lose a device, then that device could also be used to revoke your remaining device first.

So, to address the first security--: I have decided that the client, when fetching messages from homeserver, must include some sort of device ID (not a key pair or signature, just an ID), and the homeserver should know which device IDs are on your account, so that the homeserver can know when all devices have received a message and stop storing the messages immediately thereafter.

The devices will still share the long-term key pair.

Actually, maybe the device ID should be a separate key pair, to prevent devices from pretending to be each other?

~yujiri a month ago

Just realized I was wrong to think that storing the encrypted messages after they've been received would compromise forward secrecy. The attacker would still need to compromise both the long-term key and the private ephemeral key to read a message. It's still probably suboptimal, though.

~yujiri a month ago

Crap - I just realized that either scheme is subject to major other problem: you need the private part of the used prekey to decrypt the message, so you need a way to share prekeys across your devices or else only the one that generated it can read the message! And how do you share prekeys across your devices when any of them needs to be able to generate one on its own, and then might not be online when another device needs to receive the message?

The only thing I can think of is having each device also store a separate set of prekeys on your server, which your other devices would use to encrypt the message prekeys to the former device.

But this is nasty! It may not even be any less complex than Sesame. There's got to be a better way.

~yujiri a month ago*

I have realized that even the above doesn't work, because when the sender asks for a prekey, which one would your server give them? it doesn't know which of your devices will be online next.

I think any solution to multi-device support must accept one of the following downsides:

  • A loss of privacy: anyone who messages you can see your devices because they have to encrypt their message to each one separately
  • A loss of forward secrecy: with multi-device enabled, messages are encrypted only to your long-term public key
  • A loss of convenience: you have to continually sync the private parts of prekeys between your devices so that each device can read a message encrypted with a prekey it didn't generate

~yujiri 19 days ago

But on closer reflection I don't think this is a security-- because if one device can revoke another's access, and you lose a device, then that device could also be used to revoke your remaining device first.

This was wrong. The most common use case of multiple devices is probably a computer that stays at home + a phone. The phone is much more likely to be lost, so it might make sense to have the computer able to revoke the phone but not vice versa.

~yujiri 16 days ago*

So if we were to implement the Loss of Privacy approach, what would it look like?

  • When you request someone's public ephemeral key, you get one for each device, and you encrypt the message to each.
  • Each device has a device ID, visible to the owner and their homeserver.
  • When you connect as a listener, you tell the homeserver which device you're on, and that tells it which ephemeral key you'll be replacing.
  • When you download a message, your server marks it as downloaded to that device ID. It stores the message until all your devices have downloaded it.

Actually, I wonder if it'd work to identify devices by their current ephemeral keys instead of by a device ID 🤔

Register here or Log in to comment, or comment via email.