From 9628c59c378ede5d33c4bcd733b7a35bd46551d5 Mon Sep 17 00:00:00 2001 From: highperfocused Date: Sun, 20 Apr 2025 22:26:50 +0200 Subject: [PATCH] add nips for chat --- .github/prompts/nostr-nip17.prompt.md | 210 ++++++++++++++++++ .github/prompts/nostr-nip44.prompt.md | 297 ++++++++++++++++++++++++++ .github/prompts/nostr-nip59.prompt.md | 252 ++++++++++++++++++++++ 3 files changed, 759 insertions(+) create mode 100644 .github/prompts/nostr-nip17.prompt.md create mode 100644 .github/prompts/nostr-nip44.prompt.md create mode 100644 .github/prompts/nostr-nip59.prompt.md diff --git a/.github/prompts/nostr-nip17.prompt.md b/.github/prompts/nostr-nip17.prompt.md new file mode 100644 index 0000000..a37407b --- /dev/null +++ b/.github/prompts/nostr-nip17.prompt.md @@ -0,0 +1,210 @@ +NIP-17 +====== + +Private Direct Messages +----------------------- + +`draft` `optional` + +This NIP defines an encrypted direct messaging scheme using [NIP-44](44.md) encryption and [NIP-59](59.md) seals and gift wraps. + +## Direct Message Kind + +Kind `14` is a chat message. `p` tags identify one or more receivers of the message. + +```jsonc +{ + "id": "", +  "pubkey": "", + "created_at": "", +  "kind": 14, +  "tags": [ +    ["p", "", ""], +    ["p", "", ""], +    ["e", "", ""] // if this is a reply + ["subject", ""], +    // rest of tags... +  ], +  "content": "", +} +``` + +`.content` MUST be plain text. Fields `id` and `created_at` are required. + +An `e` tag denotes the direct parent message this post is replying to. + +`q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md). + +```json +["q", " or ", "", ""] +``` + +Kind `14`s MUST never be signed. If it is signed, the message might leak to relays and become **fully public**. + +## File Message Kind + +```jsonc +{ + "id": "", + "pubkey": "", + "created_at": "", + "kind": 15, + "tags": [ + ["p", "", ""], + ["p", "", ""], + ["e", "", "", "reply"], // if this is a reply + ["subject", ""], + ["file-type", ""], + ["encryption-algorithm", ""], + ["decryption-key", ""], + ["decryption-nonce", ""], + ["x", ""], + // rest of tags... + ], + "content": "" +} +``` + +Kind 15 is used for sending encrypted file event messages: + +- `file-type`: Specifies the MIME type of the attached file (e.g., `image/jpeg`, `audio/mpeg`, etc.). +- `encryption-algorithm`: Indicates the encryption algorithm used for encrypting the file. Supported algorithms may include `aes-gcm`, `chacha20-poly1305`,`aes-cbc` etc. +- `decryption-key`: The decryption key that will be used by the recipient to decrypt the file. +- `decryption-nonce`: The decryption nonce that will be used by the recipient to decrypt the file. +- `content`: The URL of the file (``). +- `x` containing the SHA-256 hexencoded string of the file. +- `size` (optional) size of file in bytes +- `dim` (optional) size of the file in pixels in the form `x` +- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the client is loading the file +- `thumb` (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce) +- `fallback` (optional) zero or more fallback file sources in case `url` fails + +Just like kind 14, kind `15`s MUST never be signed. + +## Chat Rooms + +The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with a clean message history. + +Clients SHOULD render messages of the same room in a continuous thread. + +An optional `subject` tag defines the current name/topic of the conversation. Any member can change the topic by simply submitting a new `subject` to an existing `pubkey` + `p`-tags room. There is no need to send `subject` in every message. The newest `subject` in the thread is the subject of the conversation. + +## Encrypting + +Following [NIP-59](59.md), the **unsigned** `kind:14` & `kind:15` chat messages must be sealed (`kind:13`) and then gift-wrapped (`kind:1059`) to each receiver and the sender individually. + +```jsonc +{ + "id": "", +  "pubkey": randomPublicKey, +  "created_at": randomTimeUpTo2DaysInThePast(), + "kind": 1059, // gift wrap +  "tags": [ +    ["p", receiverPublicKey, ""] // receiver +  ], +  "content": nip44Encrypt( +    { + "id": "", +      "pubkey": senderPublicKey, +      "created_at": randomTimeUpTo2DaysInThePast(), +      "kind": 13, // seal +      "tags": [], // no tags +      "content": nip44Encrypt(unsignedKind14, senderPrivateKey, receiverPublicKey), +      "sig": "" +    }, +    randomPrivateKey, receiverPublicKey +  ), +  "sig": "" +} +``` + +The encryption algorithm MUST use the latest version of [NIP-44](44.md). + +Clients MUST verify if pubkey of the `kind:13` is the same pubkey on the `kind:14`, otherwise any sender can impersonate others by simply changing the pubkey on `kind:14`. + +Clients SHOULD randomize `created_at` in up to two days in the past in both the seal and the gift wrap to make sure grouping by `created_at` doesn't reveal any metadata. + +The gift wrap's `p`-tag can be the receiver's main pubkey or an alias key created to receive DMs without exposing the receiver's identity. + +Clients CAN offer disappearing messages by setting an `expiration` tag in the gift wrap of each receiver or by not generating a gift wrap to the sender's public key + +## Publishing + +Kind `10050` indicates the user's preferred relays to receive DMs. The event MUST include a list of `relay` tags with relay URIs. + +```jsonc +{ + "kind": 10050, + "tags": [ + ["relay", "wss://inbox.nostr.wine"], + ["relay", "wss://myrelay.nostr1.com"], + ], + "content": "", + // other fields... +} +``` + +Clients SHOULD publish kind `14` events to the `10050`-listed relays. If that is not found that indicates the user is not ready to receive messages under this NIP and clients shouldn't try. + +## Relays + +It's advisable that relays do not serve `kind:1059` to clients other than the ones tagged in them. + +It's advisable that users choose relays that conform to these practices. + +Clients SHOULD guide users to keep `kind:10050` lists small (1-3 relays) and SHOULD spread it to as many relays as viable. + +## Benefits & Limitations + +This NIP offers the following privacy and security features: + +1. **No Metadata Leak**: Participant identities, each message's real date and time, event kinds, and other event tags are all hidden from the public. Senders and receivers cannot be linked with public information alone. +2. **No Public Group Identifiers**: There is no public central queue, channel or otherwise converging identifier to correlate or count all messages in the same group. +3. **No Moderation**: There are no group admins: no invitations or bans. +4. **No Shared Secrets**: No secret must be known to all members that can leak or be mistakenly shared +5. **Fully Recoverable**: Messages can be fully recoverable by any client with the user's private key +6. **Optional Forward Secrecy**: Users and clients can opt-in for "disappearing messages". +7. **Uses Public Relays**: Messages can flow through public relays without loss of privacy. Private relays can increase privacy further, but they are not required. +8. **Cold Storage**: Users can unilaterally opt-in to sharing their messages with a separate key that is exclusive for DM backup and recovery. + +The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme. + +## Implementation + +Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast. + +When sending a message to anyone, clients must then connect to the relays in the receiver's `kind:10050` and send the events there but can disconnect right after unless more messages are expected to be sent (e.g. the chat tab is still selected). Clients should also send a copy of their outgoing messages to their own `kind:10050` relay set. + +## Examples + +This example sends the message `Hola, que tal?` from `nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m` to `nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt`. + +The two final GiftWraps, one to the receiver and the other to the sender, respectively, are: + +```json +{ + "id":"2886780f7349afc1344047524540ee716f7bdc1b64191699855662330bf235d8", + "pubkey":"8f8a7ec43b77d25799281207e1a47f7a654755055788f7482653f9c9661c6d51", + "created_at":1703128320, + "kind":1059, + "tags":[ + [ "p", "918e2da906df4ccd12c8ac672d8335add131a4cf9d27ce42b3bb3625755f0788"] + ], + "content":"AsqzdlMsG304G8h08bE67dhAR1gFTzTckUUyuvndZ8LrGCvwI4pgC3d6hyAK0Wo9gtkLqSr2rT2RyHlE5wRqbCOlQ8WvJEKwqwIJwT5PO3l2RxvGCHDbd1b1o40ZgIVwwLCfOWJ86I5upXe8K5AgpxYTOM1BD+SbgI5jOMA8tgpRoitJedVSvBZsmwAxXM7o7sbOON4MXHzOqOZpALpS2zgBDXSAaYAsTdEM4qqFeik+zTk3+L6NYuftGidqVluicwSGS2viYWr5OiJ1zrj1ERhYSGLpQnPKrqDaDi7R1KrHGFGyLgkJveY/45y0rv9aVIw9IWF11u53cf2CP7akACel2WvZdl1htEwFu/v9cFXD06fNVZjfx3OssKM/uHPE9XvZttQboAvP5UoK6lv9o3d+0GM4/3zP+yO3C0NExz1ZgFmbGFz703YJzM+zpKCOXaZyzPjADXp8qBBeVc5lmJqiCL4solZpxA1865yPigPAZcc9acSUlg23J1dptFK4n3Tl5HfSHP+oZ/QS/SHWbVFCtq7ZMQSRxLgEitfglTNz9P1CnpMwmW/Y4Gm5zdkv0JrdUVrn2UO9ARdHlPsW5ARgDmzaxnJypkfoHXNfxGGXWRk0sKLbz/ipnaQP/eFJv/ibNuSfqL6E4BnN/tHJSHYEaTQ/PdrA2i9laG3vJti3kAl5Ih87ct0w/tzYfp4SRPhEF1zzue9G/16eJEMzwmhQ5Ec7jJVcVGa4RltqnuF8unUu3iSRTQ+/MNNUkK6Mk+YuaJJs6Fjw6tRHuWi57SdKKv7GGkr0zlBUU2Dyo1MwpAqzsCcCTeQSv+8qt4wLf4uhU9Br7F/L0ZY9bFgh6iLDCdB+4iABXyZwT7Ufn762195hrSHcU4Okt0Zns9EeiBOFxnmpXEslYkYBpXw70GmymQfJlFOfoEp93QKCMS2DAEVeI51dJV1e+6t3pCSsQN69Vg6jUCsm1TMxSs2VX4BRbq562+VffchvW2BB4gMjsvHVUSRl8i5/ZSDlfzSPXcSGALLHBRzy+gn0oXXJ/447VHYZJDL3Ig8+QW5oFMgnWYhuwI5QSLEyflUrfSz+Pdwn/5eyjybXKJftePBD9Q+8NQ8zulU5sqvsMeIx/bBUx0fmOXsS3vjqCXW5IjkmSUV7q54GewZqTQBlcx+90xh/LSUxXex7UwZwRnifvyCbZ+zwNTHNb12chYeNjMV7kAIr3cGQv8vlOMM8ajyaZ5KVy7HpSXQjz4PGT2/nXbL5jKt8Lx0erGXsSsazkdoYDG3U", + "sig":"a3c6ce632b145c0869423c1afaff4a6d764a9b64dedaf15f170b944ead67227518a72e455567ca1c2a0d187832cecbde7ed478395ec4c95dd3e71749ed66c480" +} +``` + +```json +{ + "id":"162b0611a1911cfcb30f8a5502792b346e535a45658b3a31ae5c178465509721", + "pubkey":"626be2af274b29ea4816ad672ee452b7cf96bbb4836815a55699ae402183f512", + "created_at":1702711587, + "kind":1059, + "tags":[ + [ "p", "44900586091b284416a0c001f677f9c49f7639a55c3f1e2ec130a8e1a7998e1b"] + ], + "content":"AsTClTzr0gzXXji7uye5UB6LYrx3HDjWGdkNaBS6BAX9CpHa+Vvtt5oI2xJrmWLen+Fo2NBOFazvl285Gb3HSM82gVycrzx1HUAaQDUG6HI7XBEGqBhQMUNwNMiN2dnilBMFC3Yc8ehCJT/gkbiNKOpwd2rFibMFRMDKai2mq2lBtPJF18oszKOjA+XlOJV8JRbmcAanTbEK5nA/GnG3eGUiUzhiYBoHomj3vztYYxc0QYHOx0WxiHY8dsC6jPsXC7f6k4P+Hv5ZiyTfzvjkSJOckel1lZuE5SfeZ0nduqTlxREGeBJ8amOykgEIKdH2VZBZB+qtOMc7ez9dz4wffGwBDA7912NFS2dPBr6txHNxBUkDZKFbuD5wijvonZDvfWq43tZspO4NutSokZB99uEiRH8NAUdGTiNb25m9JcDhVfdmABqTg5fIwwTwlem5aXIy8b66lmqqz2LBzJtnJDu36bDwkILph3kmvaKPD8qJXmPQ4yGpxIbYSTCohgt2/I0TKJNmqNvSN+IVoUuC7ZOfUV9lOV8Ri0AMfSr2YsdZ9ofV5o82ClZWlWiSWZwy6ypa7CuT1PEGHzywB4CZ5ucpO60Z7hnBQxHLiAQIO/QhiBp1rmrdQZFN6PUEjFDloykoeHe345Yqy9Ke95HIKUCS9yJurD+nZjjgOxZjoFCsB1hQAwINTIS3FbYOibZnQwv8PXvcSOqVZxC9U0+WuagK7IwxzhGZY3vLRrX01oujiRrevB4xbW7Oxi/Agp7CQGlJXCgmRE8Rhm+Vj2s+wc/4VLNZRHDcwtfejogjrjdi8p6nfUyqoQRRPARzRGUnnCbh+LqhigT6gQf3sVilnydMRScEc0/YYNLWnaw9nbyBa7wFBAiGbJwO40k39wj+xT6HTSbSUgFZzopxroO3f/o4+ubx2+IL3fkev22mEN38+dFmYF3zE+hpE7jVxrJpC3EP9PLoFgFPKCuctMnjXmeHoiGs756N5r1Mm1ffZu4H19MSuALJlxQR7VXE/LzxRXDuaB2u9days/6muP6gbGX1ASxbJd/ou8+viHmSC/ioHzNjItVCPaJjDyc6bv+gs1NPCt0qZ69G+JmgHW/PsMMeL4n5bh74g0fJSHqiI9ewEmOG/8bedSREv2XXtKV39STxPweceIOh0k23s3N6+wvuSUAJE7u1LkDo14cobtZ/MCw/QhimYPd1u5HnEJvRhPxz0nVPz0QqL/YQeOkAYk7uzgeb2yPzJ6DBtnTnGDkglekhVzQBFRJdk740LEj6swkJ", + "sig":"c94e74533b482aa8eeeb54ae72a5303e0b21f62909ca43c8ef06b0357412d6f8a92f96e1a205102753777fd25321a58fba3fb384eee114bd53ce6c06a1c22bab" +} +``` \ No newline at end of file diff --git a/.github/prompts/nostr-nip44.prompt.md b/.github/prompts/nostr-nip44.prompt.md new file mode 100644 index 0000000..cb1d44f --- /dev/null +++ b/.github/prompts/nostr-nip44.prompt.md @@ -0,0 +1,297 @@ +NIP-44 +====== + +Encrypted Payloads (Versioned) +------------------------------ + +`optional` + +The NIP introduces a new data format for keypair-based encryption. This NIP is versioned +to allow multiple algorithm choices to exist simultaneously. This format may be used for +many things, but MUST be used in the context of a signed event as described in NIP-01. + +*Note*: this format DOES NOT define any `kind`s related to a new direct messaging standard, +only the encryption required to define one. It SHOULD NOT be used as a drop-in replacement +for NIP-04 payloads. + +## Versions + +Currently defined encryption algorithms: + +- `0x00` - Reserved +- `0x01` - Deprecated and undefined +- `0x02` - secp256k1 ECDH, HKDF, padding, ChaCha20, HMAC-SHA256, base64 + +## Limitations + +Every nostr user has their own public key, which solves key distribution problems present +in other solutions. However, nostr's relay-based architecture makes it difficult to implement +more robust private messaging protocols with things like metadata hiding, forward secrecy, +and post compromise secrecy. + +The goal of this NIP is to have a _simple_ way to encrypt payloads used in the context of a signed +event. When applying this NIP to any use case, it's important to keep in mind your users' threat +model and this NIP's limitations. For high-risk situations, users should chat in specialized E2EE +messaging software and limit use of nostr to exchanging contacts. + +On its own, messages sent using this scheme have a number of important shortcomings: + +- No deniability: it is possible to prove an event was signed by a particular key +- No forward secrecy: when a key is compromised, it is possible to decrypt all previous conversations +- No post-compromise security: when a key is compromised, it is possible to decrypt all future conversations +- No post-quantum security: a powerful quantum computer would be able to decrypt the messages +- IP address leak: user IP may be seen by relays and all intermediaries between user and relay +- Date leak: `created_at` is public, since it is a part of NIP-01 event +- Limited message size leak: padding only partially obscures true message length +- No attachments: they are not supported + +Lack of forward secrecy may be partially mitigated by only sending messages to trusted relays, and asking +relays to delete stored messages after a certain duration has elapsed. + +## Version 2 + +NIP-44 version 2 has the following design characteristics: + +- Payloads are authenticated using a MAC before signing rather than afterwards because events are assumed + to be signed as specified in NIP-01. The outer signature serves to authenticate the full payload, and MUST + be validated before decrypting. +- ChaCha is used instead of AES because it's faster and has + [better security against multi-key attacks](https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits/). +- ChaCha is used instead of XChaCha because XChaCha has not been standardized. Also, xChaCha's improved collision + resistance of nonces isn't necessary since every message has a new (key, nonce) pair. +- HMAC-SHA256 is used instead of Poly1305 because polynomial MACs are much easier to forge. +- SHA256 is used instead of SHA3 or BLAKE because it is already used in nostr. Also BLAKE's speed advantage + is smaller in non-parallel environments. +- A custom padding scheme is used instead of padmé because it provides better leakage reduction for small messages. +- Base64 encoding is used instead of another encoding algorithm because it is widely available, and is already used in nostr. + +### Encryption + +1. Calculate a conversation key + - Execute ECDH (scalar multiplication) of public key B by private key A + Output `shared_x` must be unhashed, 32-byte encoded x coordinate of the shared point + - Use HKDF-extract with sha256, `IKM=shared_x` and `salt=utf8_encode('nip44-v2')` + - HKDF output will be a `conversation_key` between two users. + - It is always the same, when key roles are swapped: `conv(a, B) == conv(b, A)` +2. Generate a random 32-byte nonce + - Always use [CSPRNG](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator) + - Don't generate a nonce from message content + - Don't re-use the same nonce between messages: doing so would make them decryptable, + but won't leak the long-term key +3. Calculate message keys + - The keys are generated from `conversation_key` and `nonce`. Validate that both are 32 bytes long + - Use HKDF-expand, with sha256, `PRK=conversation_key`, `info=nonce` and `L=76` + - Slice 76-byte HKDF output into: `chacha_key` (bytes 0..32), `chacha_nonce` (bytes 32..44), `hmac_key` (bytes 44..76) +4. Add padding + - Content must be encoded from UTF-8 into byte array + - Validate plaintext length. Minimum is 1 byte, maximum is 65535 bytes + - Padding format is: `[plaintext_length: u16][plaintext][zero_bytes]` + - Padding algorithm is related to powers-of-two, with min padded msg size of 32 bytes + - Plaintext length is encoded in big-endian as first 2 bytes of the padded blob +5. Encrypt padded content + - Use ChaCha20, with key and nonce from step 3 +6. Calculate MAC (message authentication code) + - AAD (additional authenticated data) is used - instead of calculating MAC on ciphertext, + it's calculated over a concatenation of `nonce` and `ciphertext` + - Validate that AAD (nonce) is 32 bytes +7. Base64-encode (with padding) params using `concat(version, nonce, ciphertext, mac)` + +Encrypted payloads MUST be included in an event's payload, hashed, and signed as defined in NIP 01, using schnorr +signature scheme over secp256k1. + +### Decryption + +Before decryption, the event's pubkey and signature MUST be validated as defined in NIP 01. The public key MUST be +a valid non-zero secp256k1 curve point, and the signature must be valid secp256k1 schnorr signature. For exact +validation rules, refer to BIP-340. + +1. Check if first payload's character is `#` + - `#` is an optional future-proof flag that means non-base64 encoding is used + - The `#` is not present in base64 alphabet, but, instead of throwing `base64 is invalid`, + implementations MUST indicate that the encryption version is not yet supported +2. Decode base64 + - Base64 is decoded into `version, nonce, ciphertext, mac` + - If the version is unknown, implementations must indicate that the encryption version is not supported + - Validate length of base64 message to prevent DoS on base64 decoder: it can be in range from 132 to 87472 chars + - Validate length of decoded message to verify output of the decoder: it can be in range from 99 to 65603 bytes +3. Calculate conversation key + - See step 1 of [encryption](#Encryption) +4. Calculate message keys + - See step 3 of [encryption](#Encryption) +5. Calculate MAC (message authentication code) with AAD and compare + - Stop and throw an error if MAC doesn't match the decoded one from step 2 + - Use constant-time comparison algorithm +6. Decrypt ciphertext + - Use ChaCha20 with key and nonce from step 3 +7. Remove padding + - Read the first two BE bytes of plaintext that correspond to plaintext length + - Verify that the length of sliced plaintext matches the value of the two BE bytes + - Verify that calculated padding from step 3 of the [encryption](#Encryption) process matches the actual padding + +### Details + +- Cryptographic methods + - `secure_random_bytes(length)` fetches randomness from CSPRNG. + - `hkdf(IKM, salt, info, L)` represents HKDF [(RFC 5869)](https://datatracker.ietf.org/doc/html/rfc5869) + with SHA256 hash function comprised of methods `hkdf_extract(IKM, salt)` and `hkdf_expand(OKM, info, L)`. + - `chacha20(key, nonce, data)` is ChaCha20 [(RFC 8439)](https://datatracker.ietf.org/doc/html/rfc8439) with + starting counter set to 0. + - `hmac_sha256(key, message)` is HMAC [(RFC 2104)](https://datatracker.ietf.org/doc/html/rfc2104). + - `secp256k1_ecdh(priv_a, pub_b)` is multiplication of point B by scalar a (`a ⋅ B`), defined in + [BIP340](https://github.com/bitcoin/bips/blob/e918b50731397872ad2922a1b08a5a4cd1d6d546/bip-0340.mediawiki). + The operation produces a shared point, and we encode the shared point's 32-byte x coordinate, using method + `bytes(P)` from BIP340. Private and public keys must be validated as per BIP340: pubkey must be a valid, + on-curve point, and private key must be a scalar in range `[1, secp256k1_order - 1]`. + NIP44 doesn't do hashing of the output: keep this in mind, because some libraries hash it using sha256. + As an example, in libsecp256k1, unhashed version is available in `secp256k1_ec_pubkey_tweak_mul` +- Operators + - `x[i:j]`, where `x` is a byte array and `i, j <= 0` returns a `(j - i)`-byte array with a copy of the + `i`-th byte (inclusive) to the `j`-th byte (exclusive) of `x`. +- Constants `c`: + - `min_plaintext_size` is 1. 1 byte msg is padded to 32 bytes. + - `max_plaintext_size` is 65535 (64kB - 1). It is padded to 65536 bytes. +- Functions + - `base64_encode(string)` and `base64_decode(bytes)` are Base64 ([RFC 4648](https://datatracker.ietf.org/doc/html/rfc4648), with padding) + - `concat` refers to byte array concatenation + - `is_equal_ct(a, b)` is constant-time equality check of 2 byte arrays + - `utf8_encode(string)` and `utf8_decode(bytes)` transform string to byte array and back + - `write_u8(number)` restricts number to values 0..255 and encodes into Big-Endian uint8 byte array + - `write_u16_be(number)` restricts number to values 0..65535 and encodes into Big-Endian uint16 byte array + - `zeros(length)` creates byte array of length `length >= 0`, filled with zeros + - `floor(number)` and `log2(number)` are well-known mathematical methods + +### Implementation pseudocode + +The following is a collection of python-like pseudocode functions which implement the above primitives, +intended to guide implementers. A collection of implementations in different languages is available at https://github.com/paulmillr/nip44. + +```py +# Calculates length of the padded byte array. +def calc_padded_len(unpadded_len): + next_power = 1 << (floor(log2(unpadded_len - 1))) + 1 + if next_power <= 256: + chunk = 32 + else: + chunk = next_power / 8 + if unpadded_len <= 32: + return 32 + else: + return chunk * (floor((len - 1) / chunk) + 1) + +# Converts unpadded plaintext to padded bytearray +def pad(plaintext): + unpadded = utf8_encode(plaintext) + unpadded_len = len(plaintext) + if (unpadded_len < c.min_plaintext_size or + unpadded_len > c.max_plaintext_size): raise Exception('invalid plaintext length') + prefix = write_u16_be(unpadded_len) + suffix = zeros(calc_padded_len(unpadded_len) - unpadded_len) + return concat(prefix, unpadded, suffix) + +# Converts padded bytearray to unpadded plaintext +def unpad(padded): + unpadded_len = read_uint16_be(padded[0:2]) + unpadded = padded[2:2+unpadded_len] + if (unpadded_len == 0 or + len(unpadded) != unpadded_len or + len(padded) != 2 + calc_padded_len(unpadded_len)): raise Exception('invalid padding') + return utf8_decode(unpadded) + +# metadata: always 65b (version: 1b, nonce: 32b, max: 32b) +# plaintext: 1b to 0xffff +# padded plaintext: 32b to 0xffff +# ciphertext: 32b+2 to 0xffff+2 +# raw payload: 99 (65+32+2) to 65603 (65+0xffff+2) +# compressed payload (base64): 132b to 87472b +def decode_payload(payload): + plen = len(payload) + if plen == 0 or payload[0] == '#': raise Exception('unknown version') + if plen < 132 or plen > 87472: raise Exception('invalid payload size') + data = base64_decode(payload) + dlen = len(d) + if dlen < 99 or dlen > 65603: raise Exception('invalid data size'); + vers = data[0] + if vers != 2: raise Exception('unknown version ' + vers) + nonce = data[1:33] + ciphertext = data[33:dlen - 32] + mac = data[dlen - 32:dlen] + return (nonce, ciphertext, mac) + +def hmac_aad(key, message, aad): + if len(aad) != 32: raise Exception('AAD associated data must be 32 bytes'); + return hmac(sha256, key, concat(aad, message)); + +# Calculates long-term key between users A and B: `get_key(Apriv, Bpub) == get_key(Bpriv, Apub)` +def get_conversation_key(private_key_a, public_key_b): + shared_x = secp256k1_ecdh(private_key_a, public_key_b) + return hkdf_extract(IKM=shared_x, salt=utf8_encode('nip44-v2')) + +# Calculates unique per-message key +def get_message_keys(conversation_key, nonce): + if len(conversation_key) != 32: raise Exception('invalid conversation_key length') + if len(nonce) != 32: raise Exception('invalid nonce length') + keys = hkdf_expand(OKM=conversation_key, info=nonce, L=76) + chacha_key = keys[0:32] + chacha_nonce = keys[32:44] + hmac_key = keys[44:76] + return (chacha_key, chacha_nonce, hmac_key) + +def encrypt(plaintext, conversation_key, nonce): + (chacha_key, chacha_nonce, hmac_key) = get_message_keys(conversation_key, nonce) + padded = pad(plaintext) + ciphertext = chacha20(key=chacha_key, nonce=chacha_nonce, data=padded) + mac = hmac_aad(key=hmac_key, message=ciphertext, aad=nonce) + return base64_encode(concat(write_u8(2), nonce, ciphertext, mac)) + +def decrypt(payload, conversation_key): + (nonce, ciphertext, mac) = decode_payload(payload) + (chacha_key, chacha_nonce, hmac_key) = get_message_keys(conversation_key, nonce) + calculated_mac = hmac_aad(key=hmac_key, message=ciphertext, aad=nonce) + if not is_equal_ct(calculated_mac, mac): raise Exception('invalid MAC') + padded_plaintext = chacha20(key=chacha_key, nonce=chacha_nonce, data=ciphertext) + return unpad(padded_plaintext) + +# Usage: +# conversation_key = get_conversation_key(sender_privkey, recipient_pubkey) +# nonce = secure_random_bytes(32) +# payload = encrypt('hello world', conversation_key, nonce) +# 'hello world' == decrypt(payload, conversation_key) +``` + +### Audit + +The v2 of the standard was audited by [Cure53](https://cure53.de) in December 2023. +Check out [audit-2023.12.pdf](https://github.com/paulmillr/nip44/blob/ce63c2eaf345e9f7f93b48f829e6bdeb7e7d7964/audit-2023.12.pdf) +and [auditor's website](https://cure53.de/audit-report_nip44-implementations.pdf). + +### Tests and code + +A collection of implementations in different languages is available at https://github.com/paulmillr/nip44. + +We publish extensive test vectors. Instead of having it in the document directly, a sha256 checksum of vectors is provided: + + 269ed0f69e4c192512cc779e78c555090cebc7c785b609e338a62afc3ce25040 nip44.vectors.json + +Example of a test vector from the file: + +```json +{ + "sec1": "0000000000000000000000000000000000000000000000000000000000000001", + "sec2": "0000000000000000000000000000000000000000000000000000000000000002", + "conversation_key": "c41c775356fd92eadc63ff5a0dc1da211b268cbea22316767095b2871ea1412d", + "nonce": "0000000000000000000000000000000000000000000000000000000000000001", + "plaintext": "a", + "payload": "AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABee0G5VSK0/9YypIObAtDKfYEAjD35uVkHyB0F4DwrcNaCXlCWZKaArsGrY6M9wnuTMxWfp1RTN9Xga8no+kF5Vsb" +} +``` + +The file also contains intermediate values. A quick guidance with regards to its usage: + +- `valid.get_conversation_key`: calculate conversation_key from secret key sec1 and public key pub2 +- `valid.get_message_keys`: calculate chacha_key, chacha_nonce, hmac_key from conversation_key and nonce +- `valid.calc_padded_len`: take unpadded length (first value), calculate padded length (second value) +- `valid.encrypt_decrypt`: emulate real conversation. Calculate pub2 from sec2, verify conversation_key from (sec1, pub2), encrypt, verify payload, then calculate pub1 from sec1, verify conversation_key from (sec2, pub1), decrypt, verify plaintext. +- `valid.encrypt_decrypt_long_msg`: same as previous step, but instead of a full plaintext and payload, their checksum is provided. +- `invalid.encrypt_msg_lengths` +- `invalid.get_conversation_key`: calculating conversation_key must throw an error +- `invalid.decrypt`: decrypting message content must throw an error \ No newline at end of file diff --git a/.github/prompts/nostr-nip59.prompt.md b/.github/prompts/nostr-nip59.prompt.md new file mode 100644 index 0000000..c59b0cc --- /dev/null +++ b/.github/prompts/nostr-nip59.prompt.md @@ -0,0 +1,252 @@ +NIP-59 +====== + +Gift Wrap +--------- + +`optional` + +This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata +for a given event, perform collaborative signing, and more. + +This NIP *does not* define any messaging protocol. Applications of this NIP should be defined separately. + +This NIP relies on [NIP-44](./44.md)'s versioned encryption algorithms. + +# Overview + +This protocol uses three main concepts to protect the transmission of a target event: `rumor`s, `seal`s, and `gift wrap`s. + +- A `rumor` is a regular nostr event, but is **not signed**. This means that if it is leaked, it cannot be verified. +- A `rumor` is serialized to JSON, encrypted, and placed in the `content` field of a `seal`. The `seal` is then + signed by the author of the note. The only information publicly available on a `seal` is who signed it, but not what was said. +- A `seal` is serialized to JSON, encrypted, and placed in the `content` field of a `gift wrap`. + +This allows the isolation of concerns across layers: + +- A rumor carries the content but is unsigned, which means if leaked it will be rejected by relays and clients, + and can't be authenticated. This provides a measure of deniability. +- A seal identifies the author without revealing the content or the recipient. +- A gift wrap can add metadata (recipient, tags, a different author) without revealing the true author. + +# Protocol Description + +## 1. The Rumor Event Kind + +A `rumor` is the same thing as an unsigned event. Any event kind can be made a `rumor` by removing the signature. + +## 2. The Seal Event Kind + +A `seal` is a `kind:13` event that wraps a `rumor` with the sender's regular key. The `seal` is **always** encrypted +to a receiver's pubkey but there is no `p` tag pointing to the receiver. There is no way to know who the rumor is for +without the receiver's or the sender's private key. The only public information in this event is who is signing it. + +```json +{ + "id": "", + "pubkey": "", + "content": "", + "kind": 13, + "created_at": 1686840217, + "tags": [], + "sig": "" +} +``` + +Tags MUST always be empty in a `kind:13`. The inner event MUST always be unsigned. + +## 3. Gift Wrap Event Kind + +A `gift wrap` event is a `kind:1059` event that wraps any other event. `tags` SHOULD include any information +needed to route the event to its intended recipient, including the recipient's `p` tag or [NIP-13](13.md) proof of work. + +```json +{ + "id": "", + "pubkey": "", + "content": "", + "kind": 1059, + "created_at": 1686840217, + "tags": [["p", ""]], + "sig": "" +} +``` + +# Encrypting Payloads + +Encryption is done following [NIP-44](44.md) on the JSON-encoded event. Place the encryption payload in the `.content` +of the wrapper event (either a `seal` or a `gift wrap`). + +# Other Considerations + +If a `rumor` is intended for more than one party, or if the author wants to retain an encrypted copy, a single +`rumor` may be wrapped and addressed for each recipient individually. + +The canonical `created_at` time belongs to the `rumor`. All other timestamps SHOULD be tweaked to thwart +time-analysis attacks. Note that some relays don't serve events dated in the future, so all timestamps +SHOULD be in the past. + +Relays may choose not to store gift wrapped events due to them not being publicly useful. Clients MAY choose +to attach a certain amount of proof-of-work to the wrapper event per [NIP-13](13.md) in a bid to demonstrate that +the event is not spam or a denial-of-service attack. + +To protect recipient metadata, relays SHOULD guard access to `kind 1059` events based on user AUTH. When +possible, clients should only send wrapped events to relays that offer this protection. + +To protect recipient metadata, relays SHOULD only serve `kind 1059` events intended for the marked recipient. +When possible, clients should only send wrapped events to `read` relays for the recipient that implement +AUTH, and refuse to serve wrapped events to non-recipients. + +# An Example + +Let's send a wrapped `kind 1` message between two parties asking "Are you going to the party tonight?" + +- Author private key: `0beebd062ec8735f4243466049d7747ef5d6594ee838de147f8aab842b15e273` +- Recipient private key: `e108399bd8424357a710b606ae0c13166d853d327e47a6e5e038197346bdbf45` +- Ephemeral wrapper key: `4f02eac59266002db5801adc5270700ca69d5b8f761d8732fab2fbf233c90cbd` + +Note that this messaging protocol should not be used in practice, this is just an example. Refer to other +NIPs for concrete messaging protocols that depend on gift wraps. + +## 1. Create an event + +Create a `kind 1` event with the message, the receivers, and any other tags you want, signed by the author. +Do not sign the event. + +```json +{ + "created_at": 1691518405, + "content": "Are you going to the party tonight?", + "tags": [], + "kind": 1, + "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9", + "id": "9dd003c6d3b73b74a85a9ab099469ce251653a7af76f523671ab828acd2a0ef9" +} +``` + +## 2. Seal the rumor + +Encrypt the JSON-encoded `rumor` with a conversation key derived using the author's private key and +the recipient's public key. Place the result in the `content` field of a `kind 13` `seal` event. Sign +it with the author's key. + +```json +{ + "content": "AqBCdwoS7/tPK+QGkPCadJTn8FxGkd24iApo3BR9/M0uw6n4RFAFSPAKKMgkzVMoRyR3ZS/aqATDFvoZJOkE9cPG/TAzmyZvr/WUIS8kLmuI1dCA+itFF6+ULZqbkWS0YcVU0j6UDvMBvVlGTzHz+UHzWYJLUq2LnlynJtFap5k8560+tBGtxi9Gx2NIycKgbOUv0gEqhfVzAwvg1IhTltfSwOeZXvDvd40rozONRxwq8hjKy+4DbfrO0iRtlT7G/eVEO9aJJnqagomFSkqCscttf/o6VeT2+A9JhcSxLmjcKFG3FEK3Try/WkarJa1jM3lMRQqVOZrzHAaLFW/5sXano6DqqC5ERD6CcVVsrny0tYN4iHHB8BHJ9zvjff0NjLGG/v5Wsy31+BwZA8cUlfAZ0f5EYRo9/vKSd8TV0wRb9DQ=", + "kind": 13, + "created_at": 1703015180, + "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9", + "tags": [], + "id": "28a87d7c074d94a58e9e89bb3e9e4e813e2189f285d797b1c56069d36f59eaa7", + "sig": "02fc3facf6621196c32912b1ef53bac8f8bfe9db51c0e7102c073103586b0d29c3f39bdaa1e62856c20e90b6c7cc5dc34ca8bb6a528872cf6e65e6284519ad73" +} +``` + +## 3. Wrap the seal + +Encrypt the JSON-encoded `kind 13` event with your ephemeral, single-use random key. Place the result +in the `content` field of a `kind 1059`. Add a single `p` tag containing the recipient's public key. +Sign the `gift wrap` using the random key generated in the previous step. + +```json +{ + "content": "AhC3Qj/QsKJFWuf6xroiYip+2yK95qPwJjVvFujhzSguJWb/6TlPpBW0CGFwfufCs2Zyb0JeuLmZhNlnqecAAalC4ZCugB+I9ViA5pxLyFfQjs1lcE6KdX3euCHBLAnE9GL/+IzdV9vZnfJH6atVjvBkNPNzxU+OLCHO/DAPmzmMVx0SR63frRTCz6Cuth40D+VzluKu1/Fg2Q1LSst65DE7o2efTtZ4Z9j15rQAOZfE9jwMCQZt27rBBK3yVwqVEriFpg2mHXc1DDwHhDADO8eiyOTWF1ghDds/DxhMcjkIi/o+FS3gG1dG7gJHu3KkGK5UXpmgyFKt+421m5o++RMD/BylS3iazS1S93IzTLeGfMCk+7IKxuSCO06k1+DaasJJe8RE4/rmismUvwrHu/HDutZWkvOAhd4z4khZo7bJLtiCzZCZ74lZcjOB4CYtuAX2ZGpc4I1iOKkvwTuQy9BWYpkzGg3ZoSWRD6ty7U+KN+fTTmIS4CelhBTT15QVqD02JxfLF7nA6sg3UlYgtiGw61oH68lSbx16P3vwSeQQpEB5JbhofW7t9TLZIbIW/ODnI4hpwj8didtk7IMBI3Ra3uUP7ya6vptkd9TwQkd/7cOFaSJmU+BIsLpOXbirJACMn+URoDXhuEtiO6xirNtrPN8jYqpwvMUm5lMMVzGT3kMMVNBqgbj8Ln8VmqouK0DR+gRyNb8fHT0BFPwsHxDskFk5yhe5c/2VUUoKCGe0kfCcX/EsHbJLUUtlHXmTqaOJpmQnW1tZ/siPwKRl6oEsIJWTUYxPQmrM2fUpYZCuAo/29lTLHiHMlTbarFOd6J/ybIbICy2gRRH/LFSryty3Cnf6aae+A9uizFBUdCwTwffc3vCBae802+R92OL78bbqHKPbSZOXNC+6ybqziezwG+OPWHx1Qk39RYaF0aFsM4uZWrFic97WwVrH5i+/Nsf/OtwWiuH0gV/SqvN1hnkxCTF/+XNn/laWKmS3e7wFzBsG8+qwqwmO9aVbDVMhOmeUXRMkxcj4QreQkHxLkCx97euZpC7xhvYnCHarHTDeD6nVK+xzbPNtzeGzNpYoiMqxZ9bBJwMaHnEoI944Vxoodf51cMIIwpTmmRvAzI1QgrfnOLOUS7uUjQ/IZ1Qa3lY08Nqm9MAGxZ2Ou6R0/Z5z30ha/Q71q6meAs3uHQcpSuRaQeV29IASmye2A2Nif+lmbhV7w8hjFYoaLCRsdchiVyNjOEM4VmxUhX4VEvw6KoCAZ/XvO2eBF/SyNU3Of4SO", + "kind": 1059, + "created_at": 1703021488, + "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c", + "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac", + "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df750097b04f9e13053764251b8bc5dd7e8e0794a3426a90b6bcc7e5ff660f54259", + "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]], +} +``` + +## 4. Broadcast Selectively + +Broadcast the `kind 1059` event to the recipient's relays only. Delete all the other events. + +# Code Samples + +## JavaScript + +```javascript +import {bytesToHex} from "@noble/hashes/utils" +import type {EventTemplate, UnsignedEvent, Event} from "nostr-tools" +import {getPublicKey, getEventHash, nip19, nip44, finalizeEvent, generateSecretKey} from "nostr-tools" + +type Rumor = UnsignedEvent & {id: string} + +const TWO_DAYS = 2 * 24 * 60 * 60 + +const now = () => Math.round(Date.now() / 1000) +const randomNow = () => Math.round(now() - (Math.random() * TWO_DAYS)) + +const nip44ConversationKey = (privateKey: Uint8Array, publicKey: string) => + nip44.v2.utils.getConversationKey(bytesToHex(privateKey), publicKey) + +const nip44Encrypt = (data: EventTemplate, privateKey: Uint8Array, publicKey: string) => + nip44.v2.encrypt(JSON.stringify(data), nip44ConversationKey(privateKey, publicKey)) + +const nip44Decrypt = (data: Event, privateKey: Uint8Array) => + JSON.parse(nip44.v2.decrypt(data.content, nip44ConversationKey(privateKey, data.pubkey))) + +const createRumor = (event: Partial, privateKey: Uint8Array) => { + const rumor = { + created_at: now(), + content: "", + tags: [], + ...event, + pubkey: getPublicKey(privateKey), + } as any + + rumor.id = getEventHash(rumor) + + return rumor as Rumor +} + +const createSeal = (rumor: Rumor, privateKey: Uint8Array, recipientPublicKey: string) => { + return finalizeEvent( + { + kind: 13, + content: nip44Encrypt(rumor, privateKey, recipientPublicKey), + created_at: randomNow(), + tags: [], + }, + privateKey + ) as Event +} + +const createWrap = (event: Event, recipientPublicKey: string) => { + const randomKey = generateSecretKey() + + return finalizeEvent( + { + kind: 1059, + content: nip44Encrypt(event, randomKey, recipientPublicKey), + created_at: randomNow(), + tags: [["p", recipientPublicKey]], + }, + randomKey + ) as Event +} + +// Test case using the above example +const senderPrivateKey = nip19.decode(`nsec1p0ht6p3wepe47sjrgesyn4m50m6avk2waqudu9rl324cg2c4ufesyp6rdg`).data +const recipientPrivateKey = nip19.decode(`nsec1uyyrnx7cgfp40fcskcr2urqnzekc20fj0er6de0q8qvhx34ahazsvs9p36`).data +const recipientPublicKey = getPublicKey(recipientPrivateKey) + +const rumor = createRumor( + { + kind: 1, + content: "Are you going to the party tonight?", + }, + senderPrivateKey +) + +const seal = createSeal(rumor, senderPrivateKey, recipientPublicKey) +const wrap = createWrap(seal, recipientPublicKey) + +// Recipient unwraps with their private key. + +const unwrappedSeal = nip44Decrypt(wrap, recipientPrivateKey) +const unsealedRumor = nip44Decrypt(unwrappedSeal, recipientPrivateKey) +``` \ No newline at end of file