Ouroboros Flow Allocation Protocol - Revision history

Dimitri: /* Header */

2026-01-07T00:02:49Z

Header

← Older revision		Revision as of 00:02, 7 January 2026
Line 7:		Line 7:
	====================		====================

	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		* 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 \| \|		* + id (128 bits) + \|
	+ + \|		* \| Unique flow allocation ID \| \|
	\| \| \|		* + + \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| \| \|
	\| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+ timestamp (64 bits) + \|		* \| \| \|
	\| UTC nanoseconds since epoch \| \|		* + timestamp (64 bits) + \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| UTC nanoseconds since epoch \| \|
	\| crt_len (16 bits) \| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \|		* \| crt_len (16 bits) \| \| \|
	\| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \|
	+ ~~+ \|~~		* \| \| \|
	\| certificate (variable) \| \|		* + certificate (variable) + \|
	+ X.509 certificate, DER encoded + \|		* \| X.509 certificate, DER encoded \| \|
	\| \| \|		* + + \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| \| \|
	\| \| eph_len (16 bits) \| \| ~~Signed~~		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| ~~Region~~		* \| eph_len (16 bits) \| \| \| Signed
	\| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \| Region
	+ + \|		* \| \| \|
	\| ~~ephemeral_key~~ (~~variable~~) \| \|		* + ephemeral_key (variable) + \|
	+ ~~public key, DER encoded~~ + \|		* \| public key, DER encoded \| \|
	\| \| \|		* + + \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| \| \|
	~~\| \| data_len (16 bits) \| \|~~		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| cipher_len (16 bits) \| \| \|
	\| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \|
	+ data (variable) + \|		* \| \| \|
	\| Piggybacked application data \| \|		* + cipher (variable) + \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| symmetric cipher name (UTF-8) \| \|
	~~\| \| sig_len (16 bits) \| \|~~		* + + \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~---~~+		* \| \| \|
	\| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+ +		* \| data_len (16 bits) \| \| \|
	\| signature (variable) \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \|
	+ DSA signature over signed region +		* \| \| \|
	\| \|		* + data (variable) + \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		* \| Piggybacked application data \| \|
			* + + \|
			* \| \| \|
			* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
			* \| sig_len (16 bits) \| \|
			* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
			* \| \|
			* + signature (variable) +
			* \| DSA signature over signed region \|
			* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			*/

	Field Summary:		Field Summary:
Line 63:		Line 73:
	\| eph_len \| 2 bytes \| Ephemeral key length (0 = no encrypt) \|		\| eph_len \| 2 bytes \| Ephemeral key length (0 = no encrypt) \|
	\| ephemeral_key \| variable \| DHE public key \|		\| ephemeral_key \| variable \| DHE public key \|
			\| cipher_len \| 2 bytes \| Cipher name length (0 = no cipher) \|
			\| cipher \| variable \| Name of the cipher to use \|
	\| data_len \| 2 bytes \| Application data length \|		\| data_len \| 2 bytes \| Application data length \|
	\| data \| variable \| Piggybacked app data (future use) \|		\| data \| variable \| Piggybacked app data (future use) \|
Line 69:		Line 81:
	+---------------+----------+----------------------------------------+		+---------------+----------+----------------------------------------+

	Minimum header size: 16 + 8 + 2 + 2 + 2 + 2 = 32 bytes (no optional fields)		Minimum header size: 16 + 8 + 2 + 2 + 2 + 2 + 2 = 34 bytes (no optional fields)

	</pre>		</pre>

Dimitri: /* Header */

2026-01-03T10:42:11Z

Header

← Older revision		Revision as of 10:42, 3 January 2026
Line 30:		Line 30:
	\| \| \|		\| \| \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	\| \| eph_len (16 bits) \| \|		\| \| eph_len (16 bits) \| \| Signed
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| Region
	\| \| \| ~~Signed~~		\| \| \|
	+ + \| ~~Region~~		+ + \|
	\| ephemeral_key (variable) \| \|		\| ephemeral_key (variable) \| \|
	+ public key, DER encoded + \|		+ public key, DER encoded + \|

Dimitri: /* Header */

2026-01-03T10:41:49Z

Header

← Older revision		Revision as of 10:41, 3 January 2026
Line 32:		Line 32:
	\| \| eph_len (16 bits) \| \|		\| \| eph_len (16 bits) \| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	\| \| \|		\| \| \| Signed
	+ + \|		+ + \| Region
	\| ephemeral_key (variable) \| \|		\| ephemeral_key (variable) \| \|
	+ public key, DER encoded + \|		+ public key, DER encoded + \|

Dimitri: /* Header */

2026-01-03T10:41:28Z

Header

← Older revision		Revision as of 10:41, 3 January 2026
Line 34:		Line 34:
	\| \| \|		\| \| \|
	+ + \|		+ + \|
	\| ephemeral_key (variable) \| \| ~~Signed~~		\| ephemeral_key (variable) \| \|
	+ public key, DER encoded + \| ~~Region~~		+ public key, DER encoded + \|
	\| \| \|		\| \| \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|

Dimitri: /* Header */

2026-01-03T10:41:00Z

Header

@@ Line 9: / Line 9: @@
                    1                   2                   3
 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
 |         crt_len (16 bits)     |                               |    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +    |

Dimitri: /* Operation */

2026-01-03T09:24:58Z

Operation

← Older revision		Revision as of 09:24, 3 January 2026
Line 75:		Line 75:
	= Operation =		= Operation =

	When an application calls flow_alloc() to connect to a service or flow_accept() to receive incoming connections, the Ouroboros IRMd (IPC Resource Manager daemon) transparently handles all security operations on behalf of the application. The application simply provides a destination name (e.g., "sec.oping.tut.o7s") and receives back a flow descriptor for reading and writing data—it remains completely unaware of any underlying cryptography. During flow allocation, the IRMd on the client side constructs an OAP (Ouroboros Allocation Protocol) header containing a unique flow ID, timestamp, and optionally the client's X.509 certificate, an ephemeral DHE public key, and a digital signature. This OAP header travels inside the FLOW_REQ message to the server's IRMd, which can verify the client's certificate against its configured CA trust store and validate the signature. The server's IRMd then responds with its own OAP header in the FLOW_REPLY, containing its certificate, ephemeral public key, and signature. Both sides independently derive the same symmetric encryption key using DHE key agreement. Once the flow is established, the library layer (between the application and IRMd) automatically encrypts outgoing data and decrypts incoming data using this shared key—the application's flow_read() and flow_write() calls work identically whether encryption is enabled or not. This architecture applies uniformly to all flows regardless of their QoS characteristics: whether the underlying ~~IPCP~~ provides reliable ordered delivery (connection-oriented semantics) or best-effort delivery (connectionless semantics), the security handshake occurs during flow allocation, and the resulting symmetric key protects all subsequent data exchange. The security policy is entirely configuration-driven through certificate and key files in security, allowing system administrators to enforce authentication and encryption requirements without any application code changes.		When an application calls flow_alloc() to connect to a service or flow_accept() to receive incoming connections, the Ouroboros IRMd (IPC Resource Manager daemon) transparently handles all security operations on behalf of the application. The application simply provides a destination name (e.g., "sec.oping.tut.o7s") and receives back a flow descriptor for reading and writing data—it remains completely unaware of any underlying cryptography. During flow allocation, the IRMd on the client side constructs an OAP (Ouroboros Allocation Protocol) header containing a unique flow ID, timestamp, and optionally the client's X.509 certificate, an ephemeral DHE public key, and a digital signature. This OAP header travels inside the FLOW_REQ message to the server's IRMd, which can verify the client's certificate against its configured CA trust store and validate the signature. The server's IRMd then responds with its own OAP header in the FLOW_REPLY, containing its certificate, ephemeral public key, and signature. Both sides independently derive the same symmetric encryption key using DHE key agreement. Once the flow is established, the library layer (between the application and IRMd) automatically encrypts outgoing data and decrypts incoming data using this shared key—the application's flow_read() and flow_write() calls work identically whether encryption is enabled or not. This architecture applies uniformly to all flows regardless of their QoS characteristics: whether the underlying flow provides reliable ordered delivery (connection-oriented semantics) or best-effort delivery (connectionless semantics), the security handshake occurs during flow allocation, and the resulting symmetric key protects all subsequent data exchange. The security policy is entirely configuration-driven through certificate and key files in security, allowing system administrators to enforce authentication and encryption requirements without any application code changes.

Dimitri: /* Operation */

2026-01-03T09:23:13Z

Operation

← Older revision		Revision as of 09:23, 3 January 2026
Line 75:		Line 75:
	= Operation =		= Operation =

	When an application calls flow_alloc() to connect to a service or flow_accept() to receive incoming connections, the Ouroboros IRMd (IPC Resource Manager daemon) transparently handles all security operations on behalf of the application. The application simply provides a destination name (e.g., "sec.oping.tut.o7s") and receives back a flow descriptor for reading and writing data—it remains completely unaware of any underlying cryptography. During flow allocation, the IRMd on the client side constructs an OAP (Ouroboros Allocation Protocol) header containing a unique flow ID, timestamp, and optionally the client's X.509 certificate, an ephemeral ~~ECDHE~~ public key, and a digital signature. This OAP header travels inside the FLOW_REQ message to the server's IRMd, which can verify the client's certificate against its configured CA trust store and validate the signature. The server's IRMd then responds with its own OAP header in the FLOW_REPLY, containing its certificate, ephemeral public key, and signature. Both sides independently derive the same symmetric encryption key using ~~ECDHE~~ key agreement. Once the flow is established, the library layer (between the application and IRMd) automatically encrypts outgoing data and decrypts incoming data using this shared key—the application's flow_read() and flow_write() calls work identically whether encryption is enabled or not. This architecture applies uniformly to all flows regardless of their QoS characteristics: whether the underlying IPCP provides reliable ordered delivery (connection-oriented semantics) or best-effort delivery (connectionless semantics), the security handshake occurs during flow allocation, and the resulting symmetric key protects all subsequent data exchange. The security policy is entirely configuration-driven through certificate and key files in security, allowing system administrators to enforce authentication and encryption requirements without any application code changes.		When an application calls flow_alloc() to connect to a service or flow_accept() to receive incoming connections, the Ouroboros IRMd (IPC Resource Manager daemon) transparently handles all security operations on behalf of the application. The application simply provides a destination name (e.g., "sec.oping.tut.o7s") and receives back a flow descriptor for reading and writing data—it remains completely unaware of any underlying cryptography. During flow allocation, the IRMd on the client side constructs an OAP (Ouroboros Allocation Protocol) header containing a unique flow ID, timestamp, and optionally the client's X.509 certificate, an ephemeral DHE public key, and a digital signature. This OAP header travels inside the FLOW_REQ message to the server's IRMd, which can verify the client's certificate against its configured CA trust store and validate the signature. The server's IRMd then responds with its own OAP header in the FLOW_REPLY, containing its certificate, ephemeral public key, and signature. Both sides independently derive the same symmetric encryption key using DHE key agreement. Once the flow is established, the library layer (between the application and IRMd) automatically encrypts outgoing data and decrypts incoming data using this shared key—the application's flow_read() and flow_write() calls work identically whether encryption is enabled or not. This architecture applies uniformly to all flows regardless of their QoS characteristics: whether the underlying IPCP provides reliable ordered delivery (connection-oriented semantics) or best-effort delivery (connectionless semantics), the security handshake occurs during flow allocation, and the resulting symmetric key protects all subsequent data exchange. The security policy is entirely configuration-driven through certificate and key files in security, allowing system administrators to enforce authentication and encryption requirements without any application code changes.

Dimitri: /* Operation */

2026-01-03T09:22:13Z

Operation

← Older revision		Revision as of 09:22, 3 January 2026
Line 75:		Line 75:
	= Operation =		= Operation =

	When an application calls flow_alloc() to connect to a service or flow_accept() to receive incoming connections, the Ouroboros IRMd (IPC Resource Manager daemon) transparently handles all security operations on behalf of the application. The application simply provides a destination name (e.g., "sec.oping.tut.o7s") and receives back a ~~file~~ descriptor for reading and writing data—it remains completely unaware of any underlying cryptography. During flow allocation, the IRMd on the client side constructs an OAP (Ouroboros Allocation Protocol) header containing a unique flow ID, timestamp, and optionally the client's X.509 certificate, an ephemeral ECDHE public key, and a digital signature. This OAP header travels inside the FLOW_REQ message to the server's IRMd, which can verify the client's certificate against its configured CA trust store and validate the signature. The server's IRMd then responds with its own OAP header in the FLOW_REPLY, containing its certificate, ephemeral public key, and signature. Both sides independently derive the same symmetric encryption key using ECDHE key agreement. Once the flow is established, the library layer (between the application and IRMd) automatically encrypts outgoing data and decrypts incoming data using this shared key—the application's flow_read() and flow_write() calls work identically whether encryption is enabled or not. This architecture applies uniformly to all flows regardless of their QoS characteristics: whether the underlying IPCP provides reliable ordered delivery (connection-oriented semantics) or best-effort delivery (connectionless semantics), the security handshake occurs during flow allocation, and the resulting symmetric key protects all subsequent data exchange. The security policy is entirely configuration-driven through certificate and key files in security, allowing system administrators to enforce authentication and encryption requirements without any application code changes.		When an application calls flow_alloc() to connect to a service or flow_accept() to receive incoming connections, the Ouroboros IRMd (IPC Resource Manager daemon) transparently handles all security operations on behalf of the application. The application simply provides a destination name (e.g., "sec.oping.tut.o7s") and receives back a flow descriptor for reading and writing data—it remains completely unaware of any underlying cryptography. During flow allocation, the IRMd on the client side constructs an OAP (Ouroboros Allocation Protocol) header containing a unique flow ID, timestamp, and optionally the client's X.509 certificate, an ephemeral ECDHE public key, and a digital signature. This OAP header travels inside the FLOW_REQ message to the server's IRMd, which can verify the client's certificate against its configured CA trust store and validate the signature. The server's IRMd then responds with its own OAP header in the FLOW_REPLY, containing its certificate, ephemeral public key, and signature. Both sides independently derive the same symmetric encryption key using ECDHE key agreement. Once the flow is established, the library layer (between the application and IRMd) automatically encrypts outgoing data and decrypts incoming data using this shared key—the application's flow_read() and flow_write() calls work identically whether encryption is enabled or not. This architecture applies uniformly to all flows regardless of their QoS characteristics: whether the underlying IPCP provides reliable ordered delivery (connection-oriented semantics) or best-effort delivery (connectionless semantics), the security handshake occurs during flow allocation, and the resulting symmetric key protects all subsequent data exchange. The security policy is entirely configuration-driven through certificate and key files in security, allowing system administrators to enforce authentication and encryption requirements without any application code changes.

Dimitri: /* Operation */

2026-01-03T09:21:51Z

Operation

← Older revision		Revision as of 09:21, 3 January 2026
Line 74:		Line 74:

	= Operation =		= Operation =

			When an application calls flow_alloc() to connect to a service or flow_accept() to receive incoming connections, the Ouroboros IRMd (IPC Resource Manager daemon) transparently handles all security operations on behalf of the application. The application simply provides a destination name (e.g., "sec.oping.tut.o7s") and receives back a file descriptor for reading and writing data—it remains completely unaware of any underlying cryptography. During flow allocation, the IRMd on the client side constructs an OAP (Ouroboros Allocation Protocol) header containing a unique flow ID, timestamp, and optionally the client's X.509 certificate, an ephemeral ECDHE public key, and a digital signature. This OAP header travels inside the FLOW_REQ message to the server's IRMd, which can verify the client's certificate against its configured CA trust store and validate the signature. The server's IRMd then responds with its own OAP header in the FLOW_REPLY, containing its certificate, ephemeral public key, and signature. Both sides independently derive the same symmetric encryption key using ECDHE key agreement. Once the flow is established, the library layer (between the application and IRMd) automatically encrypts outgoing data and decrypts incoming data using this shared key—the application's flow_read() and flow_write() calls work identically whether encryption is enabled or not. This architecture applies uniformly to all flows regardless of their QoS characteristics: whether the underlying IPCP provides reliable ordered delivery (connection-oriented semantics) or best-effort delivery (connectionless semantics), the security handshake occurs during flow allocation, and the resulting symmetric key protects all subsequent data exchange. The security policy is entirely configuration-driven through certificate and key files in security, allowing system administrators to enforce authentication and encryption requirements without any application code changes.



	<pre>		<pre>

Dimitri: /* Operation */

2026-01-03T09:21:42Z

Operation

← Older revision		Revision as of 09:21, 3 January 2026
Line 83:		Line 83:
	\| 4. Sign header with client key \|		\| 4. Sign header with client key \|
	\| \|		\| \|
	\|-------- FLOW_REQ (OAP_HDR) ------------->\|		\|-------- FLOW_REQ (OAP_HDR) -------------> \|
	\| \|		\| \|
	\| \| 5. Load server cert/key		\| \| 5. Load server cert/key
Line 93:		Line 93:
	\| \| 11. Sign with server key		\| \| 11. Sign with server key
	\| \|		\| \|
	\|<------- FLOW_REPLY (OAP_HDR) ------------\|		\|<------- FLOW_REPLY (OAP_HDR) ------------ \|
	\| \|		\| \|
	\| 12. Verify server cert against CA \|		\| 12. Verify server cert against CA \|

← Older revision		Revision as of 00:02, 7 January 2026
Line 7:		Line 7:
	====================		====================

	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		* 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 \| \|		* + id (128 bits) + \|
	+ + \|		* \| Unique flow allocation ID \| \|
	\| \| \|		* + + \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| \| \|
	\| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+ timestamp (64 bits) + \|		* \| \| \|
	\| UTC nanoseconds since epoch \| \|		* + timestamp (64 bits) + \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| UTC nanoseconds since epoch \| \|
	\| crt_len (16 bits) \| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \|		* \| crt_len (16 bits) \| \| \|
	\| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \|
	+ ~~+ \|~~		* \| \| \|
	\| certificate (variable) \| \|		* + certificate (variable) + \|
	+ X.509 certificate, DER encoded + \|		* \| X.509 certificate, DER encoded \| \|
	\| \| \|		* + + \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| \| \|
	\| \| eph_len (16 bits) \| \| ~~Signed~~		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| ~~Region~~		* \| eph_len (16 bits) \| \| \| Signed
	\| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \| Region
	+ + \|		* \| \| \|
	\| ~~ephemeral_key~~ (~~variable~~) \| \|		* + ephemeral_key (variable) + \|
	+ ~~public key, DER encoded~~ + \|		* \| public key, DER encoded \| \|
	\| \| \|		* + + \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| \| \|
	~~\| \| data_len (16 bits) \| \|~~		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| cipher_len (16 bits) \| \| \|
	\| \| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \|
	+ data (variable) + \|		* \| \| \|
	\| Piggybacked application data \| \|		* + cipher (variable) + \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		* \| symmetric cipher name (UTF-8) \| \|
	~~\| \| sig_len (16 bits) \| \|~~		* + + \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~---~~+		* \| \| \|
	\| \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	+ +		* \| data_len (16 bits) \| \| \|
	\| signature (variable) \|		* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \|
	+ DSA signature over signed region +		* \| \| \|
	\| \|		* + data (variable) + \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		* \| Piggybacked application data \| \|
			* + + \|
			* \| \| \|
			* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
			* \| sig_len (16 bits) \| \|
			* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
			* \| \|
			* + signature (variable) +
			* \| DSA signature over signed region \|
			* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			*/

	Field Summary:		Field Summary:
Line 63:		Line 73:
	\| eph_len \| 2 bytes \| Ephemeral key length (0 = no encrypt) \|		\| eph_len \| 2 bytes \| Ephemeral key length (0 = no encrypt) \|
	\| ephemeral_key \| variable \| DHE public key \|		\| ephemeral_key \| variable \| DHE public key \|
			\| cipher_len \| 2 bytes \| Cipher name length (0 = no cipher) \|
			\| cipher \| variable \| Name of the cipher to use \|
	\| data_len \| 2 bytes \| Application data length \|		\| data_len \| 2 bytes \| Application data length \|
	\| data \| variable \| Piggybacked app data (future use) \|		\| data \| variable \| Piggybacked app data (future use) \|
Line 69:		Line 81:
	+---------------+----------+----------------------------------------+		+---------------+----------+----------------------------------------+

	Minimum header size: 16 + 8 + 2 + 2 + 2 + 2 = 32 bytes (no optional fields)		Minimum header size: 16 + 8 + 2 + 2 + 2 + 2 + 2 = 34 bytes (no optional fields)

	</pre>		</pre>

← Older revision		Revision as of 10:42, 3 January 2026
Line 30:		Line 30:
	\| \| \|		\| \| \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	\| \| eph_len (16 bits) \| \|		\| \| eph_len (16 bits) \| \| Signed
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \| Region
	\| \| \| ~~Signed~~		\| \| \|
	+ + \| ~~Region~~		+ + \|
	\| ephemeral_key (variable) \| \|		\| ephemeral_key (variable) \| \|
	+ public key, DER encoded + \|		+ public key, DER encoded + \|

← Older revision		Revision as of 10:41, 3 January 2026
Line 32:		Line 32:
	\| \| eph_len (16 bits) \| \|		\| \| eph_len (16 bits) \| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	\| \| \|		\| \| \| Signed
	+ + \|		+ + \| Region
	\| ephemeral_key (variable) \| \|		\| ephemeral_key (variable) \| \|
	+ public key, DER encoded + \|		+ public key, DER encoded + \|