I think @cryptix may have some thoughts on this.

@alannamix how ironic.

@juul I disagree with the mainstream (post-OTR) crypto community that deniability should be the primary goal. I think the landscape has changed, and the distant maybe of key compromise is not as much of a concern as the present and looming threat of metadata analysis. So, my approach to privacy is

• step one, make usable software that people want to use everyday.
• step two, make that as metadata private as possible. Metadata is easier to analyze than content! that is why it's more important to protect it!

That is, our goal is mass privacy and individual privacy is just a means to that end.

We are getting pretty good at step one, and our venturing into step two, well, we've made a good first step - it's immediately obvious who is talking to who, but there just arn't enough private messages. I'm hoping private groups are gonna change this though! We've talked about this for ages, but the enabling thing was out-of-order messages (which are working just need support to be implemented in clients!) so I'm gonna make a grant proposal for this in janurary.

okay, so signal has deniability, great, but it uses phone numbers for identifiers so every other app which of course requests access to the contacts (and they basically all do, because that's the nuts) can still see who you are friends with! Also, it's centralized - so xkeyscore selector is something like: who has signal installed / connects to signal's servers, and what are their contact lists?

Also, deniabilty only works with ephemerality, but users find chat history useful. (signal's explicit self destructing messages are good here, though)

So, for people who really want deniability, I have two ways I think we can go

• explicit self-destructing messages, like signal has. I like the idea of explicitly sending someone a self-destructing "envelope" that they can send you a deniable message in.
• once we get full p2p: on-the-side realtime chat, which is fully ephemeral, deniable, forward secure.
• ps, if you want forward secrecy today, you can cycle your private keys occasionally.

I'm definitely not a deep and known crypto expert but I know my way around the basic constructions and how to hang myself with them. I also know somebody that I trust ( @keks ) that reviewed secret-handshake (which is used for the transport crypto) together with his university professor using the tamarin prover ( thread repo ). I'm not sure if that lead to a paper but IIRC their conclusion was that it might be over-engineer but it's claims are sound. Keks and my interest in this also fueled the port to #golang.

So passive adversary is fine as along as all the public peers (pubs) only talk to peers they know (friend-distance authentication). I'm honestly not sure this is true for very pub since misconfiguration is easy. I'm currently working on a monitoring tool which I plan to release in the coming weeks. So my current verdict is, treat ssb like a distributed twitter. All the current open-invite pubs also make it very easy to get your hand on the feeds that are on here and analyze the activity data.

The current PM system use plain ed25519 for (un)boxing the messages, so these are fine thanks to djbs simple API. I mainly stand with @dominic on the compromise vs metadata approach although I think there is room for improvement that doesn't plunge us into deniability chaos.

if you want forward secrecy today, you can cycle your private keys occasionally.

Yes but re-keying and following is quite noisy. Keks also purposed forward secrecy for groups like this some time ago. I think we could merge this into the current PMs, too. tl;dr: periodically post use this new key for PMs from now on. Then you could have your long-lasting identifier and still make old PMs ununboxable by deleting those private keys to it.

I'm not too keen on implementing double ratchet. I think it's clusterfuck to reason about. See omemo implementation adoption (I think only chatsecure, gajim and conversations have (partially) working implementations) and the problems matrix.org/megolm is fighting with in their group crypto. Wire seems also to have figured it out but I'm still waiting for their federation support. I fear that the protocol hits the fan once you don't have a central server. I'm glad for moxie that he got it working but I also find his threat modeling around his service confusing. I rather wait what the crypto community is coming up with next. Key puncturing seems like a viable concept that doesn't turn your brain into a :(){ :|:& };:

@cryptix great points, yeah w could have a curve25519 key that you rotated occasionally, that was only for receiving private messages... there are still some questions arising from that... but lets discuss that again soon because private messages will see some work again soon.

@keks - overengineered but claims are sound! I'll take it!

Oh yeah, telegram is quite popular with users, but they don't have the respect of the academic cryptographic community that signal has. Funny that in something as objective and mathematical as cryptography we still must make our security decisions by evaluating other people's subjective social relations!