Message decryption relies (in part) on deserialization for validity

[AaronFeickert]

When a node wishes to determine if it can decrypt an incoming encrypted message, it performs several steps; these include:

• Generating an ECDH shared secret using the provided ephemeral public key
• Decrypting the message signature ("origin MAC")
• Deserializing the signature
• Deserializing the signature public key
• Verifying the signature against the message and header
• Decrypting the message
• Deserializing the message

If the message was not encrypted for the node:

• The first two steps will always succeed
• The next two deserialization steps may succeed (possibly maliciously)
• Signature verification will (almost certainly) fail

It is possible to alter this construction such that messages not intended for a node will be rejected with less computational effort, and without relying on particular serialization formats.

To do so, the sending node does the following:

• Uses domain-separated KDFs (recommendation is Blake2b) with ECDH shared-secret input to produce a ChaCha20 key and ChaCha20-Poly1305 key, respectively:
  • key_message = Blake2b(persona="Tari message key", input=[ECDH_shared_secret])
  • key_signature = Blake2b(persona="Tari signature key", input=[ECDH_shared_secret])
• Encrypts the message using ChaCha20 with key_message
• Generates the signature as before
• Encrypts the signature using the ChaCha20-Poly1305 AEAD construction with key_signature

The recipient node does the following:

• Uses domain-separated KDFs (recommendation is Blake2b) with ECDH shared-secret input to produce a ChaCha20 key and ChaCha20-Poly1305 key, respectively:
  • key_message = Blake2b(persona="Tari message key", input=[ECDH_shared_secret])
  • key_signature = Blake2b(persona="Tari signature key", input=[ECDH_shared_secret])
• Attempts to decrypt the encrypted signature using the ChaCha20-Poly1305 AEAD construction with key_signature
  • If tag verification fails prior to decryption, the message was not intended for this node, so we abort
• Deserializes the signature as before
• Verifies the signature as before
• Decrypts the message using ChaCha20 with key_message
• Deserializes the message as before

This approach adds an additional 16-byte ChaCha20-Poly1305 tag to the message structure.

This issue relates to (and in part supersedes) this issue.

[AaronFeickert]

The discretization approach in #4140 can be used here. To do so, assemble an extended message consisting of the original message length (in a platform-independent and fixed-length encoding), the original message, and arbitrary padding up to the next multiple of a globally-fixed base length. This extended message is then used for the encryption and decryption steps above.

[AaronFeickert]

In case it is useful here, it's possible to use fixed nonces for both the message encryption and the signature authenticated encryption, since in honest messages the ephemeral public key used for derived encryption keys is unique. A malicious or malfunctioning sender could reuse an ephemeral key and nonce anyway in a way not detected by the recipient unless it caches previous values, so there doesn't appear to be any particular security benefit to including a random nonce. The fixed nonces can be any value; zero is easy and makes the intent clear; further, the use of proper key derivation between the two encryption operations means the nonces may be identical.

[AaronFeickert]

Note that the new hashing API should be used for the key derivations proposed here.

[SWvheerden]

Fixed in: #4336