Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better resync of conversations needed #23

Open
f-r00t opened this issue Aug 15, 2022 · 1 comment
Open

Better resync of conversations needed #23

f-r00t opened this issue Aug 15, 2022 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@f-r00t
Copy link
Member

f-r00t commented Aug 15, 2022

If Alice wants to start a conversation with Bob. She will need Bob's message key and XKR-address. Then she can use the message key to encrypt an initial message using a NaCl sealedbox that can be decrypted by Bob using only using his private key. In this first message, Alice will have to append her message key and XKR-address in order to enable Bob to make a response using a NaCl box.

Currently, the first reply back to Alice from Bob will be sent using a NaCl box, that can only be decrypted by Alice if she has saved Bob's public key in her keychain. Bob's public key isn't appended to any message, meaning that if Alice tries to resync her account, she will never find this conversation.

There are a couple of ways to mitigate these issues:

  1. In the example above, Bob could instead of sending a message using a box (that again, requires Alice to keep track of Bob's public key "manually"), Bob could send his first reply with a sealedbox (with his message key and XKR-address appended to the message) making Alice able to retrieve the conversation at a later resync of her account. The issue with this solution is that the conversation is lost to Alice if Bob does not adhere to the protocol of sending a sealedbox back after first contact, or if he doesn't answer at all. Both solution 2 & 3 solves this issue.

  2. You could make away with sealedboxes altogether, and instead take the shared secret of a regular XKR-transaction that is available to both parties, and use this shared secret as a key for a NaCl secretbox. This way Alice and Bob can use the shared secret from XKR to encrypt messages to each other in the future. One advantage to this is that the first contact is in indiscernible from a regular XKR-transaction, storing it in the blockchain forever. That's awesome, because Hugin Caches might not store all messages forever (and neither should they) making some conversation potentially lost forever once the last Hugin Cache forgets about the initial message, unless you manually back the keys up yourself.

  3. The most 'hacky' solution is for Alice to just send herself a memo about the first contact to herself. I.e. Alice sends an encrypted message to Bob with her key & address appended, Alice also sends herself an encrypted message with Bob's key & message appended. This way she is able to restore the conversation whether Bob answers or not.

I propose we implement solution 1 asap, because it will solve most practical issues we're currently having and then work towards solution 2. Solution 3 is all right, but is both hacky and requires some work to make it functional, whereas solution 1 can be implemented almost immediately.

@f-r00t f-r00t added the enhancement New feature or request label Aug 15, 2022
@f-r00t f-r00t self-assigned this Aug 15, 2022
@f-r00t
Copy link
Member Author

f-r00t commented Aug 15, 2022

Implemented solution 1 in 736098f, leaving issue open for further discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant