Antheos Defence Layer

This specification is a draft. It may change in ways that break compatibility, and no implementation of it is published at present.

ANTHEOS_DEFENCE_LAYER_SPEC.md (Markdown, 45,446 bytes)

Version 0.1 — Level 2 Specification - Defence

© Are Bjørby are.bjorby@langsyn.org November 2026

This is a draft. Its proof is HMAC-SHA-256, and it admits a device over the Antheos Security Layer. The way it uses them, and the way they fit Level 1, are this document's own, and no cryptographer has reviewed them. Its worked example was computed by a script, and it has been exercised in no model and on no bus.

Contents

1. Introduction
2. Design Principles
3. Terms and Definitions
4. Defence Buses
5. Defence Sessions
6. Admission
7. Proofs
8. Admission Traffic
9. Signs of Attack
10. Telling an Attack
11. Guards and Gateways
12. Level 1 Behaviour
13. Conformance
14. Cost
15. Security Considerations
16. Licensing

• Appendix A: Worked Example
• Appendix B: Revision History

1. Introduction

Any device on an Antheos bus can send any message as any BID (Level 1 Section 15). The Security Layer protects what a session carries and leaves the bus itself open: a forger can still stop a session, take a BID, answer a Query, or end what an Exception answers (Security Section 13). Some buses can be built to keep a device out, at a port or at a coordinator, and the devices on them may still never learn that one tried.

This document defines the Antheos Defence Layer, a Level 2 protocol that does two things. On a bus that runs admission, it keeps out every device that has not been admitted: each frame carries a proof made with a key that only admitted devices hold, and a receiver refuses a frame without one. On any bus, it names the signs of an attack, and has a device tell them by an Exception, by a report to its Tether, and by its own lights and sounds.

"Level 1" means the Antheos Protocol, Version 1.10, Level 1 Specification - Transport. "Security" means the Antheos Security Layer, Version 0.4, Level 2 Specification - Security. "Level 1 Section 9.8" and "Security Section 5.2" refer to those documents, and "Section 6" to this one.

The layer needs no change to Level 1 or to the Security Layer: no new symbol, word, verb or record kind. Its exception reasons are of the kind Level 1 lets an implementation define (Level 1 Section 13). Neither document requires this layer or knows of it. A device's designer may use it, replace it with another, or use none. Another layer takes another capability and another domain string (Sections 5.1 and 7.2), and shares nothing with this one.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals, as shown here.

2. Design Principles

• Kept out, not argued with: On a Defence bus, a frame without a valid proof moves no state. To Level 1 it is a frame that was lost (Section 7.5).
• Beneath everything that reads a frame: A sender adds the proof last and a receiver removes it first, so Level 1 and the Security Layer read the frame they would have read without this layer (Section 7.1).
• Who admits is the designer's: The layer says what an admission decision gives the protocol, a static key accepted or refused, and not who makes it (Section 6.1).
• Every channel a device has: An attack is told by Exception, by Tether, and by light and sound: by whichever a device has, and by all of them if it has all (Section 10).
• Works without a guard: A plain shared wire has no place for protection to sit. Nothing here needs one, and a guard is the designer's (Section 11).
• Not invented here: The proof is HMAC-SHA-256, and admission runs over the Security Layer's handshakes (Sections 6.2 and 7.2).
• Says what it does not do: Section 15 says what admitted devices can still do, and what no device can stop.

3. Terms and Definitions

4. Defence Buses

Whether a bus is a Defence bus is fixed by its designer before any device joins it, by what its devices were built to do or by how they were set up. It is never negotiated on the bus and no frame changes it, so a Defence bus cannot be downgraded.

On a Defence bus every instance that matters runs this layer. A proof is a BLOB word that Level 1 alone does not expect: to an instance that does not run the layer, a proven frame is malformed where its verb fixes its payload (Level 1 Sections 7.4 and 9.2.2), and elsewhere its payload is read with a block that is not the application's. Such an instance is, to the bus, one that was never admitted, and nothing it sends unproven is read.

On a plain bus no frame carries a proof. The layer's signs (Section 9) and its telling (Section 10) still apply there, and an attack Exception there is advisory (Section 10.1).

A device on more than one bus runs the layer on each as that bus is: as a Defence bus on one, as a plain bus on another, and not at all on a third, as its designer chooses.

5. Defence Sessions

5.1 Carriage

A Defence message is the content of one Security transport record (Security Section 6.3). It travels in a Defence session: a session that runs the Security Layer and carries Defence messages and nothing else. A Defence session is opened for the capability antheos-defence-1, which an Accept takes (Level 1 Section 10.3), or by a direct open to an instance known to serve it (Level 1 Section 11.1.1). A session opened for that capability runs the Security Layer, since it is what such devices are built to do (Security Section 7.1).

A message's first byte is its kind, and the bytes after it are fixed by its kind. A message of any other kind, or of the wrong length for its kind, is refused and moves nothing.

A message sent as a Request goes in a session its sender opened, since only a session's opener sends requests (Level 1 Section 11.1.2). The other end sends its messages as Events. A Request that wants no message back is answered with an Answer of empty content.

5.2 Messages

Kinds 1 to 6 travel in a device's admission session with its admitter (Section 6.2), and kinds 7 and 8 in its session with its Tether (Section 10.2).

6. Admission

6.1 The Admitter

A Defence bus has one admitter at a time: an instance on the bus that holds its current key, grants it, and rotates it. Which instance that is, and who decides whom it admits and whom it blocks, are the designer's, as Security Section 5.2 leaves the acceptance of a key. A guard (Section 11) may be the admitter, and so may any other device.

An admission decision gives the protocol one thing: a newcomer's static key (Security Section 5.1), accepted or refused. A block gives it one more: the static key of an admitted device, which is not granted the next epoch. How the decision is made, by a pinned list, by a person asked, or by a signature over the key, is the designer's.

A device that is to join a Defence bus holds its admitter's static public key before it joins, by whatever means its designer chooses. That key, and nothing on the bus, is what tells it that it has reached the admitter.

6.2 Joining

1. The newcomer establishes a BID (Level 1 Section 9.1, as Section 8 reads it).
2. It finds the admitter, by a Query for antheos-defence-1 or by its designer's knowledge of the admitter's BID, and opens a Defence session with it, as the session's opener and the handshake's initiator. It SHOULD use XK (Security Section 4.1), since it already holds the admitter's key, so that the admitter shows its static key to no stranger (Security Section 4.2).
3. It refuses a responder whose static key is not the admitter's, as Security Section 5.2 refuses a key, and tries the next Offer, if it has one.
4. It sends a Join.
5. The admitter accepts or refuses the newcomer's static key, and answers the Join with a Grant, with a Refused, or with a Pending while its decision is still to be made. A Pending is followed by a Grant or a Refused, sent as an Event. After a Refused, the admitter sends a Finish.
6. On a Grant, the device is admitted. It takes the key, draws a handle (Section 7.2), and proves every frame it sends from then on (Section 7.3).

A device MAY keep its admission session for as long as it is on the bus, to receive later Grants as Events (Section 6.3). One that does not learns of a new epoch from the frames it cannot verify. A device that refuses a frame because its proof names an epoch it holds no key for MAY send a Join, in its admission session or in a new one, at most once in an interval of its designer's choosing. The admitter answers a Join from a device it admits with a Grant of the current epoch.

6.3 Epochs

The admitter MUST draw each bus key from a cryptographically secure source, fresh for every epoch. Epochs run from 1 to 65535, each the one before plus one, and 1 follows 65535. Every epoch's key is fresh, so a frame proven under an earlier use of an epoch's number does not verify under its later one.

To start a new epoch, the admitter sends a Grant of it, as an Event, to every device it admits and means to keep. A device that receives a Grant of an epoch it does not hold:

• keeps the key it held as its previous key,
• takes the new key as its current key, and draws a new handle for it (Section 7.2),
• proves under its current key from then on, and
• sends a Held naming the new epoch.

A device holds at most two keys, its current and its previous, and accepts frames proven under either. It drops its previous key when a Retire names that key's epoch, or when a time of its designer's choosing has passed since the Grant, whichever comes first.

The admitter sends a Retire of the old epoch once every device it granted the new one to has sent a Held, or once a time of its designer's choosing has passed.

An admitter that has lost its key, by a reset for example, starts a new epoch and grants it to every device it admits. What it keeps through a reset in order to do so, the static keys it admits for example, is the designer's. The key itself it does not keep (Section 6.5).

6.4 Blocking

The admitter blocks a device by starting a new epoch and granting it to every device it admits except that one. A block takes effect when the old epoch is retired, and not when it is decided: until then, a device still holding the old key as its previous key accepts the blocked device's frames under it.

A blocked device's frames after that are proven under a retired epoch, and are refused as unadmitted (Section 9). Its Join is refused. Whether the admitter tells it so, with a Refused sent as an Event, is the designer's: telling a faulty device helps its owner, and telling a hostile one tells its attacker that it was seen.

6.5 Holding Keys

A bus key MUST live in volatile memory only, and dies at a reset. A device that resets is a newcomer, and joins again (Section 6.2). A key kept in storage would leave with a captured device, and let its captor back onto the bus until the next block.

7. Proofs

7.1 Carriage

On a Defence bus, every frame an admitted device sends carries a proof: a BLOB word declaring 26 bytes, written ↕*♦D•B→26► and in no other spelling, as the frame's first payload word, directly after its ID words (Level 1 Section 7.6). Its block is therefore the first block of the frame's tail (Level 1 Section 7.3).

Pseudo:  [SOM] [SOW]![SOB]P[EOW] [SOW]@[SOR]U[SOB]4T9X2[EOW] [SOW]*[SOR]D[SOU]B[SOB]26[EOW] [EOM] <26 bytes>
Wire:    ☻↕!→P►↕@♦U→4T9X2►↕*♦D•B→26►♥

A Ping to 4T9X2, with its proof of 26 bytes in its tail.

The first payload word is the one place a proof can stand in every frame: a path-addressed message ends with its index and its PATH (Level 1 Section 9.3), and every verb's ID words come first.

A sender composes a frame as Level 1, and anything above it, would compose it without this layer, and adds the proof as the last step before the frame is sent. A receiver removes the proof word and its block first, so the frame that Level 1 and the Security Layer read is the one they would have read without this layer. A record's one BLOB word and no other payload word (Security Section 6.1) is true of that frame.

7.2 The Proof

proof = epoch (2 bytes, big-endian) | handle (4 bytes) | counter (4 bytes, big-endian) | tag (16 bytes)
tag   = the first 16 bytes of HMAC-SHA-256(bus key, M)
M     = "antheos-defence-1" | epoch | handle | counter | head | tail

"antheos-defence-1" is its 17 ASCII bytes. head is the frame's head, from SOM through EOM, without the proof word, and tail is the frame's tail without the proof's block: together they are the frame as Level 1 composed it. The epoch names the bus key the proof is made under. A later version of this layer takes another domain string, so that the proofs of two versions never verify for each other.

The handle is four bytes that a device draws from a cryptographically secure source each time it is granted a key, for that key. The counter runs from 1 to 4294967295 under a handle. A device whose counter would pass 4294967295 draws a new handle and counts from 1 again.

7.3 Sending

Every transmission is proved afresh. A frame that Level 1 sends again, a retransmitted Call for example (Level 1 Section 11.3), takes the next counter and a new tag, so that a receiver can tell a frame sent again from a frame replayed.

A device proves under its current key. A device that takes a new BID, by a Resume or by a new Establish, SHOULD draw a new handle, since the handle would link the two (Section 15).

7.4 Receiving

A receiver on a Defence bus acts on no part of a frame until it has run these steps:

1. The frame's first payload word is the proof word of Section 7.1, or the frame is unproven.
2. Its epoch names a key the receiver holds, or the frame is unproven.
3. Its counter is not 0, and is above the mark for its epoch and handle, or within the receiver's window below the mark and not accepted before. Otherwise the frame is a replay, and is unproven.
4. Its tag verifies, or the frame is unproven.
5. The mark moves to its counter, if that is higher. The proof word and its block are removed, and the frame goes to Level 1.

The window is a number of counters from 0 to 64, of the receiver's own choosing. A window of 0 accepts counters in rising order only, which a bus that keeps the order of frames allows. How many handles a receiver keeps marks for, and which it forgets when it must, are its designer's.

A frame proven under the receiver's own handle is its own frame read back (Level 1 Section 12) if its counter is at or below the last the receiver sent, and goes to Level 1 without a mark. One whose counter is above the last the receiver sent was not its own: another device drew the same handle, or an admitted device is copying it. The receiver draws a new handle.

The proof covers the whole tail, so a receiver reads the whole tail before step 4. It MAY hold the head, which is short, until the proof's block arrives, and run the rest of the tail into the tag as it arrives.

7.5 Refusal

An unproven frame moves no Level 1 state, unless it is admission traffic that the receiver reads (Section 8). To Level 1 it is a frame that was lost, which Level 1 already allows for: no unproven Establish draws a Conflict, no Ping draws an answer, no Finish closes a session, and no Exception refuses anything. The receiver skips the rest of its tail with the frame whole, as Level 1 skips a malformed message's (Level 1 Section 7.4). A refused frame draws no answer from Level 1, and may be a sign (Section 9).

Level 1 has no checksum, so a frame corrupted in transit fails its tag and is refused as a forged one is. It costs what a lost frame costs.

8. Admission Traffic

A newcomer holds no key, so it can prove nothing it sends until it is admitted. On a Defence bus, a receiver reads these frames unproven, and no others:

The admitter holds no more admission sessions with newcomers at a time than its designer allows. It reads no other unproven message of an admission session, and lets such a session end by its idle time and its timeout (Level 1 Sections 11.1.3 and 11.1.5), so that a forged Finish cannot end one.

A newcomer reads every frame, proven or not, since it cannot tell a proof from noise. Until it is admitted, nothing that reaches it is more trustworthy than on a plain bus, and the one thing it trusts is the admitter's key, which the Security Layer's handshake authenticates. A newcomer yields its BID to an Establish or a Conflict for it that carries a proof word, and establishes another.

9. Signs of Attack

Each sign has a reason of its own. Each reason is of Bus scope, and is addressed as Level 1 Section 9.8 sets out, as Level 1 Section 13 requires of a reason it does not define. Which signs a device watches for, and the thresholds at which it tells one, are its designer's. On a Defence bus, refusing an unproven frame is not: Section 7.5 holds whether or not a device watches.

A frame that shows more than one sign is told by its most specific reason: by any other before UNADMITTED_FRAME.

An attack Exception reports to the bus and not within a session, so FORGED_CONTROL is of Bus scope although what it reports is a session's (Level 1 Section 13).

A sign is a judgement over traffic. Level 1 has no checksum, so one corrupted frame looks like one forged frame, and a threshold of one makes a noisy bus an attacked one. The thresholds are the designer's for that reason.

10. Telling an Attack

A device that sees a sign, or reads an attack Exception, MUST tell it by every channel of this section that it has: by an Exception if it implements Level 1's Exception feature (Level 1 Section 14.2), by a report if it has a Tether, and by an alert if it has a light or a sound for one. A device that has all three uses all three. Which lights and sounds a device has for alerts is its designer's; those it has, it uses.

10.1 Exceptions

An attack Exception names its sender's BID alone. It is a report to the bus and answers no message, so it is addressed as an Exception that answers a message naming no sender (Level 1 Section 9.8), and every instance on the bus reads it. It never names a target: Level 1 has an instance drop an Exception that names another instance as its target, so only the target would read it.

After its reason it MAY carry one TEXT word: the first BID that the frame showing the sign names, which is its sender's where it names its sender. A sign seen over many frames names the BID most of them named, or none.

Pseudo:  [SOM] [SOW]![SOB]X[EOW] [SOW]@[SOR]U[SOB]7M3K9[EOW] [SOW]~[SOB]BID_SQUAT[EOW] [SOW]~[SOB]4T9X2[EOW] [EOM]
Wire:    ☻↕!→X►↕@♦U→7M3K9►↕~→BID_SQUAT►↕~→4T9X2►♥

On a plain bus, 7M3K9 tells the bus that Establishes are being sent for 4T9X2, a BID an instance holds.

On a Defence bus an attack Exception carries its sender's proof, as every frame there does (Appendix A.3). A proven one is an attack told by an admitted device. An unproven one is itself a sign, an UNADMITTED_FRAME, which the receiver alerts on and reports, and answers with no Exception.

On a plain bus an attack Exception is advisory, since anyone can send one. A device alerts on it as Unverified (Section 10.3), and reports it so marked.

No Exception answers an attack Exception, so no two devices can keep each other telling. To keep the bus quiet, a device that is about to send one:

1. Waits a time drawn at random between zero and a bound of its designer's.
2. Sends none if, in that time, it reads an attack Exception with the same reason and the same BID or lack of one, proven if the bus is a Defence bus.
3. Sends at most one Exception with any one reason in an interval of its designer's choosing.

A limit for each reason, and not for each offender, holds against an attacker that changes the BIDs it uses. These limits apply to Exceptions alone: a device still alerts, and still counts what it reports.

An attack Exception carries no PATH and does not travel beyond its bus (Level 1 Section 9.3).

10.2 Tether Reports

A device's Tether is the party it answers to and reports to: an instance that holds its owner's keys. Which party that is, how the device reaches it, and which key it accepts as its Tether's are the designer's (Security Section 5.2). A device has at most one Tether, and may have none.

A device with a Tether holds a Defence session with it, over whichever bus or link reaches it, and sends a Report for each sign it sees and each attack Exception it reads:

Bus is the device's own number for the bus the Report is about, and 0 if it has one bus. Count is how many times the device saw or read what it reports since its last Report with the same what and the same reason, at most 65535. A device MAY therefore gather Reports and send fewer, losing nothing but their timing; the head is the latest one's.

A device that has a Tether and cannot hold a session with it, for a time of its designer's choosing, is in the Tether lost state (Section 10.3).

A Report sent over the bus under attack can be stopped by the attacker. A Tether reached over another bus or link is RECOMMENDED.

10.3 Alerts

A device's alerts are the one channel an attacker on the bus cannot stop. A device with a light or a sound for alerts has these states, and shows each one it is in by every light and sound it has for them:

The forms are the designer's. The recommended ones differ by rhythm and not by colour, so that a light of one colour shows them all, and so that someone who cannot tell colours apart can read them. A device with one light, in more than one state, shows the first of its states in the table. A device with a display MAY also show the reason and the BID.

Attack seen and Unverified hold until they are cleared: by a Clear from the device's Tether, by a person at the device, or after a time of its designer's choosing in which no sign has been seen. States, in a Clear, is a bit field: bit 0 clears Attack seen, bit 1 clears Unverified, and every other bit is 0. Tether lost clears itself when the session is held again. A state that clears itself while no one is near has told no one, so clearing by a person or by a Tether is RECOMMENDED.

11. Guards and Gateways

A guard is where a bus's own protection sits: a gateway, a port of a star-wired bus, or a bus's coordinator. Whether a bus has one, and how it works, are the designer's. A plain shared wire has none, and nothing in this layer needs one.

A guard that is an instance tells an attack as any device does (Section 10). It MAY also keep frames off the bus, as a port that refuses unproven frames before they reach any device would. No device relies on a guard: a frame a guard let through is verified as any other frame is, since a guard can be bypassed, and on some buses cannot see every frame.

Beyond its bus, Level 1 carries a broadcast that carries a PATH, a Relay and RELAY_FAILED, through an instance on more than one bus (Level 1 Section 9.3). Such a gateway proves what it sends on a Defence bus as any admitted device does, under the key of the bus it sends on, and carries no proof from one bus to another. Its proof shows that the gateway sent the frame, and nothing about who sent it before.

A gateway forwards onto a Defence bus only what it would act on itself: from another Defence bus, frames proven there, and from a plain bus, what its designer trusts.

12. Level 1 Behaviour

Establish and Conflict: An admitted device ignores unproven Conflicts and rival Establishes while it establishes a BID, so a forger cannot keep it from one (Level 1 Section 15). A newcomer has no such defence (Section 8).

Scaleback: A device on a Defence bus states its Scaleback limits for the frame as Level 1 reads it, without its proof, and takes the proof's 10 head bytes and 26 tail bytes beyond them. A Scaleback's exclusions do not govern the proof word. An unproven Scaleback is refused, so a device that is not admitted cannot tell a sender that its target takes no tail.

Retransmission: Level 1 sends again the bytes it kept (Level 1 Section 11.1.2), and this layer proves them afresh (Section 7.3).

Resume: A proven Resume shows that an admitted device sent it, and not which one (Section 15).

Reset: A device that resets has lost its bus key (Section 6.5), and joins again before it sends anything but admission traffic.

Discover and Offer: An unproven Discover response or Offer is refused, so a device that is not admitted can hijack no route and no Offer (Level 1 Section 15). A newcomer reads an Offer for antheos-defence-1 whoever sends it, and a false admitter fails at the newcomer's acceptance of its key (Section 6.2).

Broadcast: An unproven broadcast Ping or Query draws no answer, so a device that is not admitted cannot make the bus answer it.

Tail size: A proof is verified only once the whole tail has been read, so this layer does not stop tail exhaustion (Level 1 Section 15).

13. Conformance

An instance that runs this layer on a Defence bus MUST:

• Implement the Security Layer as an initiator of XX, XK or both, and say which (Security Section 11).
• Hold every rule of Sections 5 to 8 and of Section 12.
• Hold Section 10 for every channel it has.

An admitter MUST also implement both XX and XK as a responder, so that every newcomer can join.

An instance that runs this layer on a plain bus MUST hold Sections 9 and 10. It needs the Security Layer only to reach a Tether.

A claim of conformance says on which kinds of bus the instance runs the layer, whether it can be an admitter, and which channels of Section 10 it has.

14. Cost

This section is non-normative.

A proof adds 36 bytes to every frame on a Defence bus, 10 in the head and 26 in the tail:

On a bus carrying about 1.4 kB/s, the 36 bytes take about 26 ms on the wire.

A proof costs one HMAC-SHA-256 to make and one to verify. For a frame of n bytes without its proof, that is 3 + ⌈(n + 36) / 64⌉ SHA-256 compressions: 4 for the Ping above. A device that keeps its key's inner and outer states, as HMAC allows, saves 2 of them. How long that takes depends on the device, and has been measured on none.

A frame with no proof word, or with an epoch the receiver holds no key for, is refused before any hashing. A replay is refused by its counter, also before it.

A receiver keeps 16 bytes or fewer for each handle it marks: the handle, the mark, and a window of up to 64 bits.

Joining costs one Security handshake (Security Section 12). A new epoch costs a Grant and a Held for each device the admitter keeps.

15. Security Considerations

What the layer protects: On a Defence bus, every instance against every device that holds no key of the bus: a newcomer that has not been admitted, a device that was blocked once its epoch is retired, and anything that sends on the wire without being a device of the bus. Their frames move no state.

A shared key: Every admitted device holds the same key, so any admitted device can send any frame as any other, under any handle, and no receiver can tell. The layer keeps out the devices that do not hold the key, and blocks a device only once something has shown it to be hostile. A proof of each device that every receiver could check would need a signature on every frame or a key for every pair of devices, which costs more than the smallest devices on a bus can carry.

A block is not immediate: It takes effect when the old epoch is retired (Section 6.4). An admitter that retires sooner cuts off the devices that have not yet sent a Held.

Newcomers: A device that has not yet been admitted is as exposed as on a plain bus. It can be kept from a BID, from the admitter and from its admission, and its one assurance is the admitter's key (Section 6.2).

The admitter: While it is absent, no device joins and no key rotates, and admitted devices go on under the keys they hold. A captured admitter gives its captor the bus.

First-seen replays: A receiver with no mark for a handle accepts a replay of that handle's frames, once each, within the epoch: a receiver that joined after they were sent, or that forgot the handle's mark. A new epoch ends it.

Linking: The handle links a device's frames within an epoch, as its BID already does (Level 1 Section 15), and links two BIDs if a device keeps it across a change of BID (Section 7.3).

Forged alerts: On a plain bus anyone can send an attack Exception, and enough false ones teach people to ignore true ones. That is why a device marks them Unverified, and why it limits what it sends (Section 10.1).

What an alert tells: A device that alerts shows an attacker that it was seen, and which signs it watches for.

Availability: A device that jams the wire, or fills it with frames, stops the bus, and this layer cannot prevent it. Each frame it sends costs a receiver steps 1 to 3 of Section 7.4, and an HMAC if the frame looks proven. The layer offers no availability. A device's alerts, which need no bus, are how a jammed bus is told.

Confidentiality: None. A Defence bus is as readable as any other, and a session's content is the Security Layer's to protect.

Post-quantum: HMAC-SHA-256 under a 32-byte key is not known to be weakened by a quantum computer below a margin that matters. A bus key travels in a Security session, which is not post-quantum secure (Security Section 13), so a recorded admission opened later gives the key of its epoch. A retired epoch's key proves nothing any receiver accepts, so this matters only while the epoch is current.

16. Licensing

MIT License

Copyright (c) 2026 Are Bjørby are.bjorby@langsyn.org

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification and associated documentation files (the "Specification"), to deal in the Specification without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification.

THE SPECIFICATION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SPECIFICATION OR THE USE OR OTHER DEALINGS IN THE SPECIFICATION.

Appendix A: Worked Example

This appendix is non-normative. Its key is for this example and for nothing else.

The bus key of epoch 1 is 6b1f9e04c2d85a3377a0e1c94f2b6d8135ce0a7f92b4e6d1083fa5c71e9d2b40. The device 7M3K9 was granted it, and drew the handle 1a2b3c4d.

A.1 A Grant

The content of the admitter's Answer to 7M3K9's Join, in their admission session, before the Security Layer seals it: kind 2, epoch 1, then the bus key.

0200016b1f9e04c2d85a3377a0e1c94f2b6d8135ce0a7f92b4e6d1083fa5c71e
9d2b40

A.2 A Proven Ping

7M3K9 pings 4T9X2 (Level 1 Section 9.5) under its first counter. The frame as Level 1 composes it is ☻↕!→P►↕@♦U→4T9X2►♥, 18 bytes. M is the domain string, epoch 1, the handle, counter 1 and those 18 bytes:

616e7468656f732d646566656e63652d3100011a2b3c4d000000010212211a50
10124004551a34543958321003

The frame as sent:

Pseudo:  [SOM] [SOW]![SOB]P[EOW] [SOW]@[SOR]U[SOB]4T9X2[EOW] [SOW]*[SOR]D[SOU]B[SOB]26[EOW] [EOM] <26 bytes>
Wire:    ☻↕!→P►↕@♦U→4T9X2►↕*♦D•B→26►♥
Tail:    00011a2b3c4d00000001dc6756c6faf760da20db9ca9d5c5bdf1

A receiver that holds epoch 1's key and has no mark yet for the handle removes the proof word and the 26 bytes, computes the tag over the same M, finds dc6756c6faf760da20db9ca9d5c5bdf1, moves the mark to 1, and gives Level 1 the 18-byte Ping. The same frame read again is a replay (Section 7.4, step 3).

A.3 A Proven Attack Exception

7M3K9 refuses unproven frames that name 9QZ4H, and tells the bus under its second counter. The frame as Level 1 composes it is ☻↕!→X►↕@♦U→7M3K9►↕~→UNADMITTED_FRAME►↕~→9QZ4H►♥, 47 bytes. M:

616e7468656f732d646566656e63652d3100011a2b3c4d000000020212211a58
10124004551a374d334b3910127e1a554e41444d49545445445f4652414d4510
127e1a39515a34481003

The frame as sent:

Pseudo:  [SOM] [SOW]![SOB]X[EOW] [SOW]@[SOR]U[SOB]7M3K9[EOW] [SOW]*[SOR]D[SOU]B[SOB]26[EOW] [SOW]~[SOB]UNADMITTED_FRAME[EOW] [SOW]~[SOB]9QZ4H[EOW] [EOM] <26 bytes>
Wire:    ☻↕!→X►↕@♦U→7M3K9►↕*♦D•B→26►↕~→UNADMITTED_FRAME►↕~→9QZ4H►♥
Tail:    00011a2b3c4d000000028550a70145f2891aa3f5ec6d8ee2b261

A.4 A Report

7M3K9's Report to its Tether of the sign it saw, the first since its last: kind 7, what 1 (seen), bus 0, count 1, then the head of A.3 without its proof.

07010000010212211a5810124004551a374d334b3910127e1a554e41444d4954
5445445f4652414d4510127e1a39515a34481003

Appendix B: Revision History

This appendix is non-normative.