Retroactive Interactive Key Sharing – RIKS


“Distribute first, give access later”

RIKS enables end-to-end encryption for live data over the full data lifecycle from producer to consumer(s). Data is protected in an unbroken chain over time, in transfer and at rest. RIKS also supports end-to-end encryption in dynamic groups where users and devices come and go.

Asynchronous communication patterns

While some forms of group communication are easily encrypted, protocols limited by asynchronous behavior or central authorities are harder to secure. RIKS adds a novel way of achieving end-to-end encryption for publish-subscribe protocols such as MQTT and AMQP.



These protocols have a property that makes them hard to secure. Senders are not in control over to whom the message is delivered. This is instead the responsibility of the broker. RIKS changes that.

Distribute access control to the data producer

RIKS effectively removes the authority of access control from the broker (if there is one) and gives it to the sender. By doing this, the consistency of the secret communication group is in the hand of the sender instead of at a central authority. The transfer of authority is done while maintaining other important properties that might be present in the message protocol, such as e.g. asynchronicity or publish-subscribe.

Encrypt, send and store first, give access later

On top of this, RIKS divides key establishment/sharing and the sending of messages. This way, you can decide on who the recipients are after you actually send the message. You also have an option of adding additional recipients later, which is very handy when storing data for later access by another party.

Applications can be, for instance:

  • End-to-end encryption in publish-subscribe communication (e.g. MQTT, real-time DBs), where the sender doesn’t know who subscribes to the messages at sending time.
  • A central storage of encrypted data that is only accessible at a later stage when the key is distributed to a group of users or devices.
  • End-to-end encrypted channels for dynamic chat groups. Example with source code and more
  • When you need granular control over data in a central application server preventing access by anyone except a specific group of users and devices.
  • Full data lifecycle lock down where data can be stored and transferred in services, countries, and networks that you do not need to trust.
  • Data managed by a third party cloud service where you still maintain control over the encryption keys that never leave the owner.


More reading

Take me to the documentation for a more in-depth description