Optional parentProtected createProtected getFor NIP44v2 encryption, we experimented with several ways to determine the conversationKey with the goal of not leaking sender or receiver profile information and having as little information as possible visible in the event that could be used to attack the encryption.
METHOD 1: derives public key same as the signerKey (becomes pubkey on event)
pros: a different public key is used event.
cons: the public key is visible in the event.
METHOD 2: uses the parent key
pros: public key is not visible on the event.
cons: uses the same publicKey all the time.
METHOD 3: derives public key negative of the docIndex
pros: uses different public key and not visible on the event.
cons: might seem arbitrary and confuse code reviewers
We are currently using METHOD 3, but left the other methods in the source code commented.
Optional event: Event<number>Protected read
The sender creates an HDKey (senderXPriv) and sends the public extended key (senderXPub) to the receiver using a Notification.
The receiver creates an HDKey (receiverXPriv) and sends the public extended key to the sender (receiverXPub) using a Notification.
The sender computes the nip44v2 conversationKey with senderXPriv/(HARDENED_OFFSET-created_at) and senderXPub/created_at.
The event is signed with the senderXPriv/created_at.
The receiver does the same in reverse. The intent is to have the converstionKey generated fresh on each event and have no key visible in the event, public or private, that identifies the sender, the receiver, or the any key used to calculate the nip44v2 conversationKey.
The event is given an #e tag of sha256(receiverXPub/1/1). The intent is to make the mesage identifiable to the sender and the receiver, but meaningless, unreadable, and unidentifiable to an outside data snooper.
USE CASE: direct messages