3
$\begingroup$

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:

  1. Read/Write access
  2. Read-only access
  3. 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. ;-)

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ You should not be encrypting "with the private key". $\:$ See this question and this answer. $\;\;\;\;$ $\endgroup$
    – user991
    Oct 15, 2014 at 9:44
  • $\begingroup$ Thanks, that did look like the obvious choice, but a little research showed that it's not the way to go. $\endgroup$
    – DeathByPiano
    Oct 15, 2014 at 23:43

1 Answer 1

Reset to default
4
$\begingroup$

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.

Improve this answer
$\endgroup$
6
  • $\begingroup$ Yes. The key for encrypting and decrypting the messages can (and should) be that of a symmetric algorithm, e.g. AES-CTR with suitably random or sequential IV, and known to groups 1 and 2. $\;$ Signing should be on the enciphered data, using an asymmetric signature algorithm (e.g. RSA with PKCS#1v2 signature padding), with the private key known to members of group 1, and the public key known to all (as implied by its name). $\;$ Everyone (except possibly from group 3) should verify signature of enciphered data manipulated. $\endgroup$
    – fgrieu ♦
    Oct 15, 2014 at 9:56
  • $\begingroup$ Also: because RSA allows fast signature verification, it is a good candidate for the signature from an efficiency standpoint if reading and forwarding with integrity verification largely predominates writing/signing. If signature size overhead is an issue, RSA signature with message recovery can help reduce the signature overhead (e.g. to 34 bytes with ISO/IEC 9796-2 scheme 3 using SHA-256, with encrypted message of at least 222 bytes and 2048-bit RSA). $\;$ AES-CTR encryption/decryption is fast, and its size overhead is limited to the IV (e.g. 10 bytes for a counter to $2^{80}$). $\endgroup$
    – fgrieu ♦
    Oct 15, 2014 at 10:10
  • $\begingroup$ Thank you! I did not even think about layering it this way. I'd basically replace the asymmetric encryption with a symmetric one while keeping the asymmetric signing. What's the potential downside? I guess a node in group 2 could issue an encrypted, but not signed message. Then it would be only up to convention to drop that message upon evaluation on other nodes? $\endgroup$
    – DeathByPiano
    Oct 15, 2014 at 23:47
  • $\begingroup$ I don't know exactly what your situation is but yes, it will be possible for nodes without write access to flood messages with invalid signatures and other nodes will have to drop them. $\endgroup$
    – Travis Mayberry
    Oct 16, 2014 at 11:31
  • $\begingroup$ I guess that's unavoidable in any configuration. In the extreme case, even group3 could post plain text messages to the queue, which other nodes have to be disciplined enough not drop. $\endgroup$
    – DeathByPiano
    Oct 17, 2014 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.