Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

E2E Encryption: Publishing to N subscribers

See original GitHub issue

For E2E encryption we need to publish events to multiple subscribers, there may be multiple strategies but the one that I am investigating is to publish N times by using PublishOptions(eligible=recipient_session_id). How the session ID is discovered is a separate thing.

One thing that is currently missing in autobahn is to have a way to specify which responder_pub to use when an event is being published. Once it supports that, any helper function like publish_bulk(topic, [recipients...]) could be used to achieve the 1:N publishing.

Issue Analytics

State:
Created a year ago
Comments:11 (10 by maintainers)

Top GitHub Comments

1reaction

meejahcommented, Jul 28, 2022

I suspect a promising direction is to examine the state-of-the-art for group messaging (e.g. Signal protocol for groups).

However, this has certain features that can be seen as disadvantages: late-joiners can’t “catch up” with the group messages (they will never have the right keys).

Some messaging clients like Keybase take a different approach, using a symmetric key for the group messages – this allows “catch up” for late joiners, but lacks some of the forward-secrecy features of the the Signal-like protocol.

It stil might be interesting to pursue both? That is, some users might not want forward secrecy, instead preferring history etc features to work coherently for late-subscribing clients.

(I haven’t tried to consider what a ratchet-style protocol might actually mean for key-management etc inside crossbar, mind 😉 )

0reactions

oberstetcommented, Jul 30, 2022

but sounds like a similar effect at least

yes, same effect as in “provides forward secrecy” (btw I forgot, one needs to subscribe to meta API subscriber add and remove and rotate keys on each)

I’ve also not analyzed “ratchet protocols” in detail, quick search turns up a couple of interesting links (but I need to find time to actually read them;)

https://security.stackexchange.com/questions/126768/which-protocols-exist-for-end-to-end-encrypted-group-chat https://www.ieee-security.org/TC/SP2015/papers-archived/6949a232.pdf https://whispersystems.org/blog/advanced-ratcheting/ https://github.com/trevp/double_ratchet/wiki https://eprint.iacr.org/2017/666.pdf https://messaginglayersecurity.rocks/mls-architecture/draft-ietf-mls-architecture.html

Top Results From Across the Web

PICADOR: End-to-End Encrypted Publish-Subscribe ... - NJIT

This article presents PICADOR, a system for end-to-end encrypted Publish- ... with end-to-end encryption where publishers and subscribers.

Transparent End-to-End Security for Publish/Subscribe ...

encryption enables the broker to obliviously re-encrypt messages received from the publishers for every subscriber independently,.

(PDF) PICADOR: End-to-End Encrypted Publish-Subscribe ...

This article presents PICADOR, a system for end-to-end encrypted Publish-Subscribe information distribution with proxy re-encryption.

A Secure Publish/Subscribe Protocol for Internet of Things

The payload would always be encrypted on the Publisher side, whereas the decryption process may occur in the subscriber in End-to-End encryption but...

Messages in Publish/Subscribe Systems

end-to-end delivery of messages in distributed messaging ... initiated by the publisher and subscriber, brokers that are part.