reco0 through reco4, one protocol underneath
TAWK is a single configurable protocol. Reference configurations are canonical, documented builds for different deployments, not a quality ladder. A higher number is not “more secure”, it is more independently validated and physically hardened hardware around the same cryptographic core.
| Config | Who it's for | Coordinator | Trust class | Validation |
|---|---|---|---|---|
Reference Config 0 reco0 | Families, kids, individuals | No dedicated hardware required | TAWK-S | Same post-quantum core |
Reference Config 1 reco1 | Schools first, then campuses, venues, companies | Dedicated coordinator (appliance, on-prem, or existing HSM) | TAWK-S | Same post-quantum core |
Reference Config 2 reco2 | Responders and teams that need validated ground truth | Validated hardware root of trust required | TAWK-HA | FIPS 140-3 Level 2 class |
Reference Config 3 reco3 | Government and critical infrastructure | Hardened, validated coordinator | TAWK-HA | FIPS 140-3 Level 3 class |
Reference Config 4 reco4 | Environments where tamper-active protection is non-negotiable | Tamper-active, validated coordinator | TAWK-HA | FIPS 140-3 Level 4 class |
- Coordinator
- No dedicated hardware required
- Validation
- Same post-quantum core
- Coordinator
- Dedicated coordinator (appliance, on-prem, or existing HSM)
- Validation
- Same post-quantum core
- Coordinator
- Validated hardware root of trust required
- Validation
- FIPS 140-3 Level 2 class
- Coordinator
- Hardened, validated coordinator
- Validation
- FIPS 140-3 Level 3 class
- Coordinator
- Tamper-active, validated coordinator
- Validation
- FIPS 140-3 Level 4 class
Where the meaningful lines actually are
Only two transitions matter, and only one of them changes the trust model.
reco0 → reco1 is a scale boundary
Moving from a family to an institution is about scale, not a different protocol. reco0 needs no dedicated hardware. reco1 adds a dedicated coordinator managed by IT or staff to handle hundreds of devices. Both run the same trust class, TAWK-S.
reco1 → reco2 is the assurance boundary
This is the meaningful line. At reco2 and above, an independently validated hardware root of trust becomes required and the trust class shifts to TAWK-HA. The protocol is unchanged; what changes is how rigorously the hardware is validated and physically protected.
TAWK-S and TAWK-HA
The trust class, not the configuration number, is the externally meaningful boundary. It is what the protocol actually acts on.
The standard trust class, covering reco0 and reco1. The same post-quantum core, without a module-level hardware validation claim. This is the consumer and institutional range.
The high-assurance trust class, covering reco2 through reco4, where an independently validated hardware root of trust is required and trust in the hardware itself is raised.
What rises with the number
From reco2 upward, hardware validation ramps along a recognized public standard for cryptographic modules (FIPS 140-3). In plain terms:
- Level 2 · reco2Adds physical tamper-evidence and role-based controls.
- Level 3 · reco3Adds physical tamper-resistance and stronger identity protections.
- Level 4 · reco4Most stringent: hardware that actively responds to physical attack.
FIPS levels are summarized for context and are not certification claims. Validated claims require an accredited testing lab.
Open where it should be, licensed where it must be
The protocol and its conformance are documented openly. The consumer and institutional reference builds are meant to be open, so enthusiasts and integrators can build their own compatible devices. The high-assurance reference designs are distributed under license, with room for academic and research terms.
“Every TAWK reference configuration runs the same post-quantum cryptographic core. The baseline is not “less secure”, it runs the same protection as the rest. What rises with the configuration is the independent hardware validation and physical tamper protection of the coordinator, not the strength of the cryptography. You pick the configuration that matches your deployment, your hardware, and your validation requirements, same protocol underneath.”