Compromise Panic Button (Revoking a Ricochet Address)

[s-rah]

There should be a way, in the event of a key compromise, to inform contacts that a ricochet id can no longer be trusted.

It looks like there is mention of providing some of the mechanisms around this in the next gen spec and others.

When such a mechanism exists, we should build something into the UX i.e. a panic button that the user can press to initiate whatever revocation process is determined.

The button could also generate a new ricochet address, and create a "clean" profile - as well as provide some information to the user about next steps (including best practices for reestablishing trust)

It may also make sense to build a message into the ricochet protocol to inform users to no longer trust this address - this would certainly not be perfect (as it requires some online interaction between the trusting client and the one using the compromised key) but such a message could augment anything implementing at the onion service layer.

[ProGamerGov]

This is a much needed feature.

[special]

There is a Tor proposal on hidden service revocation. As far as I know, nobody has any plans to implement that any time soon. My comments are on the tor ticket at https://trac.torproject.org/projects/tor/ticket/15729

In the Ricochet case, I'm not sure it would be very useful, because it requires an online client to constantly broadcast the revocation. I'm not sure what we could do here that would have even a reasonable chance of working.

[ggondim]

+1 for the idea.

So we can invert the implementation: if there is no possibility to exist a client that broadcasts revocation, a Ricochet client may be always emitting a valid ping, and then if a valid ping is not emitted, the address is compromised and revocated.

[HulaHoopWhonix]

Actually Tor supports multi-party authenticated access to a HS using:

HidServAuth onion-address auth-cookie [service-name]

A unique cookie that can be revoked could be generated for any arbitary number of clients/groups. Though a group size in some instances is limited. What this torrc option does is guarantee no knowledge of a hidden service or access to it without the shared symmetric secret.

Read more: https://www.torproject.org/docs/tor-manual.html.en

This would directly conflict with the proposed feature in https://github.com/ricochet-im/ricochet/issues/333

There is no reason not to support both features of the Tor protocol, providing a usable friendly mode and a paranoid mode for extra security.

[special]

@ggondim The goal with revocation is to declare that a key should no longer be trusted. We have to assume that an adversary would be able to sign and broadcast valid pings, too. And, of course, we can't assume that any interruption in pings is a compromise - it's much more likely that the peer just shut off their laptop.

@HulaHoopWhonix This is discussing how to revoke our own key if it may have been compromised, so peers won't trust it again. Hidden service authentication is useful for when we want to revoke a peer's access to our service. Also useful, but it's a different topic.