4

I recently saw the BIP 324 proposal. It shows us there can be some privacy enhancement by using ECDH secrets and encryption algorithms such as ChaCha20 and AEAD-ChaCha20-Poly1305. The proposal includes:

  • The length decriptor size is reduced to 3 Bytes.
  • The command could be expressed as an ID (1 Byte) OR as characters (13 Bytes, by including the 0x00 byte selector).
  1. However, I don't fully understand the order in data will be structured. Can it be explained ?
  2. What algorithm will be applied to which data structure ? Because I can suppose the ChaCha20 is used in order to encrypt the payload size and AEAD-ChaCha20-Poly1305 to encrypt payload.
2
  • What do you mean with "the order"? Commented Aug 20, 2023 at 13:17
  • I mean the structure of sent data. For example: CommandId (1 Byte) + Size (4 Bytes)...
    – Loopite
    Commented Aug 20, 2023 at 13:23

1 Answer 1

5

In the new P2P transport protocol proposed in BIP324, after the handshake (which among other things establishes encryption keys), packets have the following structure:

  • A 3-byte length descriptor (encrypted with FSChaCha20)
  • An arbitrary-length ciphertext which is the encryption of a plaintext (encrypted with FSChaCha20Poly1305, which expands the data by 16 bytes in the process by adding a Poly1305 authentication tag); the plaintext consists of:
    • A 1-byte header (which is used for signalling decoy data)
    • A variable-length contents (whose length is described by the length descriptor). The contents consists of:
      • A 1-byte or 13-byte message type (e.g. version, verack, tx, inv, ...).
      • A variable-length payload (the actual data sent in the message).

So if you want everything flattened out, you get:

  • 3-byte encrypted length descriptor
  • 1-byte encrypted header
  • 1-byte or 13-byte encrypted message type
  • variable length encrypted payload
  • 16-byte Poly1305 authentication tag

However, only 2 separate encryption algorithm invocations are used per packet:

4
  • So, I have a new question: Why the command field isn't directly encrypted with the length through ChaCha20 ?
    – Loopite
    Commented Aug 20, 2023 at 15:05
  • 2
    @Loopite Because we want as much as possible to be covered by the Poly1305 authentication tag (as that allows modifications in flight to be detected). Only the length isn't, because we need to know the length of a packet before we can decrypt/authenticate the packet. It would have been possible in theory to have a separate authentication tag for just the length, but that'd come at fairly high cost (an additional 16 bytes per packet), and not actually achieve anything (see footnote 23 in the BIP). Commented Aug 20, 2023 at 15:28
  • Yeah but why didn't you encrypt all the message (with length) with AEAD-ChaCha20Poly1305 then ? You'd still know the length by the way by decrypting it with ChaCha20 and then decrypt ALL the message (with the length again) with ChaCha20. You can also check the tag now by the way... This avoids encrypting 2 sections and now encrypts just one. This also protects the length by the tag.
    – Loopite
    Commented Oct 13, 2024 at 8:08
  • @Loopite I personally believe that may work, but it is much harder to argue for its security, as it means using the same key/cipher for the length data (which has very weak privacy guarantees anyway, but no mac) as the actual payload (which has strong privacy guarantees, but also a mac). This is the reason why the OpenSSH chacha20-poly1305 uses two separate ciphers for length and data, and BIP324 inherited that design. Commented Oct 13, 2024 at 12:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.