The algorithm described in NIP4 is potentially vulnerable to [padding oracle attacks](https://en.wikipedia.org/wiki/Padding_oracle_attack) and uses keys which are not indistinguishable from random.
An encrypted payload MUST be encoded as a JSON object. Different versions may have different parameters. Every format has a `v` field specifying its version.
Currently defined encryption algorithms:
-`0x00` - Reserved
-`0x01` - XChaCha with same key `sha256(ecdh)` per conversation
# Version 0
Version 0 is not defined, however implementations depending on this NIP MAY choose to support the payload described in NIP 04 in the same places a NIP 44 payload would otherwise be expected. This is intended to allow a smooth transition while clients and signing software adopt the new standard.
# Version 1
Params:
1.`nonce`: base64-encoded xchacha nonce
2.`ciphertext`: base64-encoded xchacha ciphertext, created from (key, nonce) against `plaintext`.
Example:
```
{
"ciphertext": "FvQi1H4atMwU+FzUR/0CJ7kowjs+",
"nonce": "3dBKd83Pg2Q4Tu2A2e8N++c+ZW2IBc2f",
"v": 1
}
```
**Note**: By default in the [libsecp256k1](https://github.com/bitcoin-core/secp256k1) ECDH implementation, the secret is the SHA256 hash of the shared point (both X and Y coordinates). We are using this exact implementation. In NIP4, unhashed shared point was used.