You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wrt. #30, authentication and non-repudiation: This is the RECEIVING side being able to verify that a message comes from the claimed source, and not someone else that have gotten into the system.
However, it does not hinder another node to fire up and start listening to messages for a given queue - thereby getting information that it should not have had (as the messages still would be plaintext).
Thus, we would need to encrypt messages so that only the intended receiver can read it.
However, this poses a completely different problem than signing: You SIGN with your own (private) key, which then always is the same. With encryption, you would have to ENCRYPT with the receivers (public) key. Therefore, you would need to know which app listens to any given queue.
Wrt. #30, authentication and non-repudiation: This is the RECEIVING side being able to verify that a message comes from the claimed source, and not someone else that have gotten into the system.
However, it does not hinder another node to fire up and start listening to messages for a given queue - thereby getting information that it should not have had (as the messages still would be plaintext).
Thus, we would need to encrypt messages so that only the intended receiver can read it.
However, this poses a completely different problem than signing: You SIGN with your own (private) key, which then always is the same. With encryption, you would have to ENCRYPT with the receivers (public) key. Therefore, you would need to know which app listens to any given queue.
Thus, you need a registry: #29
The text was updated successfully, but these errors were encountered: