neitzert/picardAdaptateur de chunks introspectant les protocoles pour des données résilientes
Adaptateur de chunks introspectant les protocoles pour des données résilientes
Pour les autodidactes, les non-conformistes, et tous ceux à qui on a un jour dit de rester à leur place. Continuez à construire, continuez à explorer.
PICARD chiffre vos données, les découpe en chunks et disperse ces chunks à travers tous les points de terminaison de protocole que vous configurez : enregistrements DNS TXT, API de réseaux sociaux, courtiers MQTT, buckets S3, annonces Bluetooth, ou tout cela à la fois. Récupérez-les et il les réassemble. Avec la dispersion multi-adaptateurs, aucun point de terminaison unique ne détient suffisamment de texte chiffré pour reconstruire quoi que ce soit. Aucun serveur central. Aucuns frais de stockage mensuels. Il se monte comme un système de fichiers classique.
Pas efficace. Agnostique au protocole.
[!IMPORTANT] Projet de recherche. PICARD est une expérience informatique fonctionnelle, pas un système de stockage de production. Lisez l'avis de recherche et de nature juridique avant de poursuivre.
[!WARNING] Expérimental : à utiliser à vos risques et périls. Ces adaptateurs utilisent des vulnérabilités matérielles comme primitives de stockage. Les résultats dépendent du matériel, sont non déterministes d'une machine à l'autre et irréversibles en cas de basculements de bits en DRAM. À n'utiliser que sur du matériel que vous possédez et contrôlez. L'exécution contre une infrastructure partagée ou cloud constitue un accès non autorisé dans la plupart des juridictions.
PICARD peut désormais stocker des chunks dans les états de bits de la DRAM et la résidence en cache CPU -- entièrement hors de la vue du système d'exploitation.
| Adaptateur | Ce qu'il fait |
|---|---|
rowhammer | Écrit des bits en martelant les rangées DRAM adjacentes jusqu'à ce que les fuites de charge fassent basculer les bits cibles. Lit en examinant directement la rangée victime. Local, éphémère, DDR3/4 non-ECC. |
halfdouble | Variante à deux sauts. Le ratio agresseur proche/lointain contourne le Target Row Refresh (TRR) de la DDR4. Atteint du matériel que le rowhammer classique n'affecte plus. |
throwhammer | Martèle la DRAM d'un hôte distant via RDMA. Le CPU distant n'est pas du tout impliqué -- la carte réseau effectue des lectures DMA directement vers la DRAM. Nécessite une infrastructure RDMA. |
cpu-cache | Stocke des bits dans la SRAM L3 du CPU via Flush+Reload. Encodage par vote majoritaire N_REPS=5 sur des emplacements isolés par page. BER inférieur à 5e-4 sur i7-12700KF. Inter-processus sur le même hôte ; inter-VM là où la déduplication de pages est active. |
Les quatre sont éphémères (un cycle d'alimentation les efface). Voir docs/adapters.md pour les prérequis matériels et le modèle de menace.
plaintext
→ AES-256-GCM encrypt (Argon2id key, per-block salt + nonce)
→ PCHK chunk (protocol-sized pieces)
→ scatter across adapters (DNS, Redis, Reddit, S3, MQTT, …)
→ sealed envelope (HKDF sub-key, correlation tag per adapter)
retrieve
← fan out to all adapters
← collect, verify, assemble
← decrypt
Chaque bloc est chiffré indépendamment avec son propre sel et nonce aléatoires. Les fragments sont répartis en round-robin ou via des profils RAID. Aucun adaptateur ne voit le texte en clair ; aucun adaptateur ne voit suffisamment de texte chiffré pour reconstruire quoi que ce soit.
L'index local (une base de données SQLite chiffrée en AES-256-GCM) associe les chemins aux emplacements des fragments. Perdez la phrase secrète, perdez les données.
C'était un matin frais à Berlin. Depuis mon patio, je fixais un mur en stuc nu surmonté de briques rouges. Un flou d'ailes attira mon regard, un petit oiseau bifurquant vers un trou de drainage près de la ligne de toit et disparaissant. Une autre tête apparut d'un autre trou, piaillant. Cinq trous de drainage, cinq nids. Les gouttières étaient censées évacuer l'eau, pas héberger des familles, et pourtant les oiseaux y avaient trouvé un abri, une couverture et un accès facile. Je ne l'avais jamais remarqué parce que je ne m'étais jamais donné la peine de regarder.
Notre infrastructure numérique transporte plus que ce pour quoi elle a été conçue pour stocker. Les enregistrements TXT du DNS acceptent du texte arbitraire dans les limites de la spécification. Les messages retenus MQTT persistent des données sur le broker. Les paquets ICMP echo transportent un champ de charge utile. Les API de réseaux sociaux acceptent du texte structuré libre. Chacun de ces protocoles définit des champs destinés aux métadonnées, à la découverte ou aux diagnostics. Ces champs peuvent tout aussi bien transporter des octets que remplir les cas d'usage prévus par leurs concepteurs.
picard web ouvre un tableau de bord dans le navigateur à l'adresse http://localhost:8471.
Surface de stockage par catégorie, état des adaptateurs et détails de chiffrement en un coup d'œil.
259 adaptateurs parcourables par catégorie, avec les paramètres requis et l'ajout en un clic.
pip install picard-store
export PICARD_PASSPHRASE="your-passphrase" # or picard will prompt
picard init # create picard.toml
# edit picard.toml to add your adapters, then:
picard put myfile.txt --as /docs/myfile.txt
picard get /docs/myfile.txt -o recovered.txt
picard ls
picard tree /
Depuis la source :
git clone https://github.com/neitzert/picard
cd picard
pip install -e ".[dev]"
python -m pytest --tb=short -q
# picard.toml
[general]
block_size = 65536
[[adapters]]
name = "dns-primary"
type = "dns"
enabled = true
params = { nameserver = "10.10.10.10", domain = "chunks.example.com" }
[[adapters]]
name = "s3-backup"
type = "s3"
enabled = true
tor_proxy = true # route through Tor SOCKS5
params = { bucket = "picard-chunks", prefix = "data/" }
[[adapters]]
name = "reddit-stash"
type = "reddit"
enabled = true
browser_mode = "headed" # api | headless | headed
params = { subreddit = "u_myuser" }
[[raid]]
level = "raid5"
adapters = ["dns-primary", "s3-backup", "filesystem"]
[scatter.paranoid]
raid_level = "raid10"
min_adapters = 4
Profils de dispersion : quiet, resilient, speed, paranoid