Encrypted read-only message queue I'm creating a prototype for a messaging queue with some custom logic (can't re-use any existing solution).

One requirement is to have all messages encrypted. There are three classes of nodes subscribing to the queue with the following permissions:


Read/Write access
Read-only access
Buffer/forwarder with no access to the message content


The first and obvious thought was to use an RSA private key for group 1. This would allow to encrypt with the private key and decrypt with the public key.

Group 2 would receive the corresponding public key and would be able to only decrypt the content.

Group 3 would have no key and just handles the messages without access to the content.



After doing some further reading, there seem to be a number of problems with this approach (apart from the simple fact that the keys are used in "reverse" in relation to the intended mechanism).

Now the question: Is there some common approach to get this pattern to work? I have searched, but so far have not found anything.

I will have access to someone with more experience in this matter at a later point, but for purposes of the prototype, I just want to get something done that won't make me look like an idiot later. ;-)
If you aren't worried about collusion or dynamic group membership, then a very simple solution is to simply have one key for encrypting the messages and another for signing them.  The encryption key gives someone read access and the signing key gives them write access.  Only nodes with the encryption key will be able to successfully decrypt the messages and read them, and only nodes with the signing key will be able to produce "valid" messages that have correct signatures.  The encryption key would be a symmetric key and the signing key would be a private key.  Everyone would have access to the public key to verify that messages were constructed by an authorized node.

If you need more complicated logic or a more flexible system, you can use cryptographic role-based access control, which usually makes use of attribute-based encryption.  But that solution will be very, very complicated.