Frame Types

Broadcast Packet

Broadcast packets carry a source and payload, but no security info.

+-----+-------+-----+---------+---------+
| FCF |[FHOPS]| SRC | OPTIONS |[PAYLOAD]|
+-----+-------+-----+---------+---------+
  1 B   0/1 B  3/32B  variable    var.

A broadcast with an empty payload is a Beacon. Beacons omit the 0xFF end-of-options marker since no payload follows (see End-of-Options Marker).

MAC Ack Packet

A MAC acknowledgement is generated by the final destination — the node that successfully processes and accepts the original packet. Repeaters do not generate MAC acks; they forward ack packets like any other packet type.

If the original packet is received again because its acknowledgement was lost, the final destination MAY retransmit the same acknowledgement without accepting or delivering the original packet again, subject to the bounded duplicate-acknowledgement window.

The ack carries two fixed trailer fields: an ack MIC — the first four bytes of the original packet’s MIC, which lets the original sender (and any repeater that forwarded the original) correlate the ack with the packet it acknowledges — and an ack tag — a keyed value that only the original sender can verify. The ack carries no destination hint. See Ack Tag Construction for the derivation.

+-----+-------+---------+---------+---------+
| FCF |[FHOPS]| OPTIONS | ACK MIC | ACK TAG |
+-----+-------+---------+---------+---------+
  1 B   0/1 B  variable     4 B       4 B

Where:

• ACK MIC is the first 4 bytes of the original packet’s on-wire MIC — a publicly derivable correlation handle, not an authenticator
• ACK TAG is a 4-byte keyed value derived from the original packet’s MIC and the pairwise encryption key (see Ack Tag Construction)

The ACK MIC is public — any observer who received the original packet can compute it — so it provides correlation, not authentication. Authentication comes from the ACK TAG, which requires knowledge of the pairwise K_enc and cannot be produced by an observer who lacks it, even one who received the original packet in its entirety. Because the ack carries no destination hint and the correlation handle is only a prefix of the (already public) original MIC, the ack adds no explicit endpoint identifier: an observer who received the original packet learns that it was delivered, but the ack itself names neither party. This removes the direct sender-identity leak a destination hint would introduce; it does not by itself defeat correlation by other means (timing, RF fingerprinting, or tying the ack back to an original packet that already exposed endpoint hints). For blind unicast, whose forward frame conceals both endpoints from non-channel observers, this keeps the ack from undoing that concealment.

Because the ack carries no destination hint, it is a return-routed token: it is routed back to the original sender using whatever routing state is available — a cached source route, a cached flood response scoped by FHOPS_ACC and any learned region-code options, or both. See Route Learning for how nodes learn and cache routing information from incoming packets. For reliable ack delivery over long source-routed paths, the original sender should include a trace-route option. The original sender matches an incoming ack to an outstanding request by its ACK MIC, then verifies the ACK TAG; a colliding ACK MIC from an unrelated exchange fails tag verification and is discarded.

Because the ack trailer (ACK MIC followed by ACK TAG) is a known fixed length and no payload follows, the options field MUST be followed immediately by the trailer with no intervening bytes. The 0xFF end-of-options marker MAY be omitted (the trailer length is what bounds the options region). If the marker is present it MUST be the last byte of the options region — receivers MUST reject packets that carry trailing bytes between the marker and the ack trailer.

Unicast Packet

Unicast packets are addressed by destination hint and carry the source address.

+-----+-------+-----+-----+---------+---------+---------+------+
| FCF |[FHOPS]| DST | SRC | SECINFO | OPTIONS |[PAYLOAD]| MIC  |
+-----+-------+-----+-----+---------+---------+---------+------+
  1 B  0/1 B   3 B  3/32B   5/7 B    variable    var.   4-16 B

DST is the first three bytes of the recipient’s public key.

Receivers first use DST as a cheap filter, then use the source public key (or its cached equivalent when only a hint is present) and their own key to derive the shared secret and authenticate/decrypt the packet.

Unicast Packet with Ack Requested

This is identical to unicast, but the packet-type value signals that a MAC acknowledgement is requested.

+-----+-------+-----+------+---------+---------+---------+------+
| FCF |[FHOPS]| DST | SRC  | SECINFO | OPTIONS |[PAYLOAD]| MIC  |
+-----+-------+-----+------+---------+---------+---------+------+
  1 B  0/1 B   3 B   3/32B   5/7 B    variable    var.   4-16 B

Semantics differ, wire layout does not.

Multicast Packet

Multicast packets carry a 2-byte channel identifier derived from the channel key.

Channel Identifier Derivation

channel_id = first_2_bytes( HKDF-SHA256(channel_key, salt="UMSH-CHAN-ID", info="", L=2) )

Encrypted Multicast (E = 1)

When encryption is enabled, the source address is encrypted together with the payload, concealing the sender’s identity from observers who do not possess the channel key.

+-----+-------+---------+---------+---------+----------------------+------+
| FCF |[FHOPS]| CHANNEL | SECINFO | OPTIONS | ENCRYPT(SRC+PAYLOAD) | MIC  |
+-----+-------+---------+---------+---------+----------------------+------+
  1 B  0/1 B     2 B     5/7 B    variable       3/32 + var.      4-16 B

The SRC inside the ciphertext follows the S flag convention: a 3-byte hint when S is clear, or the full 32-byte public key when S is set.

Only a node with the correct channel key can recover the source address and payload.

Unencrypted Multicast (E = 0)

When encryption is not enabled, the source address appears in cleartext, but in the same place that it appeared in encrypted multicast:

+-----+-------+---------+---------+---------+------+---------+------+
| FCF |[FHOPS]| CHANNEL | SECINFO | OPTIONS | SRC  | PAYLOAD | MIC  |
+-----+-------+---------+---------+---------+------+---------+------+
  1 B  0/1 B     2 B     5/7 B    variable  3/32 B    var.   4-16 B

Blind Unicast Packet

Blind unicast uses a multicast channel to conceal sender and destination metadata from observers without the channel key while still protecting the payload end-to-end for the actual destination.

Like other channel-addressed packets, blind unicast honors the E flag in SECINFO.

Encrypted Blind Unicast (E = 1)

+-----+-------+---------+---------+---------+-------------+-------------+------+
| FCF |[FHOPS]| CHANNEL | SECINFO | OPTIONS | ENC_DST_SRC | ENC_PAYLOAD | MIC  |
+-----+-------+---------+---------+---------+-------------+-------------+------+
  1 B  0/1 B     2 B     5/7 B    variable      6/35 B         var.     4-16 B

The MIC is computed over the payload using the blind unicast payload keys, which combine the pairwise shared secret with the channel key. ENC_DST_SRC is encrypted using the channel’s derived encryption key K_enc_channel (see Multicast Packet Keys) and the MIC as IV (see Security & Cryptography). Because ENC_DST_SRC decryption depends on the MIC, any tampering with the source address will produce an incorrect public key, causing pairwise key derivation to fail and payload authentication to reject.

Unencrypted Blind Unicast (E = 0)

When encryption is disabled, blind unicast still uses the channel identifier and the blind-unicast packet type, but the destination hint, source address, and payload appear in cleartext:

+-----+-------+---------+---------+---------+-----+------+---------+------+
| FCF |[FHOPS]| CHANNEL | SECINFO | OPTIONS | DST | SRC  | PAYLOAD | MIC  |
+-----+-------+---------+---------+---------+-----+------+---------+------+
  1 B  0/1 B     2 B     5/7 B    variable   3 B  3/32 B    var.   4-16 B

In this mode, the packet remains channel-associated and authenticated with the blind-unicast keys, but it does not conceal sender or destination metadata. This can still be useful when an implementation wants channel-associated unicast semantics without encryption.

Blind Unicast Processing

1. Receiver uses CHANNEL to identify candidate channel keys.
2. Receiver derives the channel’s candidate keys via HKDF.
3. If E = 1, receiver reads the MIC and uses K_enc_channel plus MIC to decrypt ENC_DST_SRC, recovering the destination hint and sender address.
4. If E = 0, receiver reads DST and SRC directly from the cleartext packet.
5. Receiver converts the sender Ed25519 public key into an X25519 public key.
6. Receiver converts its own Ed25519 private key into an X25519 private key.
7. Receiver performs ECDH and derives the stable pairwise keys.
8. Receiver computes the blind unicast payload keys by XORing the pairwise keys with the channel keys.
9. Receiver authenticates the packet using the blind-unicast MIC.
10. If E = 1, receiver decrypts ENC_PAYLOAD using the blind unicast payload keys.
11. If authentication fails, the packet is rejected.

Some repeaters may decline to forward blind unicast packets for unknown channels.

Blind Unicast with Ack Requested

Same wire layout as blind unicast, but with ack-requested semantics.

+-----+-------+---------+---------+---------+-------------+-------------+------+
| FCF |[FHOPS]| CHANNEL | SECINFO | OPTIONS | ENC_DST_SRC | ENC_PAYLOAD | MIC  |
+-----+-------+---------+---------+---------+-------------+-------------+------+
  1 B  0/1 B      2 B     5/7 B    variable     6/35 B         var.     4-16 B