mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-21 08:15:50 -05:00
nip44: update some nits.
This commit is contained in:
parent
97bf5266d7
commit
7e150faed4
12
44.md
12
44.md
|
@ -8,11 +8,11 @@ Encrypted Payloads (Versioned)
|
|||
|
||||
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.
|
||||
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.
|
||||
for NIP-04 payloads.
|
||||
|
||||
## Versions
|
||||
|
||||
|
@ -41,7 +41,7 @@ On its own, messages sent using this scheme have a number of important shortcomi
|
|||
- 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
|
||||
- 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
|
||||
|
||||
|
@ -86,7 +86,7 @@ NIP-44 version 2 has the following design characteristics:
|
|||
- 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 32bytes
|
||||
- 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
|
||||
|
@ -148,8 +148,8 @@ validation rules, refer to BIP-340.
|
|||
- `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. 1bytes msg is padded to 32bytes.
|
||||
- `max_plaintext_size` is 65535 (64kB - 1). It is padded to 65536bytes.
|
||||
- `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
|
||||
|
|
Loading…
Reference in New Issue
Block a user