nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-13 23:39:08 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Remove the temporary identity because the event already includes the public key of the publisher (in this case, the temporary identity). Therefore, it is not necessary to reiterate it in the message body. Thanks to DreaminglySimple's advice:

Browse Source 
https://www.reddit.com/r/nostr/comments/1446mjp/secure_communication_with_deniability_for_nostr/

Signed-off-by: HardenedVault <root@hardenedvault.net>
This commit is contained in:
HardenedVault 2023-06-10 04:40:05 +03:00
parent 10321ed061
commit 474c16cd0c
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
1317.md
View File

@ -20,9 +20,9 @@ Because all event in the NIP-04 messaging protocol are signed by the sender/publ
Let **G** represent the generator of the elliptic curve secp256k1, and if **k** is a private key, then **kG** is the corresponding public key.
When Alice, who holds the private key **a**, and has generated **a'**, wants to introduce her temporary identity **a'G** to Bob, who holds the private key **b**, for instant messaging, she first obtains Bob's public key **bG**, and then generates a message `msg(a)` with a content like: **`I am <aG> and I would like to use the temporary identity p=<a'G> to communicate with you.`** This can be called a "secret conversation invitation". Using **a** and **bG** for DH to generate a shared secret **abG = a*bG**, Alice generates a message authentication code `mac(abG, msg(a))` for `msg(a)` and combines them into `<msg(a)>?mac=<mac(abG, msg(a))>` format. After encrypted via the aforementioned scheme, the message is sent to `bG` through `a'G`.
When Alice, who holds the private key **a**, and has generated **a'**, wants to introduce her temporary identity **a'G** to Bob, who holds the private key **b**, for instant messaging, she first obtains Bob's public key **bG**, and then generates a message `msg(a)` with a content like: **`I am <aG> and I would like to use this temporary identity to communicate with you.`** This can be called a "secret conversation invitation". Using **a** and **bG** for DH to generate a shared secret **abG = a*bG**, Alice generates a message authentication code `mac(abG, msg(a))` for `msg(a)` and combines them into `<msg(a)>?mac=<mac(abG, msg(a))>` format. After encrypted via the aforementioned scheme, the message is sent to `bG` through `a'G`.
When Bob receives and decrypts the message, verifies it using **b** and **aG** for DH to generate a shared secret **abG = b*aG**, and decides to respond to Alice's request, he generates a private key **b'** for the temporary identity and generates a message `msg(b)` with a content like: **`I am <bG> and I will use the temporary identity p=<b'G> to communicate with you.`** This can be called a "secret conversation invitation response". Using `abG` for `msg(b)`, Bob generates a message authentication code `mac(abG, msg(b))` and combines them into `<msg(b)>?mac=<mac(abG, msg(b))>` format. After encryption using the aforementioned scheme, the message is sent to **a'G** through **b'G**.
When Bob receives and decrypts the message, verifies it using **b** and **aG** for DH to generate a shared secret **abG = b*aG**, and decides to respond to Alice's request, he generates a private key **b'** for the temporary identity and generates a message `msg(b)` with a content like: **`I am <bG> and I will use this temporary identity to communicate with you.`** This can be called a "secret conversation invitation response". Using `abG` for `msg(b)`, Bob generates a message authentication code `mac(abG, msg(b))` and combines them into `<msg(b)>?mac=<mac(abG, msg(b))>` format. After encryption using the aforementioned scheme, the message is sent to **a'G** through **b'G**.
Alice receives and decrypts the message, verifies it using **abG**, and then both parties can use **a'G** and **b'G** for subsequent communication, possibly using more advanced "custom" protocol (see below). Other parties who cannot decrypt the message cannot determine the relationship between **a'G, b'G, aG, and bG**.