Saving this. When we form the resistance against AI machines this will probably be the flag. Someone ship a few to Sarah Connor too.
- 0 Posts
- 3 Comments
Joined 2 years ago
Cake day: June 8th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
Not sure which docs you are looking at, but my preferred description for this part is SMP
- https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md
- https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md#smp-procedure
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:
- queues are unidirectional (so you need at least 2 for a contact) and you only create the ones you use to receive messages
- the server holds two identifiers for a queue - one for the sender one for the receiver
- 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)
- all the keys/ids i mentioned so far a created anew per queue
- 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
- you would have to send it to a server with the wrong ID and encrypted with wrong key
- 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)
- 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
It is a long article covering a bunch of things. But I’ll try to cover the items in the comments.
GUIX puts things in different location, making it incompatible with fhs standard. This important for guix to be able to implement its core features, namely these TWO
The problem for the “consumer” here happens when they try to drop a binary they download from the internet and it fails to run because:
The article covers two solutions for this problem: the first is patchelf (but is only meaningful for link loader and libs) and the second is to run inside a container (guix shell --container --emulate-fhs). I should note here the container solution is not that different from e.g. flatpak or similar.
Now for my personal (and very biased) opinion. I do like that guix enforces this and that random binaries from the internet don’t simply run here.
Historically distros packaged software for various reasons - but one side effect of this is that package maintainers (i.e. your distro volunteers) vetted changes/updates, tested new releases and reported issues upstream (or patched it). For me this is an important part of Linux distros not being a monoculture.
Finally on a hopeful note. I don’t think this is insurmountable. The article mentions two things that already exist 1) guix packages that wrap binaries in containers and 2) guix import that does auto imports for libraries. In principle there could be a tool that glues these two to automate it but this will probably happen in one of the projects that packages binaries (nonguix probably).