Authenticated PubSub

[ianopolous]

@whyrusleeping asked me to post some use cases for an authenticated pubsub api. In this api the topic to subscribe to would be a public key (or one could consider a path starting with a public key for more fine grained control). Anyone can subscribe to a key. However all updates have to be signed by the corresponding private key, and the network would verify these signatures before propagating them.

We would use this in Peergos to allow only users with write access to a part of the filesystem to publish updates.

I can imagine an equivalent to an RSS feed, or even a plain blog, being done using this.

The only sticky point I can think of is ensuring replay attacks aren't possible. Where nodes without the private key republish an old update, but there are techniques to solve this.

[lachenmayer]

I'm very interested in this - is there any documentation around how pubsub works currently / could someone point me towards the right places in the code to play around with this?

[ianopolous]

@lachenmayer There's probably another explanation somewhere, but there's https://github.com/ipfs/blog/blob/4b81aaa0d0819858cf89f5f3f8ab134adfa48128/src/21-pubsub/index.md

[daviddias]

@ianopolous thank you for kicking this again :) See notes from the IPFS workshop here -- #154 -- We've started talking and describing what this would like there :)

[ianopolous]

There is also more discussion here

[RangerMauve]

I would say that instead of authentication, you should use encryption.

If you want to pubsub data that you don't want to be read by random people, share a secret key of some sort and encrypt all the data before publishing it. Then share the secret key with all peers that need it and have them decrypt messages as they get them. If any messages come that can't be decrypted with the key, ignore them.

This makes it easy to have secure pubsub without having to trust the actual pubsub network or worry about people snooping on your messages.

The main limitation here is that people will still be able to pick up on frequency of messages so you should be wary about whether you have any sensitive timing information

@RangerMauve this discussion is not about privacy or encryption -- it's about authenticity of pubsub messages.

[RangerMauve]

@lgierth Encryption acts as authentication in this case. Messages that aren't encrypted with the correct key are ignored.

Ah yes, understood -- now you have to distribute keys though, and the network can't proactively drop invalid messages anymore.

[RangerMauve]

I like the idea of having topics be public keys, but I really like the option to use arbitrary strings for topics. I could see applications that use one particular key for authentication/encryption using multiple topics for different streams of events. For instance different chat rooms. I guess it could have all data in a single stream and have clients filter out messages they don't want, but that would be a lot less efficient.

[RangerMauve]

An application could generate keys from passphrases to make it easier on users. See, for example, how peergos supports "logging in".

One could also use a password that's used with aes encryption.

[RangerMauve]

Sharing keys between peers is also in the works as you can see here

[ianopolous]

Using authentication instead of encryption means the network (without knowledge of any keys) can mitigate DOS attacks from people who try to flood the topic. In Peergos we would be publishing things which are independently encrypted anyway. But pubsub doesn't need to know that.

This means we also don't need to trust the network. Though bear in mind the network can always drop/delay messages, but can't inject messages.