Ouroboros Protocols: Difference between revisions
| Line 32: | Line 32: | ||
== Flow encryption header == | == Flow encryption header == | ||
Every encrypted packet is a fixed-size cleartext '''selector''' header, | |||
followed by the AEAD ciphertext of the inner FRCP packet, followed by | |||
the AEAD authentication '''tag'''. | |||
<syntaxhighlight lang="text"> | |||
+----------------+------------------------------+--------------+ | |||
| selector (6 B) | E(inner FRCP packet) | tag (16 B) | | |||
+----------------+------------------------------+--------------+ | |||
\__ cleartext _/ \______ ciphertext __________/ \__ cleartext _/ | |||
\________________ authenticated (AAD + AEAD) ________________/ | |||
</syntaxhighlight> | |||
;selector | |||
:6-octet cleartext key-selection header (see [[#1.2. Selector|Section 1.2]]). It is read '''before''' decryption to select the key and reconstruct the nonce, and it is bound into the AEAD as Associated Data (see [[#4. AEAD and AAD binding|Section 4]]). | |||
;ciphertext | |||
:AEAD encryption of the inner packet under the selected sub-key and reconstructed nonce. The supported ciphers are stream-mode, so the ciphertext length equals the plaintext length. | |||
;tag | |||
:AEAD authentication tag, 16 octets (128 bits) for AEAD ciphers; absent for non-AEAD ciphers (see [[#4. AEAD and AAD binding|Section 4]]). | |||
== Flow and Retransmission Control Protocol == | == Flow and Retransmission Control Protocol == | ||
Revision as of 08:21, 13 June 2026
This page is under construction
The protocols in Ouroboros are designed with strong adherence to the principles of separation of concerns and separation of mechanism and policy in mind to prevent network ossification and protocol ossification from occuring.
There are 5 core protocols in Ouroboros.
Data Transfer Protocol
Main page: Ouroboros Data Transfer Protocol
The Data Transfer Protocol resides in the network forwarding layer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live | QoS | ECN | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ N + 1 Data +
. .
. .Flow encryption header
Every encrypted packet is a fixed-size cleartext selector header, followed by the AEAD ciphertext of the inner FRCP packet, followed by the AEAD authentication tag.
+----------------+------------------------------+--------------+
| selector (6 B) | E(inner FRCP packet) | tag (16 B) |
+----------------+------------------------------+--------------+
\__ cleartext _/ \______ ciphertext __________/ \__ cleartext _/
\________________ authenticated (AAD + AEAD) ________________/
- selector
- 6-octet cleartext key-selection header (see Section 1.2). It is read before decryption to select the key and reconstruct the nonce, and it is bound into the AEAD as Associated Data (see Section 4).
- ciphertext
- AEAD encryption of the inner packet under the selected sub-key and reconstructed nonce. The supported ciphers are stream-mode, so the ciphertext length equals the plaintext length.
- tag
- AEAD authentication tag, 16 octets (128 bits) for AEAD ciphers; absent for non-AEAD ciphers (see Section 4).
Flow and Retransmission Control Protocol
Main page: Flow and Retransmission Control Protocol
The Flow and Retransmission Control Protocol resides in the application end-to-end layer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | hcs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ackno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload (variable) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
flags - feature/type bitmap (see 1.2).
hcs - CRC-16-CCITT-FALSE Header Check Sequence (HCS) over
flags + window + seqno + ackno (+ stream extension when
present); the two octets of the hcs field itself are
omitted from the CRC input. Verified on receive before
any flag-driven dispatch.
window - receiver-advertised right window edge (valid iff FC).
seqno - per-flow sequence number.
ackno - cumulative Acknowledgement (ACK) (valid iff ACK).Flow Allocation Protocol
Main page: Ouroboros Flow Allocation Protocol
/*
* 0 1 2 3 * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ * | | | * + + | * | | | * + id (128 bits) + | * | Unique flow allocation ID | | * + + | * | | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * | | | * + timestamp (64 bits) + | * | UTC nanoseconds since epoch | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * | crt_len (16 bits) | | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | * | | | * + certificate (variable) + | * | X.509 certificate, DER encoded | | * + + | * | | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * |F|R| kex_len (14 bits) | | | Signed * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | * | | | Region * + kex_data (variable) + | * | public key (DER/raw) or ciphertext (KEM) | | * + + | * | | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * | cipher_len (16 bits) | | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | * | | | * + cipher (variable) + | * | symmetric cipher name (UTF-8) | | * + + | * | | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | * | data_len (16 bits) | | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | * | | | * + data (variable) + | * | Piggybacked application data | | * + + | * | | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ * | sig_len (16 bits) | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | | * + signature (variable) + * | DSA signature over signed region | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * * kex_len field bit layout: * F (bit 15): Format - 0 = X.509 DER, 1 = Raw/Hybrid * R (bit 14): Role - 0 = Server encaps, 1 = Client encaps * (R is ignored for non-KEM algorithms) * Bits 0-13: Length (0-16383 bytes) */
The Flow Allocation Protocol resides in the network end-to-end layer.
Connection Establishment Protocol
Main page: Ouroboros Connection Establishment Protocol
Enrollment Protocol
Main page: Ouroboros Enrolment Protocol
The Enrollment protocol is best seen as one of the application protocols for IPCPs.