peeza — protocole et cryptographie

Read in English

Version 3 du document · 2026-10-05 · version du format peeza-e2e-v1

Traduction de la version anglaise (https://peeza.app/protocol). Les numéros de section et les vecteurs de test sont identiques dans les deux langues ; en cas d'écart entre les deux textes, la version anglaise fait foi, et l'écart est un problème à nous signaler (section 13).

Ce document décrit comment peeza protège un fichier entre l'appareil qui l'envoie et l'appareil qui le reçoit : les clés, le format de chiffrement, la façon dont une clé parvient au destinataire, l'association de deux appareils, et ce que le relais de peeza peut voir ou non. Il s'adresse aux personnes qui veulent examiner l'affirmation « chiffré de bout en bout » plutôt que la croire sur parole.

Ce que ce document est, et ce qu'il n'est pas.

• C'est une spécification du protocole, pour tout ce qui touche à la sécurité, assez précise pour qu'on puisse le réimplémenter. La section 12 donne des vecteurs de test ; chacun a été produit par le moteur tel qu'il est livré, puis reproduit par une implémentation indépendante écrite à partir de ce seul texte.
• Le moteur des applications natives n'est pas à code source ouvert. Vous pouvez lire le code du client web, puisque votre navigateur le reçoit ; vous pouvez capturer le trafic et le comparer à ce document ; vous ne pouvez pas lire le code source du moteur. Nous disons « le protocole et la cryptographie sont publiés », et non « vérifiez le binaire vous-même ».
• Ce n'est pas un audit indépendant, et il ne prétend pas en être un.
• Il ne décrit pas l'ordonnancement des transferts, la stratégie de reprise, ni la façon dont les appareils d'une équipe choisissent auprès de qui récupérer un fichier. Rien de cela ne change ce qu'un tiers peut lire ou falsifier, qui est le sujet ici.

La section 10 énumère les limites et les exceptions. Lisez-la avant de citer la section 1.

1. Ce que nous affirmons

1. Le contenu est chiffré sur l'appareil qui envoie et déchiffré sur l'appareil qui reçoit, en AES-256-GCM, avec une clé générée sur l'appareil qui envoie.
2. Le relais ne reçoit pas cette clé dans les cas normaux : elle voyage dans le fragment de l'URL d'un lien, ou scellée pour la clé publique de l'appareil destinataire, ou elle est dérivée par deux appareils sur un réseau local sans que le relais y prenne part. La section 10.1 décrit le seul cas où une clé passe délibérément par le relais.
3. Le relais ne stocke jamais le contenu d'un fichier. Quand une connexion directe est impossible, il transmet des trames chiffrées, en mémoire, entre deux pairs connectés.
4. Le relais ne peut pas modifier un transfert sans que cela se voie. Il ne peut ni changer le contenu, ni le tronquer, ni changer le nom, la taille ou la forme déclarés, ni annoncer une livraison qui n'a pas eu lieu. Chacune de ces tentatives échoue à l'authentification à l'un des deux bouts.
5. Un transfert direct et un transfert relayé sont aussi confidentiels l'un que l'autre. Les mêmes trames scellées circulent sur les deux chemins.

Ce que nous n'affirmons pas : que les métadonnées sont cachées (section 9), qu'un transfert fait par lien bénéficie de la confidentialité persistante (10.5), ni que le client web est protégé contre le serveur qui le livre (10.2).

2. Parties et chemins

Un transfert emprunte l'un de trois chemins. Le chiffrement du contenu décrit à la section 4 est identique sur les trois et ne dépend pas du transport sous-jacent.

3. Clés et secrets

Ceux-ci ne sont pas des clés et ne déchiffrent rien :

Il n'y a ni séquestre de clés, ni clé de récupération, ni clé détenue par l'exploitant qui ouvrirait un transfert.

4. Chiffrement des transferts

4.1 Primitive

AES-256-GCM (FIPS 197, NIST SP 800-38D) : clé de 256 bits, nonce de 96 bits, étiquette d'authentification de 128 bits. Les applications natives utilisent la bibliothèque standard de Go (crypto/aes, crypto/cipher) ; le client web utilise WebCrypto (AES-GCM). Les deux produisent des octets identiques.

Une clé de transfert s'écrit en 43 caractères de base64url sans remplissage.

4.2 Nonces

Les nonces sont déterministes. Un nonce fait 12 octets :

nonce(domaine, index) = [ domaine : 1 octet ][ 0x00 0x00 0x00 ][ index : uint64 gros-boutiste ]

L'octet de domaine sépare chaque usage d'une même clé, de sorte que deux messages différents ne sont jamais scellés sous le même couple (clé, nonce) :

VERSION correspond aux 12 octets ASCII peeza-e2e-v1. Elle figure dans les données additionnelles de chaque message scellé, de sorte que deux clients en désaccord sur le format échouent à l'authentification au lieu de mal déchiffrer. total est la longueur totale, en octets, du texte clair de la charge utile.

4.3 Contenu

La charge utile est découpée en blocs de 64 512 octets (63 × 1024) ; le dernier bloc est plus court. Le bloc i commence à l'octet i × 64512. Une trame, telle qu'elle circule :

trame = uint64BE(i) ‖ AES-256-GCM( bloc_i, nonce(0x00, i), VERSION ‖ uint64BE(total) )

c'est-à-dire 8 octets d'index, le texte chiffré, et l'étiquette de 16 octets.

Comme total est lié à chaque bloc, si quoi que ce soit entre les deux appareils change la taille déclarée — pour faire passer un fichier raccourci pour complet —, aucun bloc ne s'authentifie. Le destinataire exige aussi que chaque bloc ait exactement la longueur que son index implique, avant de l'écrire.

Comme les nonces sont déterministes, sceller le même bloc de la même charge utile sous la même clé donne toujours la même trame. Deux conséquences :

• Reprendre un transfert n'exige, chez l'expéditeur, aucun autre état que la charge utile : le destinataire demande une position et reçoit les trames qu'il aurait reçues.
• Tout appareil qui détient la charge utile et la clé peut servir ces trames (section 7). Ce n'est sûr que tant que le texte clair n'a pas changé ; la section 7.3 décrit la vérification qui l'assure.

4.4 Le manifeste de la charge utile

Tout ce qu'un destinataire doit tenir pour vrai au sujet d'une charge utile est scellé en un seul message :

manifeste = JSON { "n": nom, "s": taille, "t": date-de-modification-ms?, "p": empaqueté?, "d": dossier?, "f": version-du-format? }scellé    = base64url( AES-256-GCM( manifeste, nonce(0x08, 0), VERSION ) )

p et d indiquent si la charge utile est un conteneur à déballer (un dossier ou plusieurs fichiers voyagent en un seul flux ZIP non compressé), et f quelle version de ce format de conteneur l'a produite. Les champs marqués ? sont omis quand ils sont vides.

Le destinataire tire le nom, la taille et la forme uniquement du manifeste. Le message de signalisation qui le transporte répète aussi certaines de ces valeurs en clair, pour la comptabilité du relais ; le destinataire n'en tient pas compte. Un message sans manifeste est refusé. Il n'y a aucun repli sur des valeurs non authentifiées.

Le nonce est fixe, donc une clé ne scelle qu'un seul manifeste. Le moteur le garantit : le manifeste est scellé une seule fois, quand la charge utile est figée, puis conservé et renvoyé tel quel ; partager de nouveau le même fichier crée une nouvelle clé. Un appareil qui sert de nouveau une charge utile (section 7) transmet le manifeste scellé d'origine et ne scelle jamais le sien.

4.5 L'accusé de réception

Un destinataire qui a reçu chaque octet, authentifié, l'indique à l'expéditeur par un accusé scellé :

accusé = base64url( AES-256-GCM( "peeza-received-v1", nonce(0x09, 0), VERSION ‖ uint64BE(total) ‖ identifiant de salle ) )

L'expéditeur ne marque un transfert comme terminé que sur un accusé qui s'ouvre. Le relais transmet le message « done » mais ne peut pas en produire un, donc il ne peut pas annoncer une livraison qui n'a pas eu lieu. L'identifiant de salle lie l'accusé à une livraison précise quand plusieurs destinataires partagent une clé (section 7). Sur le chemin À proximité, l'identifiant de salle est vide ; la clé y est déjà propre à la connexion.

Les messages de signalisation sont aussi vérifiés selon leur sens : un message destiné à l'expéditeur est ignoré par un destinataire, et inversement. Un « done » envoyé à un destinataire n'a aucun effet.

4.6 Les petits échanges scellés

Trois échanges facultatifs accompagnent le contenu, chacun scellé avec la clé de transfert dans sa propre paire de domaines (tableau de la section 4.2), un domaine par sens, avec un compteur de messages comme index :

message = uint64BE(compteur) ‖ AES-256-GCM( JSON, nonce(domaine, compteur), VERSION )

Ils permettent à un destinataire qui a déjà une version antérieure, le même dossier ou le même fichier d'éviter de le recevoir de nouveau. Ils transportent des empreintes et des structures, jamais de clés. Le relais peut voir qu'un tel échange a eu lieu, pas ce qui s'y est dit.

5. Comment la clé parvient au destinataire

5.1 Un lien

https://g.peeza.app/K7Q9F2MX#k=<clé de transfert>

Le chemin est le jeton du lien. Le fragment (après le #) contient la clé. Un navigateur n'envoie jamais le fragment dans une requête HTTP, et une application native analyse le lien elle-même et ne présente que le jeton : le relais apprend donc le jeton, pas la clé.

Le lien est transmis par le moyen que l'expéditeur choisit : un message, un courriel, un code QR. Le lien est le secret. Quiconque le détient peut recevoir le fichier, une fois. Il fonctionne pour un seul destinataire et expire après 48 heures s'il n'est pas utilisé.

5.2 Adressé à un appareil

Quand vous envoyez à l'un de vos propres appareils, ou à l'appareil d'un membre de votre équipe, il n'y a pas de lien. La clé de transfert est scellée pour la clé publique d'identité de l'appareil destinataire :

enveloppe = crypto_box_seal( clé de transfert, clé publique d'identité du destinataire )

C'est la « boîte scellée » anonyme de NaCl / libsodium : une paire de clés X25519 éphémère par enveloppe, XSalsa20-Poly1305, 48 octets de surcoût. Le relais achemine l'enveloppe et la garde jusqu'à 7 jours si l'appareil est hors ligne. Seul l'appareil qui détient la clé privée peut l'ouvrir.

L'appareil qui envoie apprend la clé publique du destinataire auprès du relais. Il épingle cette clé la première fois qu'il l'utilise, et refuse ensuite de sceller pour une autre clé au nom du même appareil. Voir la section 10.3 pour ce que cela couvre et ne couvre pas.

5.3 À proximité

Aucune clé de transfert n'est transportée. Les deux appareils dérivent une clé de session entre eux (section 6).

6. L'association À proximité

Deux appareils sur le même réseau local, sans relais, sans compte, sans Internet.

Découverte. Chaque appareil s'annonce par multidiffusion UDP (239.255.66.66:5354) : identifiant de l'appareil, nom, système d'exploitation, version de l'application, clé publique d'identité, port d'écoute. Ces annonces sont en clair et non authentifiées, visibles sur le réseau local, et rien n'est tenu pour fiable sur leur seule foi. « À proximité » est désactivé tant que l'utilisateur ne l'active pas.

Échange. Les appareils se connectent par une WebSocket ordinaire, et chacun envoie un message d'accueil avec sa clé publique d'identité I et une clé publique éphémère E toute neuve. Les deux calculent :

transcription  = SHA-256( "peeza-lan-v1" ‖ tri(I_a, I_b) ‖ tri(E_a, E_b) )clé de session = SHA-256( "peeza-lan-key" ‖ X25519(e_moi, E_pair) ‖ transcription )preuve_moi     = HMAC-SHA-256( clé = X25519(i_moi, E_pair), message = transcription )code           = décimal( 4 premiers octets de SHA-256( "peeza-lan-sas" ‖ transcription ) mod 1 000 000 ), 6 chiffres

tri place les deux clés de 32 octets dans l'ordre de leurs octets, de sorte que les deux côtés hachent la même entrée. Les lettres minuscules désignent des clés privées.

• La clé de session vient des deux clés éphémères : un vol ultérieur d'une clé d'identité ne permet donc pas de déchiffrer un transfert à proximité antérieur.
• La preuve montre que chaque côté détient la moitié privée de la clé d'identité qu'il a présentée. Le pair la vérifie avec X25519(e_pair, I_moi), qui donne la même valeur par symétrie de l'échange, en temps constant.
• Le code couvre les deux clés d'identité et les deux clés éphémères. Quelqu'un qui s'interpose et substitue l'une d'elles fait afficher des codes différents sur les deux écrans.

Premier contact. Les deux écrans affichent le code à six chiffres, et chaque personne confirme qu'ils concordent. La confirmation épingle la clé d'identité du pair ; la connexion suivante à un appareil épinglé ne demande rien. Un appareil qui n'est pas connecté à un compte ne garde aucune épingle : chaque association affiche un nouveau code.

Contenu. La clé de session alimente la section 4 sans changement : manifeste, blocs et accusé, scellés sous la clé de session au lieu d'une clé de transfert. Le transport n'est pas chiffré ; toute la protection sur ce chemin est celle de la section 4.

Un code à six chiffres donne à un attaquant actif une chance sur un million par tentative, et chaque tentative exige que les deux personnes soient justement en train de comparer leurs codes.

7. Les équipes, et les charges utiles détenues par plusieurs appareils

Une équipe est un groupe de comptes qui partagent des fichiers. Un fichier partagé avec une équipe peut être récupéré plus tard auprès de n'importe quel appareil membre qui le détient, pas seulement auprès de l'appareil qui l'a partagé en premier.

7.1 Une clé par charge utile. Une charge utile partagée a une seule clé de transfert. Chaque livraison de cette charge utile à un appareil membre porte cette clé dans sa propre enveloppe scellée (5.2), scellée pour cet appareil, avec la même règle d'épinglage. Le relais garde la liste des membres de l'équipe et un catalogue de ce qui a été partagé — noms, tailles, qui l'a partagé —, et jamais une clé.

7.2 Des trames identiques. Les appareils qui détiennent la charge utile et sa clé la désignent par un identifiant public :

identifiant de charge utile = base64url( SHA-256( "peeza-payload-id-v1" ‖ clé de transfert ) )

L'identifiant ne révèle rien de la clé. Un détenteur sert les mêmes trames que l'expéditeur d'origine l'aurait fait (4.3). Quand un appareil récupère un fichier auprès de plusieurs détenteurs à la fois par des connexions directes, chaque trame est précédée d'une étiquette de 8 octets (les 8 premiers octets du SHA-256 de l'identifiant de charge utile) pour que le destinataire distingue les charges utiles ; ce préfixe sert à l'acheminement, pas à la sécurité. Une trame est acceptée parce qu'elle s'authentifie, quel que soit l'appareil qui l'a envoyée.

7.3 Un détenteur doit prouver ce qu'il scelle de nouveau. La copie d'un détenteur est un fichier ordinaire dans le dossier de l'utilisateur, et elle a pu être modifiée. Sceller un contenu modifié sous la clé et le numéro de bloc d'origine réutiliserait un nonce. C'est pourquoi un appareil qui reçoit enregistre l'étiquette d'authentification de chaque bloc à son arrivée et, avant de servir un bloc, scelle de nouveau sa copie et compare l'étiquette. Un bloc dont l'étiquette ne concorde pas n'est pas servi. Un appareil sans ce registre ne sert rien du tout. Cela protège contre un fichier modifié ; ce n'est pas une défense contre un détenteur lui-même malveillant, qui détient la clé et pourrait mal agir de toute façon.

7.4 Ce qu'implique l'appartenance. Chaque appareil membre qui a reçu une charge utile en détient la clé. Retirer un membre arrête les livraisons futures. Cela ne peut pas reprendre une clé ou un fichier qu'il a déjà.

8. Le transport sous-jacent

Ces protections s'appliquent à la connexion. Elles s'ajoutent à la section 4, et aucune des affirmations de la section 1 n'en dépend.

Si le relais trafique la signalisation. Avec WebRTC, quiconque transporte la signalisation peut substituer les empreintes de certificat et s'interposer au milieu de la connexion DTLS. peeza ne compte pas sur DTLS pour la confidentialité. Un relais qui ferait cela détiendrait la session DTLS et ne verrait toujours que les trames scellées de la section 4, sous une clé qu'on ne lui a jamais donnée : la clé est arrivée dans le fragment d'un lien, dans une enveloppe scellée pour une clé d'appareil épinglée, ou par un échange auquel le relais n'a pas pris part. Il pourrait supprimer ou retarder des trames. Il ne pourrait ni les lire, ni les modifier, ni les raccourcir, ni les remplacer.

Pour trouver un chemin direct, un appareil demande à des serveurs STUN quelle est son adresse publique : celui du relais, et des serveurs publics exploités par Google et Cloudflare. Un serveur STUN voit une adresse IP et rien du transfert. peeza n'utilise aucun serveur TURN ; son propre relais sert de solution de repli.

9. Ce que voit le relais

Le chiffrement cache le contenu. Il ne cache pas qu'un transfert a eu lieu. Le relais voit ou détient :

• Pour chaque transfert qu'il aide à établir : les adresses IP des deux bouts, l'heure, la taille, la date de modification du fichier, et si la charge utile est un conteneur. Pour un transfert relayé, aussi les trames scellées à leur passage, gardées en mémoire seulement.
• Pour un compte connecté : l'identité du compte auprès de son fournisseur de connexion, ses appareils (nom, système d'exploitation, version, clé publique d'identité) et des compteurs d'utilisation.
• Pour un appareil connecté à un compte, tant qu'il est en ligne : un reflet de la liste des transferts de cet appareil, pour que le tableau de bord web du compte puisse l'afficher et la piloter. Ce reflet comprend les noms de fichiers, les tailles et les états. Il exclut les clés, les fragments de liens et les chemins des dossiers locaux. Il est gardé en mémoire et disparaît quand l'appareil se déconnecte.
• Pour une équipe : ses membres et leurs adresses courriel, et le catalogue des fichiers partagés : nom, taille, qui l'a partagé, quand.
• Pour un appareil hors ligne : les enveloppes scellées qui l'attendent (5.2), que le relais ne peut pas ouvrir, pendant au plus 7 jours.
• Pendant qu'un appareil se connecte à un compte : les adresses IP d'où la connexion a été lancée, d'où elle a été terminée dans un navigateur et d'où elle a été récupérée, en mémoire, pour les comparer (10.9) — pendant au plus 15 minutes, jamais écrites sur disque. Le pays et l'opérateur réseau de chacune, tirés d'une base de données que détient le relais, figurent dans les courriels décrits en 10.9 ; les adresses elles-mêmes, non. Ces courriels partent à l'adresse du compte par un fournisseur d'envoi de courriels.
• Pour chaque salle qu'il ouvre : un hachage SHA-256 de la preuve d'expéditeur de la salle, en mémoire. La preuve est faite de 32 octets aléatoires que le relais génère quand un expéditeur ouvre la salle et ne renvoie qu'à cet expéditeur. L'appareil de l'expéditeur la garde avec le transfert (jamais dans le lien, jamais dans le reflet du tableau de bord) et la présente chaque fois qu'il rejoint la salle, pour que le relais puisse distinguer l'appareil qui a ouvert la salle de toute autre personne qui en connaît l'identifiant. Elle ne protège aucun contenu : c'est le relais qui l'a créée, et la clé de transfert n'y intervient pas. Voir la section 10.11.

Donc : dans un transfert fait par lien entre deux appareils qui ne sont connectés à aucun compte, le relais voit un nom scellé et un contenu scellé. Dès qu'un compte est en jeu, les noms de fichiers sont visibles du relais, dans le tableau de bord de ce compte et dans le catalogue de l'équipe. Le contenu ne l'est jamais.

Ce que le relais peut faire : refuser le service, supprimer ou retarder un transfert, et observer ce qui précède. Ce qu'il ne peut pas faire est à la section 1.

10. Limites et exceptions

10.1 Obtenir un lien depuis un autre de vos appareils fait passer cette clé par le relais. Un utilisateur connecté peut demander, depuis le tableau de bord web ou depuis un autre de ses appareils, le lien d'un transfert que l'un de ses appareils propose — pour le copier, le partager ou l'afficher en code QR. L'appareil envoie alors le lien complet, clé comprise, au relais, qui le remet au tableau de bord et cesse de le servir après 30 secondes. Pour ce transfert, à ce moment-là, le relais détient la clé. Cela n'arrive que sur cette demande explicite du titulaire du compte. Cela veut dire qu'un relais compromis, ou une session de compte volée, pourrait aussi la demander.

10.2 Le client web fait confiance au serveur qui le livre. Un navigateur reçoit son code des serveurs de peeza à chaque visite. La clé contenue dans le fragment n'est pas envoyée au serveur, mais le script de la page la lit pour déchiffrer. Un serveur compromis pourrait livrer un script qui envoie la clé ailleurs. C'est vrai de tout chiffrement fait dans un navigateur. Les applications natives n'ont pas cette propriété ; elles ont celle de la section 10.7.

10.3 La première clé d'un appareil vient du relais. L'épinglage (5.2) protège chaque envoi après le premier. Au premier envoi vers un appareil, l'expéditeur fait confiance à la clé publique que fournit le relais. Un relais qui substituerait sa propre clé lors de ce premier contact pourrait ouvrir cette enveloppe. Associer deux appareils en personne (section 6) épingle la clé sans le relais.

10.4 Un lien est un secret au porteur. Quiconque obtient le lien peut recevoir le fichier, une fois. Un lien copié reste dans le presse-papiers, et tout ce qui peut lire le presse-papiers, ou le canal par lequel le lien est envoyé, peut lire la clé.

10.5 Pas de confidentialité persistante pour les transferts par lien et adressés. Une clé de transfert reste la même pendant toute la vie d'un partage. Quelqu'un qui enregistre les trames scellées d'un transfert relayé et obtient plus tard la clé ou le lien peut les déchiffrer. Seul le chemin À proximité dérive une nouvelle clé à chaque connexion.

10.6 Les clés sont des fichiers sur l'appareil. Les clés d'identité, les clés épinglées et les clés des transferts encore affichés dans l'application sont stockées dans le dossier de données de l'application, lisibles par le compte de l'utilisateur et protégées par le système d'exploitation, non par un magasin de clés matériel. Tout ce qui s'exécute sous l'identité de l'utilisateur peut les lire.

10.7 Le code source du moteur est fermé. Ce document, les vecteurs et le client web vous permettent d'examiner la conception et une implémentation de celle-ci. Ils ne vous permettent pas de confirmer qu'une version native donnée n'implémente que cela. Les applications natives sont distribuées signées : notarisation d'Apple et flux de mises à jour signé sur macOS, paquet signé sur Windows, App Store et Google Play sur les téléphones, et sommes de contrôle SHA-256 publiées sur Linux.

10.8 Métadonnées. Voir la section 9. Les adresses IP, les tailles et le moment des transferts sont visibles du relais et, pour un transfert direct, de l'autre appareil.

10.9 Connecter un nouvel appareil peut encore faire l'objet d'un hameçonnage depuis votre propre réseau. Connecter un appareil à un compte ouvre une page dans un navigateur, et rien dans cette page ne la lie à l'application qui l'a demandée. Quelqu'un qui vous persuade de terminer une connexion qu'il a lancée pourrait rattacher son appareil à votre compte. Cela concerne les comptes et le tableau de bord à distance, pas le chiffrement d'un transfert, mais cela se combine avec la section 10.1 : un appareil rattaché à votre compte peut demander à vos autres appareils le lien d'un transfert.

Ce qui fait obstacle. Quand un appareil se connecte, le relais compare le réseau d'où le navigateur a terminé la connexion avec les réseaux d'où l'appareil l'a lancée et récupérée. Ils concordent quand ils partagent une adresse IPv4, ou un même /64 IPv6 ; un côté en IPv4 et l'autre en IPv6 compte comme différent. Quand ils diffèrent, l'appareil ne reçoit rien tant que la connexion n'a pas été approuvée par un lien envoyé par courriel à l'adresse du compte — que la personne qui vous a envoyé un lien ne peut pas lire. Le courriel montre les deux endroits (pays et opérateur réseau, jamais une adresse), dit qu'un RPV (VPN) ou le relais privé iCloud peut les faire différer, et dit de ne pas approuver si quelqu'un vous a envoyé un lien ou vous a demandé de vous connecter. Le navigateur qui a terminé la connexion affiche le même avertissement au lieu de sa page habituelle quand la connexion a été lancée depuis un autre réseau. Si le courriel ne peut pas partir, ou si le compte n'a pas d'adresse, la connexion est refusée ; sans réponse, elle expire après 15 minutes. Chaque connexion envoie aussi au compte un avis qui nomme l'appareil, avec un lien qui le déconnecte, une seule fois, pendant 30 jours : il révoque la session de cet appareil et le retire du compte. Retirer un appareil depuis le tableau de bord ou depuis un autre appareil fait la même chose.

Ce qui reste :

• Un hameçonnage depuis le même réseau passe. Quelqu'un sur votre Wi-Fi, dans votre bureau, ou derrière le même NAT d'opérateur que vous — ce qui peut regrouper de nombreux clients d'un même opérateur mobile — vous ressemble. L'avis et son lien Déconnecter sont ce qui reste dans ce cas.
• Approuver malgré l'avertissement rattache son appareil.
• Le nom de l'appareil dans les deux courriels est celui que l'appareil déclare, et un attaquant le choisit. Les courriels le présentent comme tel.
• Les connexions faites avant que cela existe, et les connexions au tableau de bord web, ne reçoivent aucun avis. Une connexion web renvoie sa session au navigateur même qui l'a terminée ; il n'y a donc pas de seconde partie à hameçonner.
• La part des applications n'est pas encore publiée. Tout ce qui précède relève du relais, et s'applique à toutes les applications déjà installées. Les applications ajoutent un écran « Consultez vos e-mails » pendant qu'une connexion attend d'être approuvée, et envoient le nom de l'appareil pour les courriels. Tant qu'aucune version ne les contient, une application en attente affiche son écran d'attente habituel et abandonne après dix minutes, et les courriels désignent l'appareil par « un appareil ».

10.10 Versions. Un changement du format scellé change VERSION et n'est pas rétrocompatible, à dessein. Le 2026-09-28, le manifeste et l'accusé de réception sont devenus obligatoires ; les applications antérieures ne peuvent pas échanger de fichiers avec les versions actuelles, et échouent avec un message plutôt que de se rabattre sur l'ancien format.

10.11 Un expéditeur qui rejoint une salle n'a pas encore à prouver qu'il l'a ouverte. Les applications et les pages antérieures à la preuve d'expéditeur (section 9) rejoignent une salle en la nommant, et le relais l'accepte encore. Quiconque connaît l'identifiant d'une salle — le destinataire compris — peut donc prendre la place de l'expéditeur dans cette salle. Il n'obtient aucune clé et ne peut produire aucune trame que le destinataire accepterait, puisque chaque trame est scellée sous la clé de transfert ; il peut perturber ce transfert-là. Le relais compte les retours sans preuve valide et les refusera dès que les applications en usage la présenteront.

11. Algorithmes et bibliothèques

Aucun algorithme de chiffrement ni de hachage propriétaire n'est utilisé. Les constructions propres à peeza sont la disposition des trames et des nonces (section 4), la dérivation À proximité (section 6) et la vérification des étiquettes (7.3), toutes décrites ici en entier.

12. Vecteurs de test

Copie lisible par machine : protocol-vectors.json, à côté de ce fichier.

12.1 Transfert

clé (base64url)

0123456789abcdefghijklmnopqrstuvwxyzABCDEFG

clé (hex)

d35db7e39ebbf3d69b71d79f8218a39259a7a29aabb2dbafc31cb30010831051

Manifeste, nonce(0x08, 0), données additionnelles peeza-e2e-v1 :

texte clair

{"n":"holiday photos.zip","s":6000968,"t":1789092766750,"p":true,"d":true,"f":1}

scellé

l1LuMwkPNQZZU1eFaO-6IfCWDsq-T163XFOL5DKjhwJCN-KL4dLeoLjE0eDKgigyXWKWdKdnYueu72MuAqLw3xwovxtbLoDl6KgBhbB5gtc4zdQ25w_i_SWnQk6rO2zG

Nom, nonce(0x01, 0), données additionnelles peeza-e2e-v1 :

texte clair

holiday photos.zip

scellé

UqV9vFmAyQLXm_fBSfscZTFFhWAeVSBQH2aNsrzVZfvivg

Accusé de réception, nonce(0x09, 0), total 6000968, identifiant de salle 1WMcraeO :

texte clair

peeza-received-v1

scellé

Z-YJtRNvDjM3j6eYPnG3tF4uHTskAIWxrchi4Oh57uHc

Bloc numéro 2 d'une charge utile d'une longueur totale de 200000 octets :

texte clair

peeza test chunk

nonce

000000000000000000000002

aad

7065657a612d6532652d76310000000000030d40

trame

0000000000000002de6a0e0ac48439cc0dde96867c21744ed5f634f94749c5f461c74df599d7fc4e

12.2 À proximité

Les clés privées sont faites de 32 octets identiques : identité de A 0x11…, clé éphémère de A 0x22…, identité de B 0x33…, clé éphémère de B 0x44….

A identité publique

7b4e909bbe7ffe44c465a220037d608ee35897d31ef972f07f74892cb0f73f13

A éphémère publique

0faa684ed28867b97f4a6a2dee5df8ce974e76b7018e3f22a1c4cf2678570f20

B identité publique

7b0d47d93427f8311160781c7c733fd89f88970aef490d8aa0ee19a4cb8a1b14

B éphémère publique

ff2ee45601ec1b67310c7790404585ae697331eee1c1f8cf2419731c1fff3e6b

transcription

febacfc413c62c305ca53e9e98cad80171069b29bce55148d2c38bcd0a05ed56

clé de session

997cd336b63a6bb0a91e8528e5cd57360ded08d8ca2e07a8263005ef2fbe2737

preuve de A

d62edfc0a7c7dc90c9844903c5421c268c15c85c4359388c94e779fc9335324a

preuve de B

6f7b5a4dbe8c621e6685b4866c4e51ff1ba92d7c7e1526d506fe65691121f2df

code

678689

13. Signaler un problème

Signalements de sécurité : security@peeza.app. La politique de divulgation et les engagements envers les chercheurs sont à https://peeza.app/security. Si ce document se trompe sur ce que font les applications, c'est aussi un signalement de sécurité.

14. Modifications