vacp2p/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-09 22:08:07 -05:00
Code Issues Packages Projects Releases Wiki Activity

Created nomos/raw/nomos-message-formatting.md file

Browse Source
This commit is contained in:
Cofson
2025-12-05 09:59:02 +01:00
parent d2df7e0c2d
commit 0bbd30ad2d
1 changed files with 214 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

214
nomos/raw/nomos-message-formatting.md Normal file
View File

@@ -0,0 +1,214 @@
---
title: NOMOS-MESSAGE-FORMATTING
name: Nomos Message Formatting Specification
status: raw
category: Standards Track
tags: nomos, blend, message-formatting, protocol
editor: Marcin Pawlowski
contributors:
- Youngjoon Lee <youngjoon@status.im>
- Alexander Mozeika <alexander.mozeika@status.im>
- Álvaro Castro-Castilla <alvaro@status.im>
- Filip Dimitrijevic <filip@status.im>
---
## Abstract
This document defines an implementation-friendly specification of the Message Formatting for the Blend Protocol. The message contains a header and a payload, where the header informs the protocol about the version and the payload type. The message contains either a drop or a non-drop payload, with fixed-length payloads to prevent adversaries from distinguishing message types based on length. This specification reuses notation from the Notation document and integrates with the Message Encapsulation Mechanism.
## Semantics
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.
## Document Structure
This specification is organized into two distinct parts to serve different audiences and use cases:
**Protocol Specification** contains the normative requirements necessary for implementing an interoperable Blend Protocol node. This section defines the cryptographic primitives, message formats, network protocols, and behavioral requirements that all implementations MUST follow to ensure compatibility and maintain the protocol's privacy guarantees. Protocol designers, auditors, and those seeking to understand the core mechanisms should focus on this part.
**Implementation Details** provides non-normative guidance for implementers. This section offers practical recommendations, optimization strategies, and detailed examples that help developers build efficient and robust implementations. While these details are not required for interoperability, they represent best practices learned from reference implementations and can significantly improve performance and reliability.
## Protocol Specification
### Introduction
This document defines an implementation-friendly specification of the Message Formatting, which is introduced in the Formatting section.
In this document we are reusing notation from Notation.
### Overview
The message contains a header and a payload. The header informs the protocol about the version of the protocol and the payload type. The message contains a drop or a non-drop payload. The length of a payload is fixed to prevent adversaries from distinguishing types of messages based on their length.
### Construction
#### Message
The Message is a structure that contains a public_header, private_header and a payload.
```python
class Message:
public_header: PublicHeader
private_header: Private_Header
payload: bytes
```
#### Public Header
The public_header must be generated as the outcome of the Message Encapsulation Mechanism.
The public_header is defined as follows:
```python
class PublicHeader:
version: byte
public_key: PublicKey
proof_of_quota: ProofOfQuota
signature: Signature
```
**Fields:**
- version=0x01 is version of the protocol.
- public_key is $K^{n}_i$, a public key from the set $\mathbf K^n_h$ as defined in the Message Encapsulation spec.
- proof_of_quota is $\pi^{K^{n}i}{Q}$, a corresponding proof of quota for the key $K^{n}_i$ from the $\mathbf K^n_h$ it also contains the key nullifier.
- signature is $\sigma_{K^{n}_{i}}(\mathbf {h|P}i)$, a signature of the concatenation of the $i$-th encapsulation of the payload $\mathbf P$ and the private header $\mathbf h$, that can be verified by the public key $K^{n}{i}$.
#### Private Header
The private_header must be generated as the outcome of the Message Encapsulation Mechanism.
The private header contains a set of encrypted blending headers $\mathbf h = (\mathbf b_1,...,\mathbf b_{h_{max}})$.
```python
private_header: list[BlendingHeader]
```
The size of the set is limited to $\beta_{max}=3$ BlendingHeader entries, as defined in the Global Parameters.
**Blending Header:**
The BlendingHeader ($\mathbf b_l$) is defined as follows:
```python
class BlendingHeader:
public_key: PublicKey
proof_of_quota: ProofOfQuota
signature: Signature
proof_of_selection: ProofOfSelection
is_last: byte
```
**Fields:**
- public_key is $K^{n}_{l}$, a public key from the set $\mathbf K^n_h$.
- proof_of_quota is $\pi^{K^{n}l}{Q}$, a corresponding proof of quota for the key $K^{n}_l$ from the $\mathbf K^n_h$ it also contains the key nullifier.
- signature is $\sigma_{K^{n}_{l}}(\mathbf {h|P}l)$, a signature of the concatenation of $l$-th encapsulation of the payload $\mathbf P$ and the private header $\mathbf h$, that can be verified by public key $K^{n}{l}$.
- proof_of_selection is $\pi^{K^{n}{l+1},m{l+1}}{S}$, a proof of selection of the node index $m{l+1}$ assuming valid proof of quota $\pi^{K^{n}{l}}{Q}$.
- is_last is $\Omega$, a flag that indicates that this is the last encapsulation.
#### Payload
The payload must be formatted according to the Payload Formatting Specification. The formatted payload must be generated as the outcome of the Message Encapsulation Mechanism.
#### Maximum Payload Length
The Max_Payload_Length parameter defines the maximum length of the payload, which for version 1 of the Blend Protocol is fixed as Max_Payload_Length=34003. That is, 34kB for the payload body (Max_Body_Length) and 3 bytes for the payload header. More information about payload formatting can be found in Payload Formatting Specification.
```python
MAX_PAYLOAD_LENGTH = 34003
MAX_BODY_LENGTH = 34000
PAYLOAD_HEADER_SIZE = 3
```
## Implementation Considerations
### Message Size Uniformity
**Fixed-Length Design:**
- All messages have a fixed total length to prevent traffic analysis attacks
- The payload length is constant regardless of actual content size
- Padding is used to fill unused space in the payload body
- This design prevents adversaries from distinguishing message types based on size
### Protocol Version
**Version Field:**
- The current protocol version is 0x01
- The version field is a single byte in the public header
- Future protocol versions may introduce breaking changes to the message format
- Implementations must validate the version field before processing messages
### Header Generation
**Dependency on Encapsulation:**
- Both public_header and private_header are generated by the Message Encapsulation Mechanism
- Implementations must not manually construct headers
- The encapsulation mechanism ensures proper cryptographic properties
- Headers include signatures, proofs, and encryption as specified in the Message Encapsulation spec
### Blending Header Limit
**Maximum Encapsulation Layers:**
- The protocol limits the private header to $\beta_{max}=3$ BlendingHeader entries
- This limit is defined in the Global Parameters
- Each blending header represents one layer of message encapsulation
- The limit balances privacy (more layers) with performance and overhead
### Integration Points
**Required Specifications:**
- Message Encapsulation Mechanism: Generates the public and private headers
- Payload Formatting Specification: Defines how to format the payload content
- Notation: Provides mathematical and cryptographic notation used throughout
- Global Parameters: Defines protocol-wide constants like $\beta_{max}$
### Security Considerations
**Traffic Analysis Protection:**
- Fixed message lengths prevent size-based traffic analysis
- All messages appear identical in size on the network
- Cover traffic can be indistinguishable from real data messages
**Cryptographic Integrity:**
- Signatures in both public and private headers ensure message authenticity
- Proof of Quota prevents spam and resource exhaustion
- Proof of Selection ensures correct node routing
**Message Validation:**
- Implementations must verify all signatures before processing
- Proof of Quota must be validated to prevent quota violations
- The is_last flag must be checked to determine final message destination
## References
### Normative
- [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) - Key words for use in RFCs to Indicate Requirement Levels
- [Message Encapsulation Mechanism](https://nomos-tech.notion.site/Message-Encapsulation-Mechanism-215261aa09df8136a3bbf64df8b59779)
\- Cryptographic operations for building and processing messages
- [Payload Formatting Specification](https://nomos-tech.notion.site/Payload-Formatting-215261aa09df81b2a3e1d913a0df9ad9)
\- Defines payload structure and formatting rules
- [Blend Protocol](https://nomos-tech.notion.site/Blend-Protocol-215261aa09df81ae8857d71066a80084)
\- Protocol-wide constants and configuration values
### Informative
- [Message Formatting](https://nomos-tech.notion.site/Message-Formatting-215261aa09df81dab083c6e01e2b56e3)
\- Original Message Formatting documentation
- [Blend Protocol Formatting](https://nomos-tech.notion.site/Formatting-215261aa09df81a3b3ebc1f438209467)
\- High-level overview of message formatting in Blend Protocol
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).