mirror of
https://github.com/ruvnet/RuView
synced 2026-08-11 20:41:44 +00:00
Claude
b827dc40b1
Take VEIL from the synthetic Rust reference model toward real WiFi silicon
across multiple hardware providers, around one shared, host-validated core.
Answers the questions "can OpenWRT / open WiFi software implement this?" and
"can ESP32 help scramble signals?" with an honest per-platform feasibility map.
Portable C shield core (firmware/privshield/core/) — VALIDATED (host test):
- veil_shield.{h,c}: keyed Givens-rotation obfuscation of the identity-bearing
"fine" subspace, C99, no malloc / no libc I/O, only <math.h>. SplitMix64 key
schedule byte-identical to the Rust crate, so on-air behavior is consistent
everywhere and every adapter links the same math.
- make test passes: energy conservation (orthogonal => "not jamming"),
reversibility (recover inverts apply), wrong-key-fails, and PRNG stream parity
with the Rust crate. This is build/host evidence, NOT silicon.
Per-provider adapters (all SYNTHETIC / L0, build-only, TODO(hw) markers):
- openwifi/ grade B (ceiling A, effort D): only open PHY/MAC (FPGA) that can
host the full keyed rotation + inverse; needs new HDL + 2nd TX chain. Carries
the P5 measurement protocol (MEASUREMENT.md) for the first MEASURED result.
- openwrt/ grade C: per-packet keyed unitary is blob-blocked on commodity APs;
coarse compliant knobs (TX antenna map, sounding-cadence jitter) reachable
from userspace/hostapd; ath9k is the one credible driver-patch route.
- nexmon/ grade C: reading the compressed-BF angles is solved (nexmon_csi /
Wi-BFI); shaping the transmitted report is research-grade (D11 ucode-adjacent).
- esp32/ grade F (self) / B (supporting): cannot shape its own BF feedback
(closed esp-phy-lib blob); legitimate as a sensing detector and external-RIS
controller — the honest way ESP32 "helps scramble", via an external surface.
Docs:
- firmware/privshield/README.md: architecture, layout, and the feasibility matrix.
- ADR-290: the E2E hardware program, PROOF discipline, and per-provider decision;
added to docs/adr/README.md index.
Compliant waveform controls only, never jamming. No adapter has run on silicon;
no MEASURED claim is made (that is roadmap P5, gated on a captured log).
Co-Authored-By: claude-flow <ruv@ruv.net>
Claude-Session: https://claude.ai/code/session_01WEXNqzs7UsfNFBcP5yW21p
24 lines
1.1 KiB
CMake
24 lines
1.1 KiB
CMake
# veil_ris_controller — ESP-IDF component (SYNTHETIC / L0, build-only)
|
|
#
|
|
# Drives an EXTERNAL reconfigurable intelligent surface (RIS) over GPIO/SPI to
|
|
# scramble the *sensing-direction* channel while preserving the *comm-direction*
|
|
# channel (the PrivISAC pattern, arXiv:2601.04488). This is the honest way an
|
|
# ESP32 "helps scramble": through an external passive surface, NOT its own
|
|
# closed Wi-Fi PHY. See the subdir README.md.
|
|
#
|
|
# The keyed configuration schedule reuses the portable VEIL core's SplitMix64
|
|
# `veil_rng` (../../core/veil_shield.{h,c}) so the schedule is deterministic and
|
|
# byte-consistent with the Rust reference — the same key can be shared with an
|
|
# associated receiver.
|
|
#
|
|
# NOTE: build-only skeleton, never run on silicon. Hardware paths -> TODO(hw).
|
|
|
|
set(VEIL_CORE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../../core")
|
|
|
|
idf_component_register(
|
|
SRCS "veil_ris_controller.c"
|
|
"${VEIL_CORE_DIR}/veil_shield.c" # reuse veil_rng from the portable core
|
|
INCLUDE_DIRS "include" "${VEIL_CORE_DIR}"
|
|
REQUIRES esp_timer esp_driver_gpio esp_driver_spi
|
|
)
|