Principe de fonctionnement

Yggstore propose un système de stockage distribué où chaque fichier est d’abord découpé en blocs de 4 MiB. Chaque bloc est chiffré avec AES‑256‑GCM en utilisant une clé aléatoire unique par fichier et un nonce différent par bloc. Ensuite, le bloc chiffré subit un codage d’effacement : 4 données + 2 parités sont générées, ce qui crée six fragments (shards) dont la perte de deux n’empêche pas la reconstruction.

Les fragments sont adressés par leur empreinte SHA‑256 et répartis parmi les nœuds actifs du réseau Yggdrasil. Lorsque le groupe compte au moins six nœuds, chaque nœud ne reçoit qu’un seul fragment d’un même bloc, limitant ainsi la corrélation entre les données stockées localement.

Gestion des identités et des accès

Yggdrasil attribue à chaque nœud une adresse IPv6 du préfixe 200::/7, dérivée de la clé publique du nœud. Cette adresse sert d’identifiant unique et authentifie chaque connexion sans besoin de serveur central. Le fichier peers.json liste les adresses autorisées ; toute connexion provenant d’une adresse non listée est rejetée (politique « default deny »). De plus, chaque serveur n’accepte que les requêtes provenant d’adresses présentes dans ce fichier et ne répond qu’à son adresse overlay, ce qui élimine l’exposition du réseau local.

Le propriétaire d’un fichier conserve un stub (FILE.ystub) contenant le manifeste, la clé de chiffrement et les métadonnées de vérification. Posséder le stub et l’accès aux nœuds du groupe suffit pour récupérer le fichier complet.

Vérification de la disponibilité des fragments

Lors de l’upload, le client pré‑calcule 20 défis à usage unique par fragment et les stocke dans FILE.ystub.challenges.json. Le processus verify envoie à chaque nœud un défi du type « hash ce segment d’octets avec ce nonce », puis compare la réponse avec la valeur attendue. Cette méthode garantit que les nœuds conservent réellement les fragments et permet de détecter rapidement les pertes ou les altérations.

Le téléchargement (get) récupère les fragments en parallèle, rejette ceux dont le hash ne correspond pas, puis reconstruit chaque bloc à partir de n’importe quel sous‑ensemble de 4 fragments sur 6. Ainsi, la disponibilité du fichier ne dépend pas d’un nœud particulier.

Déploiement et limites

Yggstore se compile avec Go 1.24 ou version ultérieure : 

go build -o bin/yggstore ./cmd/yggstore
Le binaire fonctionne sans daemon, TUN ou privilèges root, et peut être exécuté directement. Des versions pré‑compilées existent pour Linux, Windows, macOS et les architectures ARM64, notamment les Raspberry Pi.

Le projet est déclaré expérimental ; la cryptographie n’a pas été auditée par une tierce partie et les auteurs recommandent de ne pas l’utiliser comme unique sauvegarde. De plus, la robustesse dépend du nombre de nœuds actifs : avec moins de six participants, la redondance diminue et la reconstruction peut échouer. Enfin, la sécurité repose sur la confidentialité du stub ; toute fuite expose la clé de chiffrement et rend le fichier accessible à quiconque possède les fragments.