• 0 Posts
  • 5 Comments
Joined 2 years ago
Cake day: June 8th, 2023
  • rrobin@lemmy.worldtoPrivacy@lemmy.ml•Opinion on the Matrix protocol
    1·
    2 months ago

    This was once common, but it’s somewhat rare now in my experience, and the upcoming Matrix 2.0 apparently addresses most (all?) of the remaining causes.

    I still see it - usual case is when someone has two clients. One of them will have issues with this.

    I consider this a good thing, for the sake of the people who joined or wrote in the chat with the understanding that what they write is and will remain encrypted. If you want to abandon encryption, you can always create a new room.

    Disabling encryption in the room did not have to mean decrypt past history. Yes you can create a new room. But for big groups who wants to risk it. The room admins I know steer clear of encrypted group chats because of the previous issue.

    No, there is one officially released client for android: Element. Element X is in beta. When it leaves beta, it will take over as the one officially released client.

    One would never guess based on the release announcement

    This is just plain false.

    https://spec.matrix.org/latest/client-server-api/#sending-encrypted-attachments

    The docs say it clearly “If encryption is enabled”. Otherwise attachments are just a link, nothing special there.

  • rrobin@lemmy.worldtoPrivacy@lemmy.ml•Opinion on the Matrix protocol
    61·
    2 months ago

    Yes and No

    I consider matrix to be somewhat equivalent to XMPP or public mailing lists. It is potentially decentralized (even though everyone uses matrix.org) and it can host group chats. And for those purposes it is ok-ish, but for privacy it is no good.

    My pet peeve with matrix is that I consider most features to be half baked. And instead of fixing them we just keep pilling up more. Here is a list in no particular order

    • encryption regularly breaks in weird ways, usually you see a message that you can’t read
    • if you enable encryption in a chat room you cannot disable it
    • we now have two official clients for Android (Element and Element X) in the first one encryption breaks in weird ways, in the later there is no way to use Spaces properly
    • direct messages between people don’t work well - it is like they are a room with the two people
    • privacy wise matrix is weak, leaks metadata, attachments are not encrypted, etc. Do not use if you expect privacy/anonymity. Also I think most groups run without encryption because of the other issues.
    • verifying sessions between clients is painful e.g. the client annoys me to verify but then verification does not trigger on the second client

    Because of this mess your quality of experience will vary depending on the client and features you use. The web clients are usable.

    I don’t really use the video/audio calls so I have no comments on that front.

  • rrobin@lemmy.worldtoSimpleX Chat@lemmy.ml•If SimpleX donesn't work with ID's, how can it be sure to deliver the messages at the right person ?English
    0·
    4 months ago

    Not sure which docs you are looking at, but my preferred description for this part is SMP

    The previous message already pointed out the main point - communication happens via queues our clients knows to belong to the destination, and these queues are temporary. This means even if an attacker determines the queue belongs to a specific person it can be changed and even then it does not reveal who is the other contact using the queue.

    A few more bits to consider:

    1. queues are unidirectional (so you need at least 2 for a contact) and you only create the ones you use to receive messages
    2. the server holds two identifiers for a queue - one for the sender one for the receiver
    3. the queue also has two keys - which allow the server to recognize the sender and receiver respectively i.e. only the sender can send and only the receiver can collect msgs (SMP server should reject otherwise)
    4. all the keys/ids i mentioned so far a created anew per queue
    5. finally the messages that are placed in the queue are encrypted between sender and receiver (DH) but is beyond SMP

    So there are IDs but hopefully they are not useful for an attacker.

    Now to answer your question. There are IDs but for a message to be delivered to the wrong person the following would need to happen

    1. you would have to send it to a server with the wrong ID and encrypted with wrong key
    2. the SMP server would need to allow this by decrypting it with the wrong key too (unlikely but not impossible I think - if we assume some magic to break point 3. from before)
    3. the message would then be picked up by the receiver (which would try to decrypt it but it would fail)

    Caveats - the client app must be well implemented and NEVER reuse keys. Likewise the server must not reuse queue IDs.

    I think I got my assumptions right. When in doubt check the 2nd link for a long step by step description of the protocol