Passing private, encrypted messages between MSMQ and another message queue system is very similar to passing private messages between MSMQ applications. The only difference is a symmetric key that is exposed when sending a private message to the other message queue system.
The implementation of the connector application plays a significant role when passing private messages to their destination.
Transparent connector applications pass the symmetric key, encryption algorithm, and the encrypted message body on to the queue manager of the destination queue. This is the same regardless of the direction the message is going. When using a transparent connector application, the public keys of all destination queue managers must be registered in MQIS.
Non-transparent connector applications decrypt the message at the server and can pass on a clear-text message body or, encrypt the message again (using a the receiving systems encryption operations) and pass on a newly encrypted message body. When using a non-transparent connector application, all destination queues must use the public key of the connector application.
In addition to the type of connector application, there are two design considerations that should be taken into account:
This means that there must be a level of trust between the connector application and the foreign queue manager. There is no way for the foreign queue manager to independently verify that the key it receives is the public key it requested.
Non-transparent connector applications can cache the symmetric key to save time when decrypting private messages. If several messages arrive from the same source, there is no need to decrypt a symmetric key for each message.
To do this, the application must cache the identifier of the source computer and the decrypted and encrypted values of the symmetric key. The connector application can call PROPID_M_SRC_MACHINE_ID, to retrieve the identifier of an MSMQ source machine.
When the next message arrives, the connector application can first check if a message has already arrived from that source machine. If the machine identifier is not found, the connector application will add it to the cached values.
If a previous message has arrived, the application can next test to see if the new encrypted key matches the cached encrypted key. If they match, the cached decrypted value can be used immediately. If they do not match, it will decrypt the new key (storing both the encrypted and decrypted values in the cache), using the new value to decrypt the message body.