Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
NIP-104: Double Ratchet (End-to-End Encrypted) DMs #1206
base: master
Are you sure you want to change the base?
NIP-104: Double Ratchet (End-to-End Encrypted) DMs #1206
Changes from 2 commits
cb180e1
2169fab
3fd653e
79ed7ab
ba2b22a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding a tldr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Define RK, CKs, CKr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change the tag to
recipient_prekey
to make it more clear?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When sharing the key between clients/devices, do we also need to share the current rachet state (
current_index
,previous_length
)? Or should a new client start from 0?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This DOES NOT work out of the box on multiple clients or devices. Each client/device combo should be thought of as a different "inbox" that will have it's own initial setup and will maintain it's own set of chains/keys for each conversation with another person. At a very high level, say I have Primal on iOS and Amethyst on Android and you have just Amethyst on Android. You're client would have to know that it's having the same conversation with two device-clients but using different sets of keys/chains. It would encrypt each message you send for each recipient and then publish those GW events separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is similar to how this sort of scheme works for group conversations as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@staab @paulmillr high level description of multiple devices question here... ☝️
you can also read more about how signal does it here: https://www.signal.org/docs/specifications/sesame/
I want to read up a bit more before committing to any path here. In an ideal world we have multi-device conversations, it's significantly more complex for clients. From the beginning I viewed this more as a solution that a dedicated secure messaging client would be using, and less as the normal standard for DMs in social clients. That said, nothing stopping those clients from implementing it, just a question of making the UI good enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that is the case, then I would add a:
Clients MUST not re-use/re-import keys from other clients or devices. The Key is not supposed to leave the app/device it was created from.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. I need to make this whole device/client limitation more clear in the NIP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clients MUST check if the
pubkey
of kind443
and444
is the same as the Seal's, kind13
, pubkey. Otherwise, impersonators can impersonate. :)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clients MUST verify the
prekey_sig
before accepting this event.This allows anyone out there to copy the
prekey_sig
string and resign it under their own main nostr keys. Shouldn't the signature be a hash of(nostr.pubkey || prekey.pubkey)
to avoid the shenanigans of just reusing somebody else's key?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my demo I'm verifying the signature, but I'll make it clear that it's a
MUST
.Since the prekey has the signature of the user's nostr identity key in the
sig
field, and the signed value in theprekey_sig
tag value, I think you're covered there from imposters? But maybe not? Maybe you can elaborate a little on what you're thinking here?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. As it is today, one can just copy any other user's prekey tag and it will be valid. They won't have the private key so maybe they can't do anything with it, but there might be a social attack somewhere. The event doesn't prove the prekey is linked with the main key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. that's a good point. I was thinking validation of the event + validation of the prekey signature would be enough but you're right, they aren't technically linked and it's easy to link them.
I don't think it's strictly necessary given how we do the multiple pairs of DH calculations in the initial key exchange (which does require private key signatures from both the prekey and the identity key) to derive the initial root key but it certainly wouldn't hurt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do the other protocols (Signal and OMEMO) address this issue? Do they rely on at least one client to be online with the full history to relay it to the new client?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, in most cases that I've seen there is no historic conversation syncing via the protocol. With some of them there is a way to download/backup chat history and then load that into a new client (Signal does this) but it's not syncing conversations between devices ever.
One thought I had about this was that if Blossom becomes something then it would be a way that we could sync this chat data but I think that's still too early to tell...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://conversations.im/ suggests "If you are installing Conversations on a new device or catching up after being offline for a while, Conversations will use XEP-0313: Message Archive Management to fetch the message history from your server.". Do they mean that it is a new device with the same private key loaded from an old device?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signal does not address the issue. Signal can't download historical messages and doesn't have sync (besides a very trivial one, phone-to-desktop-web that relies on phone-to-web pairing and LAN webservers)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's partially true. They don't handle syncing but they do have a mechanism to back up the history and then load that file into a new device (done via bluetooth) https://support.signal.org/hc/en-us/articles/360007059752-Backup-and-Restore-Messages
@AndySchroder No idea. I think we have to approach the syncing question from first principles based on how Nostr works instead of just trying to copy whatever XMPP is doing.