JHILKE झिल्के

Steganographic key lifecycle management for the Yakmesh mesh.

Overview

JHILKE provides two critical functions that together eliminate all plaintext cryptographic exchange on the Yakmesh network:

The Problem JHILKE Solves

Traditional key exchange protocols expose critical metadata to passive observers:

Deterministic Bootstrap

When two nodes connect, they both independently compute the same initial symmetric key:

// Both nodes independently derive the same bootstrap key
// Key = HKDF(SHA3-256, codeHash, sortedNodeIds, bootstrapInfo, 32)

import { JhilkeCoordinator } from './mesh/jhilke.js';

const jhilke = new JhilkeCoordinator({
  codeHash: oracle.selfHash,   // Validation Oracle code hash
  nodeId: myNodeId,
  annex: annexInstance,
  mesh: meshInstance,
});

// Derive bootstrap key for a peer (deterministic — both nodes get same key)
const bootstrapKey = jhilke.deriveBootstrapKey(peerNodeId);

// Create ANNEX session using bootstrap key (no KEM exchange needed!)
annex.bootstrapSession(peerNodeId, bootstrapKey);

// Traffic is now encrypted from the very first message.
// KEM upgrade happens automatically through the encrypted channel.

Key Derivation

// Salt includes both node IDs (sorted for order-independence)
const [first, second] = [nodeA, nodeB].sort();
const salt = `YAKMESH-JHILKE-BOOTSTRAP-2026:${first}:${second}`;

// HKDF derivation
const key = HKDF(
  SHA3-256,                              // Hash function
  codeHash,                              // Input key material (oracle hash)
  salt,                                  // Salt (sorted node IDs)
  'yakmesh-jhilke-bootstrap-key-v1',     // Info string (versioned)
  32                                     // Output: 256-bit key
);

Encryption Lifecycle

JHILKE manages the complete ANNEX encryption lifecycle:

Steganographic Signals

JHILKE signals are hidden inside mesh_entropy messages — a normal part of mesh communication used for entropy exchange between peers:

// What an observer sees on the wire:
{
  type: 'mesh_entropy',
  entropy: 'a7f3b2c1...',   // 32 bytes of genuine entropy
  jhilke: '8e4d1f2a...',    // 8 bytes — cricket signal or random noise?
  pad: 'c3d2e1f0...',       // 16-64 bytes random padding (varying size)
  t: 1740100000000           // Timestamp
}

// To an observer: just entropy exchange, nothing unusual.
// To nodes sharing the dialect: a coordinated key rotation.

Dialect Derivation

The "dialect" is the shared secret that allows signal encoding/decoding. It's derived from the code hash — only nodes running identical code share the dialect:

// Dialect seed — same for all nodes with identical codebase
const dialectSeed = HKDF(
  SHA3-256,
  codeHash,                             // Input key material
  'jhilke-cricket-salt-2026',           // Salt
  'yakmesh-jhilke-dialect-v1',          // Info
  32                                    // 256-bit seed
);

// Signal generation — encodes intent + context
const signal = HKDF(
  SHA3-256,
  dialectSeed,                          // Key = dialect
  `${nodeA}:${nodeB}:${tick}:${fibPos}:${fibRoot}:${intent}`,
  'jhilke-signal-v1',
  8                                     // 8-byte signal
);

Signal Decoding

Decoding is brute-force over a tiny search space — trivial for nodes sharing the dialect, impossible without it:

// 3 intents × 3 tick offsets (±1 tolerance) = 9 attempts
const intents = [PREPARE, READY, SWITCH];  // +1, 0, -1
const offsets = [-1, 0, +1];               // tick tolerance

for (const offset of offsets) {
  for (const intent of intents) {
    const expected = generateSignal(peerId, tick + offset, intent);
    if (expected === receivedSignal) {
      // Decoded! We know the intent and approximate timing.
      return { intent, tick: tick + offset };
    }
  }
}
// No match → genuine entropy, not a cricket signal

Ternary State Machine

The rekey coordination uses a ternary state machine with TRIBHUJ trits:

  Initiator                         Responder
  ─────────                         ─────────
  idle                              idle
    │                                 │
    ├── needsRekey() ─────────────────┤
    │                                 │
  prepare ──── PREPARE (+1) ────▶   prepare
    │                                 │
    │     (3 ticks generating keys)   │
    │                                 │
  ready   ──── READY (0) ──────▶   ready
    │     ◀──── READY (0) ──────     │
    │                                 │
    │     (both confirmed ready)      │
    │                                 │
  switch  ──── SWITCH (-1) ────▶   switch
    │     ◀──── SWITCH (-1) ────     │
    │                                 │
  exchanging ── KEM rekey ──────▶  exchanging
    │     ◀── KEM response ─────     │
    │                                 │
  idle    (new KEM key active)     idle
        

Timing & Retry

API Reference

Buffer  // 32-byte (256-bit) symmetric key

{
  bootstrapKeysDerived: 3,      // Bootstrap keys computed
  signalsSent: 142,             // Cricket chirps sent
  signalsReceived: 138,         // Chirps received
  signalsDecoded: 47,           // Successfully decoded (rest were genuine entropy)
  rekeyCoordinations: 12,       // Rekey coordinations started
  rekeySuccesses: 11,           // Successful key rotations
  rekeyAborts: 1,               // Timed-out coordinations
  activeSessions: 2,            // Peers tracked
  activeCoordinations: 1,       // Rekeys in progress
  globalTick: 3847              // Ticks since start
}

Security Properties

Relationship to ANNEX

JHILKE is ANNEX's companion protocol — it manages the cryptographic lifecycle while ANNEX handles the actual encryption/decryption: