You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered: