Forward Secrecy

In my opinion, public chat history is more interesting to users (so that they have some context when joinining a public chat) than 1:1 chat, but I might be wrong. Pinging @patrick regarding a survey. On the other hand, there will also be the case of group chats in the future…

1 Like

For multiple devices, would it make sense to have a command where you can ask from a 2nd device to sync from your 1st device, so that you have the complete history, as well that the double ratchet state for each chat restored to the 2nd device? In short:

  1. I install Status Desktop on my laptop;
  2. I ask it to sync my account from my phone;
  3. My phone does a secure pairing sequence where it asks me whether I want to allow the sync;
  4. Desktop gets all the information it needs through a secure channel, and it now has the same state as the phone.
1 Like


yes, you need an initial sync so that the device is “authorized” ( you can transfer the history but you might need to force some Acks from the new device to keep ratcheting, as otherwise we only ratchet on one side, and we lose forward secrecy, but these are probably details).

For new conversations sharing state is tricky as effectively you would need to share state every time you send a message between the two devices, (I generate a private key with each message sent, but I need to share that with the desktop app, but can’t send it otherwise I don’t have forward secrecy, as if I compromise this message I will be able to decrypt the next message sent by the other peer).

One way (signal’s way), is to have one double ratchet between A1 & B, one double ratchet between A2 & B and one between A1 & A2, so that everytime you sent a message you send it to all the devices involved, at the cost of bandwidth/cpu.


start by saying I know nothing about coding. I was just reading this string and had a thought about the issue of recovering messages in a private chat after doing an account recovery. I recently did a recovery of my account to test the recovery seed phrase, so I saw how you lose all contacts and all history of messages. I agree that backing up the messages kind of defeats the purpose of privacy in the messages. That said my history of messages are still on the other side of the conversation, i.e. on my friend’s phone. So if I do a full recovery I have to reconnect with my contacts, that is good and not a problem, kind of expected when you have to recover an account. Would it be possible to build a tool in the 1 to 1 chat where once I reconnect with my contact, he/she can send me a message that contains all our previous chats? Maybe data limited but it will get back a lot of recent (aka most valuable) history of our conversation. This would mean I don’t have to back up all conversation and lose privacy but once I reconnect with my contact we use the same privacy tool we use to communicate in Status and they send me the history of our conversation that is on their phone.

Again, I apologize if what I am saying is crazy because I do not know how to code. :wink:


@Chopstick00 thanks for contributing in the discussion!

The issue with recovering messages in that way is that anyone who manages to get hold of your private key (when you recover an account your are re-creating your private key), will have access to all the messages, as it would be trivial to impersonate you. The method you described has some nice properties but for the purpose of this discussion is equivalent to any backup strategy.

This is incompatible with forward secrecy as the compromise of 1 key (your private key), will give an attacker access to messages from different sessions.

As far as I know, secure messaging apps tend not to store backups, from most secure to least:

  1. Signal allows you to create one locally, but you’d have to move it to the new device yourself, it is never transmitted over the wire
  2. Telegram (mind that it does not follow the “secure by default” philosophy), allows you to store encrypted backups only for non-secure chats
  3. Whatsapp/messenger etc store backups in a unsecure way, over the wire, in cloud storage services (as demonstrated recently by the Paul Manaford’s case) is a good example of the properties we are after.

1 Like

Very interesting idea for solving the history problem! Thanks for contribute with discussion.

We are building Identity with Friends Recovery, and this could be used as additional feature.

Basically the idea is then when Friends Recovery complete, and Identity is recovered, Status Wallet could request the backup history of 1:1 chat. I don’t think this should be automatic, but an action that require both participants to be online and agreement from history source.

About devices sync, I think we should support, can be whisper private messaging, so the history source encrypts to devices public key and send through whisper.


@cammellos, thanks for the wiki article on forward secrecy. I did not fully understand it. So basically to be completely forward secret the past conversations can not be re-sent/deciphered, even if someone has your private key. So the goal, if I understand correctly, is to make the messaging app more secure than a Trezor or even a cold wallet for crypto. My understanding is if someone gets the private key to my Trezor then they can take my funds. So here speaking as an end user and coding neophyte, I would never expect my messaging to be more secure than my wallet, in fact the best case for my expectations would be for it to match the security of my wallet.

But I also understand I am not a Chinese dissident sending jokes to my friends about how President Xi looks like Whinnie the Pooh. :grinning: In that case I may want my text messages to be more secure than my wallet. This is sounding like the conversation about Ludicrous mode (@oskarth) and different end users having varying expectations. Maybe in Ludicrous mode you have Perfect Forward Secrecy and if I am part of leading a revolution in Egypt I understand that if I have to do a full recovery of my account from my seed phrase then all contacts and past conversations are automatically lost. In fact I would consider it a benefit if that was the case. In the event that I found myself in that situation and became a prisoner to the state, when they get out the wrench to get my seed phrase out of me, then I don’t need to take any blows from the wrench, just give up the seed phrase and when they restore the account all is gone.

All that said, for those of us who hope and pray we are never in need of Ludicrous mode and more likely will need to restore our account because we dropped the phone in the toilet while looking at social media; for those users, being able to get back my contacts would be valuable and again I think this users expectation of security is that if it matches my Trezor, I am pretty happy. I get it that if you have my private key you have any funds I have in my Trezor.

There was an interesting article on Medium about hiding your Trezor Wallets with multiple passphrases. Maybe there is a way to implement Ludicrous mode in a similar way, it being one of your “deeper wallets” inside your account. This way you only tell your Xi and Pooh jokes inside the Ludicrous level of your account. The rest of your account looks like a normal Xi loving citizen.

Here is the article:

Thanks again for responding and I have the utmost respect for your knowledge and ability to make things that I can only dream of become a reality.

One thing, impersonating me would not be trivial!! :grinning::+1:t4:


Thanks for the great comments, @Chopstick00! I think one distinction that must be made between the hardware wallet and communications is that the 3rd party can perform surveillance of the communications 100% of the time, without your knowledge, whereas that is not the case with a hardware wallet. That being said, we will be meeting this week to discuss Chat security and the association of Ludicrous Mode and PFS will certainly be a subject of the conversation. :+1:


@Chopstick00 your argument for the wallet is a very strong point and something that troubled me as well.

in addition to @pedro s point.

I don’t have a strong counterpoint to that but I have a few scattered ones:

  1. I agree with you that is a matter of expectations, if you installed Status to have a wallet and send/receive funds, you probably would expect that a wallet/account recovery to recover messages.
    if on the other hand you installed status as a secure messaging app, then automatic backup on by default might not be expected.

  2. At the moment you are highlighting a weakness (in my opinion) in the current way the app handles this 2 features, wallet/messaging: We couple wallet and chat, using the same key for both.
    Ideally I think we should move away from this, allowing the user to have 1 chat & multiple wallets for example ( or the opposite).
    Also it forces you to give away wallet information (therefore which transactions happened), every time you want to communicate with someone new, I can’t think this is a desirable feature.
    Having separate keys allows you to choose which information you want to share with whom, at the cost of usability.
    Generalizing I feel we should try to avoid coupling wallet & chat requirements, as it might not always be the case that we use the same key.

  3. Forward Secrecy is also a safe measure or the receiving end, not only for the sender ( think about a dissident contacting a journalist), having it on by default would prevent forcing ( or even just having) a lower level of security onto the receiving user.

  4. every time you send a message signed with your private key, you give away some cyphertext that can be used in attacks against your private key, so minimizing this is desirable (this is more to do with plausible deniability). having said that, there are no known attacks against rsa at the moment (dsa had this weakness), and also this is partially unavoidable as transaction needs to be signed . Messages are though a whole different scenario as it s much easier for an attacker to force arbitrarly encrypted cyphertext to be sent.

full disclosure I am not a big fan of having a revolution mode, (incognito mode in chrome is a ux failure ino), i am more for secure by default, with individual settings that can be tweeked to achieve more or less security, as for most people security is something they don’t know they needed until the did :slight_smile: but that’s for a different discussion.

again, thanks for the very insightful comments!


A few days ago, @arnetheduck posted a link to Wire messenger whitepaper:

It describes how they implemented forward secrecy and it might be a good source of ideas. Of course, they approach relies on a server.

1 Like

@adam thanks for the link, I just had a quick read through the paper, they seem to be using the signal protocol (Axolot / double ratchet), with a simplied/weaker version of X3DH ( which is the actual bit that requires server side storage, and in our case is a bit tricky to implement)

1 Like

@cammellos thanks for the detailed response. I feel like my learning of the subject is happening exponentially in just this conversation.

I think you are correct in the position of Status should be security by default. If someone does not desire security they could just use WeChat, Telegram or any of the other apps that has not done it right yet. So maybe we are all thinking in the wrong direction. Maybe what everyone is calling Ludicrous or Revolution Mode should be default by design and the options should all be to lower security or provide simpler user interface. This is a great point, in that the community and developers need to all have an agreement on the basis of the app and work from there.

I really like your idea in item 2 above about having separate keys for the wallet and the chat. This kind of sounds like it would provide some of the functionality discussed in the Trezor article.

So lets go! I am on Team Forward Secrecy and separate keys by default. Convinced and sold. :slight_smile:


Forgot to mention in the previous post, @Chopstick00, the link you sent for the Trezor wallet, that is actually easyish to implement in status and seems like a good idea ( basically if you get the password wrong, it will just open a new empty account, this kind of feature might make sense not to be enabled by default as it can be very confusing to the user if you are not aware of it).
We will be definitely discussing this and see whether to push forward, thank you!

1 Like

@ricardo3 I agree, it has to be something that both parties agree to. In fact the control of the release of the information is essentially at the will of the 1:1 chat member that is not going through recovery. So if I want to recover my conversation with my contact, I must reach out that contact outside of Status and get them to approve the release of the conversation. So the non-restoring party receives a warning; do not release history unless you have confirmed the other user via a second method outside of Status, this will avoid the identity problem, a kind of two factor authentication.
Again based on my recent education from @cammellos this whole process should not be default and default should by PFS. There are people with whom I would want to be able to recover at the cost of security and those that I would accept not being able to recover based on desire for maximum security.


Hey John! This is exactly the reason why we’re holding an in-person meeting later this week to try to nail down what are the principles we want to uphold with Status chat: Chat risk management/Product principles meetup Switzerland.

Our goal is to update that thread as we go along so that the community can follow and hopefully feed their thoughts/concerns/expectations into the conversation.

1 Like

@pedro wish I could be there. :slight_smile: Have a great time and so excited to watch this happen.

1 Like

Hi all. Apologies for the late follow up on this thread and special thanks to @Chopstick00 for chiming in with observations and insights from his own use. As mentioned multiple times, we’ll have a chance to discuss FS today and tomorrow at the risk management meetup in Basel but wanted to respond re: surveying users about chat history.

@pedro while it is certainly possible to do, this conversation already highlights that there are going to be different motivations for different types of users coming to Status to try and complete different tasks. E.g., there’s quite a difference between the Chinese dissident starting a 1:1 chat with a journalist and me trying to convince my wife to use Status for our 1:1 to chats. We could run surveys to try and get an understanding of how and when it’s most important for users to have chat history in 1:1 vs group chat but those surveys would need to be well crafted and highly precise in terms of who we are surveying and for what contexts before I would trust results. Even then am not sure I would trust those results in isolation for making decisions.

I’m also quite new to most of the technical details outlined here but it seems like the common question(s) we’re returning to is of what modes (or settings) do we set/start by default when a user creates an account? Or can we provide a flexible way for people to decide what mode to use through onboarding or education when they first start to use?

Generally, I would also recommend against inconsistencies in functionalities for chat history. Meaning that it would be pretty confusing for users to have public chat history available and not private chat after recovery and would argue to have one or the other depending on the level of necessary security for a user. I’d also bet that even the most active users of the highly secure mode/settings will forget that their 1:1 chats will be wiped on account recovery. Which might be the right behavior for that type of user but not others.

Again, thanks all for the great discussion.


The Chat Team regrouped today and discussed some of the points raised in Basel along with other areas of importance and agreed to prioritize PFS.

1 Like

FWIW I’m +1 on most secure by default and let the user ease it up by choice.

Status as an organization and brand could position itself as an ambassador to the general public about good data security hygeine in the modern age.

A lot of people feel creeped out by the current data collection economy, and don’t like the negative affects of their data leaking around all over the place but feel too powerless to do anything about it, which leads to apathy and just giving in. They think only leet hackers could possibly be safe. Many of them would adopt good practices if someone were to just tell them precisely what to do and made it easy for them.

Status has a really good opportunity to reach these people by using the app to guide them into good data hygeine by explaining in simple terms how and why all the things work the way they do.

Then, armed with that knowledge, and the confidence about their control over their own data, they can make an informed decision to give that up for convenience to various degrees.

Once those people are trained in good practices they will convince their friends to do it too. I’ve personally seen how when people start using Signal and understand why, they start to feel unsafe using SMS.


Not convinced about the “lift off phase”.

“Secure by default” and “secure messenger” imply that we’re giving security a priority - implementing a way for users to send non-pfs messages counters this.

It’s hard enough as it is to teach users what “secure” means - effectively, I’d be wary to say we support PFS (or “secure messaging”) until all ways to send actual messages are protected (not even considering metadata leaks here) - “we mostly support PFS except when X, Y and Z” is a pretty weak statement, and is bound to sow confusion. We’re already having trouble ourselves understanding what the properties of our current messaging are (for example, it’s not “secure” by 2018 standards, not even in the context of “normal” messengers)…

How about simply disabling async messaging until we have a proper key exchange / distributed X3DH in place? Having a half-baked solution in seems like a crutch that will delay a proper solution - it still needs to be implemented, tested, deployed, potentially audited and bugfixed, and it will pollute the protocol - can we avoid this with a more simple solution at the cost of some UX?

As discussed in Basel, I like the idea of splitting up the problem into its constituent pieces and attacking these pieces separately. This means Identity/Key Exchange, Ratcheting and Backups/Multi-devices can be attacked completely separate from each other, making sure that each part of the problem receives the attention it deserves. For implementation plan, it means that black-boxing or delaying x3dh, backups and all that for later and focusing on the best ratcheting we can come up with, for example. This way, we start with the clean slate of a PFS-enabled protocol, and enhance it to support the other features, making sure that each step along the way maintains PFS and other security properties we’re interested in.