4 ms·

It seems to me that if any new device/app that "logs to your IM account" gets all message history, you're kind of defeating the point of having E2EE in the firs

by nicoco 4y ago

It seems to me that if any new device/app that "logs to your IM account" gets all message history, you're kind of defeating the point of having E2EE in the first place. If I sent encrypted messages to a trusted device of yours, I suppose I don't really want any new device of yours to get these messages. I agree that this does not create the best "user experience", but if that is what you are looking for, maybe you didn't want E2EE in the first place? It could be possible to have a XEP that covers "history syncing between my devices", but what's the point of E2EE if encrypted information can just be transferred and duplicated like this? It's also possible to disable OMEMO if having history sync'ed on any new device is what's most important to you. It's not like messages are sent as plain unencrypted text (unlike email...), TLS is used. If you and the other end are on servers you trust (or own), there is little reason to use OMEMO anyway. Except that nice lock icon that supposedly means "safe" without really defining "safe *from what*".

kitkat_new 4y ago
> you're kind of defeating the point of having E2EE in the first place. why? > If I sent encrypted messages to a trusted device of yours, I suppose I don't really want any new device of yours to get these messages. I actually do. > maybe you didn't want E2EE in the first place I am sure I do want E2EE. > but what's the point of E2EE if encrypted information can just be transferred and duplicated like this? being able to read my messages on all my devices? > If you and the other end are on servers you trust (or own), I have to also trust the servers of all my contacts. Where did I imply that? > Except that nice lock icon that supposedly means "safe" without really defining "safe from what". safe from anyone being able to read my messages except me and my communication partners
- nicoco 4y ago
  > why? If you have E2EE but then one the two ends can be substituted for a new one, does it really qualifies as E2EE? If I have a hard requirement on E2EE, it probably means I don't want encrypted messages stored forever on remote servers, and easily decrypted on new devices. Or it can also mean I don't really understand what encryption mean, and I'm only interested in having a nice looking lock icon next to my messages. >> If I sent encrypted messages to a trusted device of yours, I suppose I don't really want any new device of yours to get these messages. > I actually do > I am sure I do want E2EE. Then what you are looking for is opengpg-type encryption (which is available via XMPP's most popular clients too). It's a lot less convenient to set up but this is how you switch from "device key" to "personal key". > I have to also trust the servers of all my contacts. Where did I imply that? Where did I imply that? I just gave you an example use case that is generally not tagged as E2EE but where no one but you and your contact can read your messages (self hosting). > being able to read my messages on all my devices? I can read all my OMEMO encrypted messages on all my devices. If I use a new device, I cannot read history. But that's because OMEMO isn't just for show (the nice lock icon), but actually something that makes it nearly impossible for anyone but you or your communication partner to read what you exchanged. Also, most XMPP clients also allow to export local history, which could then be imported again, so if keeping all chat history really matters to you, it's also possible. But again, if you plan to store messages forever, you increase the chance of it being read by third parties significantly. > safe from anyone being able to read my messages except me and my communication partners If that is all that matters to you, facebook messenger has E2EE and it should suit your needs. It has the nice lock icon you're looking for. I think that who you talk to and how often you do is also rather important for privacy concerns, that's why I self host my XMPP server. You seem to like the matrix protocol, where even if you self host, a lot of data is sent to the mother ship, cf https://hackea.org/notas/matrix.html https://hackea.org/notas/matrix.html
  - Arathorn 4y ago
    > You seem to like the matrix protocol, where even if you self host, a lot of data is sent to the mother ship, cf https://hackea.org/notas/matrix.html https://hackea.org/notas/matrix.html That article is bullshit and FUD (as its subheading seems to acknowledge). No data is sent back to matrix.org if you selfhost (unless you point your config at matrix.org, obviously).
    - nicoco 4y ago
      Sorry for spreading it if it is FUD indeed (cannot edit anymore). I'll concede that I am not skilled or motivated enough to verify all that is asserted there; I think my other points about E2EE still stand, don't they? There is a lot of FUD about XMPP in comments on HN, and I feel bad for (potentially) doing the same thing about matrix, this was not my goal.
      - Arathorn 4y ago
        > Sorry for spreading it if it is FUD indeed np; thanks for listening :) > I think my other points about E2EE still stand, don't they? I think the question is whether the recipient should be able to move message keys between their devices so they can decrypt messages from the server when they log in on a new device. Given the recipient already has the plaintext of the messages, they can obviously copy the plaintext to the new device (as Signal and Wire do, for instance). Alternatively, if the recipient has the message keys (as in Matrix), they can copy those to the new device and use them to redecrypt the history off the server. This gives the same end result, but with less data being transferred between the clients. It doesn’t violate any E2EE; it’s just the recipient chosing to process their history as they like.
        singpolyma3 4y ago
        OMEMO let's you move keys to a new device no problem, if you buy a new phone and will no longer use the old one for instance.
  - kitkat_new 4y ago
- leetnewb 4y ago
  I'm curious which messenger options allow you to add a new device to receive and decrypt old messages? I don't think Signal allows it, and forward secrecy seems to be the standard for secure E2EE. I do agree that can be a source of friction for users. And perhaps an encryption system that doesn't require forward secrecy would be enough for most.
  - kitkat_new 4y ago
    WhatsApp, a few Matrix clients for certain (Element, FluffyChat, Cinny), Threema (the old WhatsApp way with plans to do it similarly to the new WhatsApp way). I am not aware that forward secrecy is contradictory to that.

by nicoco 4y ago

kitkat_new 4y ago

> you're kind of defeating the point of having E2EE in the first place. why? > If I sent encrypted messages to a trusted device of yours, I suppose I don't really want any new device of yours to get these messages. I actually do. > maybe you didn't want E2EE in the first place I am sure I do want E2EE. > but what's the point of E2EE if encrypted information can just be transferred and duplicated like this? being able to read my messages on all my devices? > If you and the other end are on servers you trust (or own), I have to also trust the servers of all my contacts. Where did I imply that? > Except that nice lock icon that supposedly means "safe" without really defining "safe from what". safe from anyone being able to read my messages except me and my communication partners

nicoco 4y ago
> why? If you have E2EE but then one the two ends can be substituted for a new one, does it really qualifies as E2EE? If I have a hard requirement on E2EE, it probably means I don't want encrypted messages stored forever on remote servers, and easily decrypted on new devices. Or it can also mean I don't really understand what encryption mean, and I'm only interested in having a nice looking lock icon next to my messages. >> If I sent encrypted messages to a trusted device of yours, I suppose I don't really want any new device of yours to get these messages. > I actually do > I am sure I do want E2EE. Then what you are looking for is opengpg-type encryption (which is available via XMPP's most popular clients too). It's a lot less convenient to set up but this is how you switch from "device key" to "personal key". > I have to also trust the servers of all my contacts. Where did I imply that? Where did I imply that? I just gave you an example use case that is generally not tagged as E2EE but where no one but you and your contact can read your messages (self hosting). > being able to read my messages on all my devices? I can read all my OMEMO encrypted messages on all my devices. If I use a new device, I cannot read history. But that's because OMEMO isn't just for show (the nice lock icon), but actually something that makes it nearly impossible for anyone but you or your communication partner to read what you exchanged. Also, most XMPP clients also allow to export local history, which could then be imported again, so if keeping all chat history really matters to you, it's also possible. But again, if you plan to store messages forever, you increase the chance of it being read by third parties significantly. > safe from anyone being able to read my messages except me and my communication partners If that is all that matters to you, facebook messenger has E2EE and it should suit your needs. It has the nice lock icon you're looking for. I think that who you talk to and how often you do is also rather important for privacy concerns, that's why I self host my XMPP server. You seem to like the matrix protocol, where even if you self host, a lot of data is sent to the mother ship, cf https://hackea.org/notas/matrix.html https://hackea.org/notas/matrix.html
- Arathorn 4y ago
  > You seem to like the matrix protocol, where even if you self host, a lot of data is sent to the mother ship, cf https://hackea.org/notas/matrix.html https://hackea.org/notas/matrix.html That article is bullshit and FUD (as its subheading seems to acknowledge). No data is sent back to matrix.org if you selfhost (unless you point your config at matrix.org, obviously).
  - nicoco 4y ago
    Sorry for spreading it if it is FUD indeed (cannot edit anymore). I'll concede that I am not skilled or motivated enough to verify all that is asserted there; I think my other points about E2EE still stand, don't they? There is a lot of FUD about XMPP in comments on HN, and I feel bad for (potentially) doing the same thing about matrix, this was not my goal.
    - Arathorn 4y ago
      > Sorry for spreading it if it is FUD indeed np; thanks for listening :) > I think my other points about E2EE still stand, don't they? I think the question is whether the recipient should be able to move message keys between their devices so they can decrypt messages from the server when they log in on a new device. Given the recipient already has the plaintext of the messages, they can obviously copy the plaintext to the new device (as Signal and Wire do, for instance). Alternatively, if the recipient has the message keys (as in Matrix), they can copy those to the new device and use them to redecrypt the history off the server. This gives the same end result, but with less data being transferred between the clients. It doesn’t violate any E2EE; it’s just the recipient chosing to process their history as they like.
      - singpolyma3 4y ago
        OMEMO let's you move keys to a new device no problem, if you buy a new phone and will no longer use the old one for instance.
- kitkat_new 4y ago
leetnewb 4y ago
I'm curious which messenger options allow you to add a new device to receive and decrypt old messages? I don't think Signal allows it, and forward secrecy seems to be the standard for secure E2EE. I do agree that can be a source of friction for users. And perhaps an encryption system that doesn't require forward secrecy would be enough for most.
- kitkat_new 4y ago
  WhatsApp, a few Matrix clients for certain (Element, FluffyChat, Cinny), Threema (the old WhatsApp way with plans to do it similarly to the new WhatsApp way). I am not aware that forward secrecy is contradictory to that.