-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discuss - 0009-MPID-Messaging #96
Comments
I am not sure, if this is the right place, but I'll just leave this here then. First off. Great work! I am happy you are discussing a new, safe way of secured message passing for the safe network. As a seasoned software dev, I think one major misappropriation was naming the programming model "Object Oriented" rather than "MessagePassingActors". A key infrastructure of any distributed system focus on independent actors which pass messages from and two each other. I love that you are also adopting this concept inside the actual infrastructure allowing to build cool apps on top, which can just rely on it! First a general remark, which might just be a clarification of understanding on my side: MPID-Messages are supposed to be held in-memory by Manager Vaults (suggested here )? What if the vault the Node is on dies? Or am I missing something about how messages like these are stored in general? Also, how is an Inbox bound to the sender and can the size-limit be enforced? To the nitty gritty:
While the sender field is self-explanatory, the let encoded = Self::encode(&sender_name, &guid, &metadata); But is the sender_name really needed in this signature? If you'd temper with that the public-key for the XorName wouldn't be valid for that message anymore, would it? Or can different XorNames have the same private+public-key-pair, so you could impersonate a different sender – in which case including it in the signature wouldn't actually prevent this from taking place though. I am only arguing this because for the message itself we have the definition:
Which doesn't include the header in the signature but has a terribly long name (I'd totally vote for also shortening that to Which leads to that awkward case that I could ask the outbox for a guid I have in my inbox, but the message stored on the MpidManager (I am thinking of an entity that might has been messed with), is serving me a different MpidMessage, with a different header than the header I have for more guid, containing a totally valid signature but all of the sudden is from a different Which would however be made much easier to verify if the signature was defined as All this written now, I am wondering whether the guid is needed at all. If instead you used the full-message-signature as that key (so a The only "problem" would occur when the same message is send twice (or you could argue that this actually not a real-life problem and should be considered the same message or the sender should include a timestamp or sequence number in their timestamp – see my remark after).
While I like that the you can add further metadata, but I'd strongly argue for either another field that specifies the
I'd argue this wouldn't always have to be the case, but falls into the metadata-part I mentioned earlier. I'd argue that an "email"-like system should have a title in the metadata already, while in the case of a safecoin or instant message that doesn't make any sense. However, If you want to put the pressure of having the message on the sender side, the header needs to provide all necessary information for the client (or better: Person in front of the computer) to make the decision to retrieve that message or not. While the sender is a good indicator, at least for email the title would be another important one. And I'd actually add some rudimentary system to identify the message type and know which other fields/structs to expect to help with this process. (I am also wondering why there is not timestamp in there... I feel that is a good information to have)
What is |
It just occurred to me that we aren't encrypting the message itself and I am wondering if that shouldn't be happening. I know the possibility of an intercept is low but just considering that the message will be hold in memory by some rounting nodes, anyone on that node can then read that message – or am I mistaken here?. So you just need to gain access to enough Nodes/strategic Nodes and you could intercept information reliably Maybe I am missing something obvious, but wouldn't it be better to encrypt the metadata and body with the recipients public key (which would also mean that you mathematically can't more than one recipient) before signing and sending only the encrypted content? Or do we guarantee in some other way that intercepted messages can't be read? |
https://github.com/maidsafe/rfcs/tree/master/text/0009-MPID-Messaging
The text was updated successfully, but these errors were encountered: