Network Working Group L. Reilly, Jr. Internet-Draft Independent Intended status: Experimental 22 July 2026 Expires: 23 January 2027 Hypercube Data Rotation Protocol (HDRP) for Distributed Integrity and Moving Target Defense draft-reilly-hdrp-00 Abstract This document specifies the Hypercube Data Rotation Protocol (HDRP), an experimental protocol for distributing erasure-coded data shards across nodes arranged in an n-dimensional binary hypercube topology and periodically permuting shard placement through structured rotation operations. Rotations are automorphisms of the hypercube graph, applied on a fixed epoch schedule and committed to a verifiable epoch ledger. The design applies the established principles of hypercube interconnection networks, maximum distance separable (MDS) erasure coding, and moving target defense (MTD) to provide three properties in combination: storage-efficient fault tolerance, continuous cryptographic verifiability, and reduction of the value of static reconnaissance by an adversary. HDRP is designed to integrate with autonomous self-healing pipelines and with dual-layer permanence anchoring (blockchain timestamping and DOI archival) as defined in related documents by the same author. Informally, the rotation mechanism may be visualized as the face turns of a combination puzzle applied to a data topology; this document defines that intuition as a precise algebraic operation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. Motivation 1.2. Design Goals 1.3. Relationship to Other Documents 2. Conventions and Terminology 3. Architectural Overview 4. Hypercube Topology Model 4.1. Vertex Addressing 4.2. Adjacency and Routing 4.3. Logical Versus Physical Nodes 5. Shard Encoding and Placement 5.1. Erasure Coding Profile 5.2. Initial Placement Function 6. Rotation Operations 6.1. Rotation as Hypercube Automorphism 6.2. The Rotation Key 6.3. Rotation Execution Procedure 6.4. Partial (Face) Rotations 7. Epochs and the Rotation Ledger 7.1. Epoch Structure 7.2. Epoch Commitment 7.3. Verification and Audit 8. Self-Healing Integration 8.1. Failure Detection 8.2. Shard Reconstruction 8.3. Agent Pipeline Interface 9. Permanence Anchoring 10. Security Considerations 10.1. Moving Target Defense Rationale 10.2. Threat Model 10.3. Limitations 11. Operational Considerations 12. IANA Considerations 13. References 13.1. Normative References 13.2. Informative References Appendix A. Worked Example (Dimension 3) Appendix B. Relationship to Combination Puzzle Intuition Author's Address 1. Introduction 1.1. Motivation Distributed storage systems conventionally optimize for durability (via replication or erasure coding) and availability (via placement diversity). A third property has received growing attention in the security community: unpredictability of placement over time. A static shard map allows an adversary who compromises the map, or who passively observes traffic, to know indefinitely which nodes hold which fragments of a target object. Moving target defense (MTD) research [MTD11] [NIST-MTD] establishes that periodically and verifiably changing system configuration raises attacker cost and shrinks the window in which reconnaissance remains valid. Separately, the n-dimensional binary hypercube is among the most thoroughly studied interconnection topologies in parallel and distributed computing [SaadSchultz88] [Leighton92]. Its properties -- logarithmic diameter, n vertex-disjoint paths between any two vertices, uniform vertex degree, and a rich automorphism group -- make it unusually well suited to structured, verifiable reconfiguration: the topology can be "turned" without being torn. HDRP combines these two bodies of work. Data objects are erasure coded and their shards placed on hypercube vertices; on a fixed schedule, placement is permuted by an automorphism of the cube selected from fresh, committed randomness. Every permutation is deterministic given the rotation key, so honest participants can always locate shards, while observers without the key face a placement that changes every epoch. 1.2. Design Goals G1. Durability: tolerate the loss of any m of n shards per object without data loss, where m is set by the erasure coding profile. G2. Verifiability: every rotation epoch is committed to a hash- linked ledger whose roots can be externally anchored; any party can audit that rotations occurred as scheduled and that shard inventories are intact. G3. Placement unpredictability: an observer who learns the shard map at epoch e gains no advantage in predicting the map at epoch e+1 without the rotation key. G4. Locality of repair: reconstruction of a lost shard requires contacting only a bounded set of hypercube neighbors. G5. Compatibility: integrate cleanly with autonomous self-healing agent pipelines and dual-layer permanence anchoring. 1.3. Relationship to Other Documents HDRP is designed to operate as a storage and integrity substrate beneath the self-healing web architecture described in [I-D.reilly-looking-glass], and to anchor its epoch commitments using the Dual-Layer Digital Permanence methodology established in [I-D.reilly-rem-protocol]. HDRP does not require either document; the integration points are specified in Sections 8 and 9 and are OPTIONAL. 2. Conventions and Terminology 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Dimension (n): The dimension of the hypercube. The cube has 2^n vertices. This document uses "cube" for any dimension n >= 1; n = 4 is a tesseract, n = 5 a penteract. Vertex address (v): An n-bit binary string uniquely identifying a hypercube vertex. Shard: One erasure-coded fragment of a data object. Placement map (P_e): The function from shard identifiers to vertex addresses in effect during epoch e. Rotation key (r_e): An n-bit value determining the global rotation applied at the boundary of epoch e (Section 6.2). Face: The set of 2^(n-1) vertices whose address has a fixed bit value b in a fixed position i; written F(i, b). Epoch (e): A fixed-duration interval during which the placement map is constant. Rotation ledger: The hash-linked sequence of epoch commitment records (Section 7). 3. Architectural Overview An HDRP deployment consists of: o A set of storage nodes, each assigned one or more vertex addresses of an n-dimensional hypercube (Section 4.3). o An encoder that splits each data object into k data shards and generates (n_s - k) parity shards using an MDS erasure code (Section 5.1), where n_s is the total shard count per object. o A rotation coordinator (which MAY be a distributed or agent- based process) that derives the rotation key each epoch, instructs shard transfers, and writes the epoch commitment record. o A rotation ledger providing an append-only, hash-linked history of epoch commitments, OPTIONALLY anchored externally (Section 9). o A repair service that detects missing or corrupt shards and reconstructs them from surviving shards (Section 8). The lifecycle of an object is: encode -> place (epoch e0) -> rotate at each epoch boundary -> verify continuously -> repair on failure -> retrieve on demand by inverting the composition of rotations. 4. Hypercube Topology Model 4.1. Vertex Addressing Each vertex is addressed by an n-bit string v = b_{n-1} ... b_1 b_0. Two vertices are adjacent if and only if their addresses differ in exactly one bit position (Hamming distance 1). Consequently: o Every vertex has exactly n neighbors. o The diameter of the topology is n; any shard is reachable from any vertex in at most n hops. o There exist n vertex-disjoint paths between any two vertices [SaadSchultz88], providing inherent routing redundancy. Implementations SHOULD enumerate traversal orders using the binary reflected Gray code [Gray53], which visits all 2^n vertices while changing a single bit per step; this yields transfer schedules in which each step moves data only between adjacent vertices. 4.2. Adjacency and Routing Routing from vertex u to vertex v proceeds by correcting the bits of u XOR v one at a time (dimension-order routing). Each corrected bit is one hop. Implementations MAY use any bit-correction order; randomized order is RECOMMENDED to spread load. 4.3. Logical Versus Physical Nodes The hypercube is a logical overlay. A physical node MAY host multiple vertex addresses (e.g., a 16-vertex tesseract overlay on 4 physical machines hosting 4 vertices each). Operators SHOULD map vertices to physical nodes such that no single physical failure domain contains more than (n_s - k) shards of any object; this preserves goal G1 under correlated failure. 5. Shard Encoding and Placement 5.1. Erasure Coding Profile HDRP uses a systematic MDS code. The REQUIRED baseline profile is Reed-Solomon over GF(2^8) [ReedSolomon60] [RFC5510] with parameters (n_s, k) satisfying n_s <= 2^n. The RECOMMENDED default for a tesseract deployment (n = 4, 16 vertices) is (n_s, k) = (16, 10): any 10 of 16 shards reconstruct the object, tolerating the loss of any 6 vertices with a storage overhead factor of 1.6. Each shard s_i carries a shard header: +----------------+---------------------------------------------+ | Field | Meaning | +----------------+---------------------------------------------+ | object_id | SHA-256 of the plaintext object [RFC6234] | | shard_index | i in [0, n_s) | | epoch_created | epoch number at encoding time | | shard_digest | SHA-256 of the shard payload | | coding_params | (n_s, k, field, generator) | +----------------+---------------------------------------------+ 5.2. Initial Placement Function At the object's creation epoch e0, shard i is placed at vertex: P_{e0}(i) = ENC(i) XOR H_n(object_id) where ENC(i) is the n-bit binary reflected Gray code of i, and H_n(x) denotes the first n bits of SHA-256(x). The Gray-code term distributes consecutive shard indices to adjacent vertices; the object-dependent XOR term decorrelates placement across objects so that no vertex systematically holds low-index (data) shards for all objects. 6. Rotation Operations 6.1. Rotation as Hypercube Automorphism The automorphism group of the n-cube is the hyperoctahedral group of order 2^n * n!, generated by (a) translations, i.e., XOR of all vertex addresses with a fixed mask, and (b) permutations of bit positions [Harary00]. HDRP rotations are drawn from this group, which guarantees the defining invariant of the protocol: A rotation relabels vertices but preserves all adjacency. Neighbors remain neighbors. The cube turns; it does not tear. This invariant is what makes epoch transitions cheap: because adjacency is preserved, a translation rotation moves every shard along a path of exactly HammingWeight(r_e) hops, and repair relationships (Section 8) survive rotation unchanged. 6.2. The Rotation Key At each epoch boundary e -> e+1, the coordinator derives: r_{e+1} = H_n( K_master || e+1 || L_e ) where K_master is a deployment secret, e+1 is the epoch number encoded as a 64-bit unsigned integer, and L_e is the ledger head digest after epoch e (Section 7.2). Including L_e makes each rotation key depend on the committed history, preventing precomputation of future placements even by a party who learns K_master late. The new placement map is: P_{e+1}(i) = P_e(i) XOR r_{e+1} Because XOR translations compose, retrieval at any epoch requires only the object's creation placement and the cumulative mask R_{e} = r_{e0+1} XOR ... XOR r_{e}, computable in O(1) from a running value. Implementations MUST maintain the cumulative mask per deployment, not per object. 6.3. Rotation Execution Procedure At the epoch boundary the coordinator MUST: 1. Derive r_{e+1} and verify it is nonzero; if zero, set r_{e+1} = 0...01 (rotation along dimension 0). 2. Issue transfer instructions: each vertex v sends its held shards to v XOR r_{e+1}. Transfers traverse one dimension at a time following any fixed order of the set bits of r_{e+1}; each step is a single-hop transfer between adjacent vertices. 3. Require per-shard receipts: the receiving vertex MUST verify shard_digest before acknowledging. A failed verification triggers immediate repair (Section 8) rather than epoch abort. 4. Write and sign the epoch commitment record (Section 7.2). Rotation is atomic per epoch: until step 4 completes, readers MUST be served under P_e. Implementations SHOULD use a two-phase (prepare/commit) sequence so that a coordinator crash mid-rotation is recoverable by replaying receipts. 6.4. Partial (Face) Rotations A deployment MAY additionally schedule face rotations, which apply a bit-position permutation to only the 2^(n-1) vertices of a face F(i, b), holding the opposite face fixed. This is the direct analogue of turning one face of a combination puzzle while the rest of the cube holds still. Face rotations are drawn from the stabilizer subgroup of F(i, b) and MUST be recorded in the epoch commitment record with their face selector and permutation. Face rotations increase placement entropy at the cost of a more complex cumulative map (a composition of affine transformations rather than a single XOR mask); deployments prioritizing retrieval simplicity SHOULD use global translations only. 7. Epochs and the Rotation Ledger 7.1. Epoch Structure Epoch duration is a deployment parameter. The RECOMMENDED default is 24 hours; the epoch length MUST be at least twice the worst-case rotation execution time observed over the trailing 30 epochs. Epoch numbers are unsigned 64-bit integers starting at 0. 7.2. Epoch Commitment At the completion of each rotation, the coordinator MUST append to the rotation ledger an epoch commitment record: EpochRecord { epoch : uint64 prev_digest : SHA-256 of the previous EpochRecord rotation_comm : SHA-256( r_e ) // key commitment inventory_root : Merkle root over sorted (vertex, shard_digest) pairs [RFC6962-style tree, SHA-256] timestamp : RFC 3339 UTC time signature : coordinator signature over all above fields } The ledger head digest L_e is the SHA-256 of the latest record. Note that the record commits to the rotation key without revealing it (rotation_comm); the key itself is disclosed only to authorized participants. The inventory_root allows any vertex to prove possession of its assigned shards by Merkle inclusion proof, and allows an auditor to detect any divergence between the committed and actual shard inventory. 7.3. Verification and Audit An auditor with read access to the ledger can verify, for any epoch range, that (a) the chain of prev_digest values is unbroken, (b) each epoch's inventory_root is consistent with challenge-response spot checks against live vertices, and (c) rotation cadence matched the schedule. Auditors SHOULD issue randomized possession challenges: request the shard at (vertex, shard_index), verify its digest against the inventory Merkle proof. A vertex that fails a challenge MUST be treated as failed for the purposes of Section 8. 8. Self-Healing Integration 8.1. Failure Detection Each vertex maintains heartbeat exchange with its n hypercube neighbors. Because rotations preserve adjacency (Section 6.1), neighbor relationships are stable across epochs, and heartbeat state survives rotation without renegotiation. A vertex is suspected failed after missing h consecutive heartbeats (default h = 3) and confirmed failed when a majority of its neighbors concur. 8.2. Shard Reconstruction Upon confirmed failure of vertex v, the repair service: 1. Enumerates the shards assigned to v under the current P_e (from the inventory committed at epoch e). 2. For each lost shard, retrieves any k surviving shards of the same object. By construction the n vertex-disjoint paths of the hypercube ensure retrieval routes exist despite the failure. 3. Re-derives the lost shard via RS decoding, verifies its digest against the object's shard header set, and installs it at a standby vertex address or at v upon recovery. 4. Records the repair in the next EpochRecord (repaired shards alter the inventory_root). 8.3. Agent Pipeline Interface Deployments running an autonomous agent pipeline (e.g., the fourteen-agent self-healing architecture of [I-D.reilly-looking-glass]) SHOULD map HDRP roles onto agents as follows: monitoring agents consume heartbeat and challenge telemetry; diagnosis agents confirm vertex failure; remediation agents execute Section 8.2; and audit agents perform the ledger verification of Section 7.3. HDRP deliberately exposes each of these functions as a discrete, idempotent operation so that agent retries are safe. 9. Permanence Anchoring The rotation ledger is internally tamper-evident but not, by itself, tamper-proof against an adversary who controls the coordinator and can rewrite history. Deployments requiring external immutability SHOULD anchor the ledger using the Dual-Layer Digital Permanence methodology [I-D.reilly-rem-protocol]: o Layer 1 (existence proof): submit L_e to a Bitcoin-anchored timestamp aggregator (e.g., OpenTimestamps [OTS]) at least once per anchoring interval (RECOMMENDED: every 24 epochs). o Layer 2 (archival): deposit the ledger segment and its verification metadata with a DOI-issuing archive at least once per archival interval (RECOMMENDED: every 720 epochs). Anchoring converts the ledger's tamper evidence into third-party- verifiable tamper proof for all epochs at or before each anchor. 10. Security Considerations 10.1. Moving Target Defense Rationale The security contribution of rotation is best understood through the MTD literature [MTD11] [NIST-MTD]: defenses that periodically invalidate attacker knowledge impose ongoing reconnaissance cost and shrink the exploitation window. Under HDRP, an adversary who exfiltrates the placement map at epoch e knows shard locations only until the next boundary. Learning placements at epoch e+1 requires either the deployment secret K_master or fresh compromise of the coordinator, because r_{e+1} is derived from K_master and the as-yet-unknown ledger head. Rotation therefore converts a one-time map disclosure from a permanent loss into a bounded one. Rotation also mitigates slow, targeted corruption: an adversary holding persistent access to a small set of physical nodes sees a different shard population each epoch, so sustained targeting of one object's shards requires breadth of compromise proportional to the whole deployment rather than depth on a few nodes. 10.2. Threat Model HDRP defends against: (T1) static reconnaissance and map exfiltration; (T2) loss or destruction of up to (n_s - k) shards per object per repair interval; (T3) silent shard corruption (detected by digests and possession challenges); (T4) after-the- fact ledger rewriting, when anchoring per Section 9 is enabled. 10.3. Limitations HDRP does not by itself provide: confidentiality (objects SHOULD be encrypted before encoding; rotation is not encryption and MUST NOT be treated as such); protection against a fully compromised coordinator during live epochs (mitigate with threshold or agent- distributed coordination); or availability under partition of more than (n_s - k) vertices. Rotation increases steady-state network cost by one shard transfer per shard per epoch; operators MUST provision for this or lengthen epochs. Finally, HDRP's rotation keys are symmetric-key derived; post-quantum considerations reduce to the standard treatment of SHA-256 preimage resistance and deployment secret hygiene, on which HDRP makes no novel claims. 11. Operational Considerations Deployments SHOULD begin with global translations only (no face rotations), n = 4, and (16, 10) coding, and SHOULD monitor: epoch rotation duration, challenge failure rate, repair rate, and cumulative-mask consistency across replicas of the coordinator state. A sustained challenge failure rate above the repair rate indicates the deployment is losing integrity faster than it heals and MUST trigger operator alerting. 12. IANA Considerations This document has no IANA actions. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. [RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, April 2009. 13.2. Informative References [SaadSchultz88] Saad, Y. and M. Schultz, "Topological Properties of Hypercubes", IEEE Transactions on Computers, Vol. 37, No. 7, pp. 867-872, July 1988. [Leighton92] Leighton, F. T., "Introduction to Parallel Algorithms and Architectures: Arrays, Trees, Hypercubes", Morgan Kaufmann, 1992. [Gray53] Gray, F., "Pulse Code Communication", U.S. Patent 2,632,058, March 1953. [ReedSolomon60] Reed, I. S. and G. Solomon, "Polynomial Codes over Certain Finite Fields", Journal of the Society for Industrial and Applied Mathematics, Vol. 8, No. 2, pp. 300-304, June 1960. [Harary00] Harary, F., "The automorphism group of a hypercube", Journal of Universal Computer Science, Vol. 6, No. 1, pp. 136-138, 2000. [MTD11] Jajodia, S., Ghosh, A. K., Swarup, V., Wang, C., and X. S. Wang (Eds.), "Moving Target Defense: Creating Asymmetric Uncertainty for Cyber Threats", Springer Advances in Information Security, Vol. 54, 2011. [NIST-MTD] National Institute of Standards and Technology, "Framework for Improving Critical Infrastructure Cybersecurity" and associated MTD research literature; see also DHS Cyber Security Division, "Moving Target Defense" program documentation. [OTS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized Timestamping with Bitcoin", 2016, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013. [I-D.reilly-looking-glass] Reilly, Jr., L., "Project Looking Glass: An Integrative Framework for Self-Healing Web Architecture", Work in Progress, Internet-Draft, draft-reilly-looking-glass-00, July 2026. [I-D.reilly-rem-protocol] Reilly, Jr., L., "The REM Protocol and Dual-Layer Digital Permanence", Work in Progress, Internet-Draft, draft-reilly-rem-protocol-00, September 2025. Appendix A. Worked Example (Dimension 3) Consider n = 3 (8 vertices, addresses 000-111) and an object encoded (n_s, k) = (8, 5). Suppose H_3(object_id) = 101. Initial placement (Gray code ENC(i) XOR 101): shard i : 0 1 2 3 4 5 6 7 ENC(i) : 000 001 011 010 110 111 101 100 vertex : 101 100 110 111 011 010 000 001 Epoch 1 rotation with r_1 = 011: every shard moves to vertex XOR 011, a 2-hop transfer (two set bits), e.g., shard 0 moves 101 -> 100 -> 110 (or 101 -> 111 -> 110). Adjacency of all vertices is unchanged. Retrieval at epoch 1 computes placement as initial placement XOR cumulative mask R_1 = 011. Loss of any 3 vertices at any epoch destroys at most 3 shards; 5 survivors suffice to reconstruct all 8. Appendix B. Relationship to Combination Puzzle Intuition The project's working name, "Project Rubik's Cube", reflects the governing intuition: a Rubik's Cube permutes its facelets through face turns while its physical structure -- which cubelet touches which -- is constrained by the group of legal moves. HDRP's rotations are likewise elements of a group (the hyperoctahedral group) acting on shard placements while preserving the adjacency structure that repair and routing depend on. The intuition is exact at the level of group actions and approximate everywhere else; in particular, nothing in this protocol involves, requires, or claims physical higher-dimensional space. The tesseract of the default profile is a 4-dimensional *graph*, realized entirely on ordinary networked hosts. Author's Address Lawrence John Reilly, Jr. Independent Florida, United States of America Email: lawrencejohnreilly@gmail.com