Contexte actuel
Signal utilise aujourd’hui le numéro de téléphone comme identifiant unique. L’inscription repose sur la réception d’un code SMS ou d’un appel vocal, puis le serveur stocke le numéro en clair pour la découverte de contacts. Cette architecture expose un vecteur de métadonnées : chaque compte est directement lié à un numéro observable par le serveur.
Mécanisme proposé
Les contributeurs suggèrent d’employer des zero‑knowledge proofs (ZKP) afin de prouver la possession d’un numéro sans le divulguer. Concrètement, l’utilisateur créerait un engagement cryptographique à partir de son numéro, puis fournirait une preuve de connaissance de ce secret (par exemple un zk‑SNARK) que le serveur vérifierait sans jamais voir le numéro brut. Le même principe sous‑jacent alimente déjà les badges de donation et les groupes Signal, comme le rappelle Talya : « zero‑knowledge proofs are not only the technology behind donation badges and backup payments, but also behind groups ».
Dans ce modèle, le serveur ne conserve que la preuve vérifiée et un identifiant dérivé (hash) du numéro, ce qui réduit la surface d’exposition des métadonnées.
Analyse des contraintes techniques
Le principal défi réside dans la génération d’une preuve fiable et compacte. Les ZKP modernes (zk‑SNARKs, zk‑STARKs) exigent des paramètres de confiance et des circuits de vérification qui peuvent atteindre plusieurs dizaines de kilooctets, ce qui alourdit le processus d’inscription sur des appareils mobiles limités en bande passante. De plus, la preuve doit être liée à un mécanisme de récupération : sans numéro, la réinitialisation du compte nécessite soit une clé de récupération stockée localement, soit un second facteur, augmentant la complexité de l’expérience utilisateur.
Un autre risque est la protection contre les attaques Sybil. Un adversaire pourrait générer un grand nombre de preuves valides en automatisant la création d’engagements, à moins que le protocole n’intègre un coût de calcul ou un taux de limitation côté serveur. Le serveur doit également garantir l’unicité de l’identifiant dérivé pour éviter les collisions, ce qui impose l’usage d’une fonction de hachage résistante aux collisions (ex. SHA‑256) combinée à un sel unique.
Implémentation actuelle et perspectives
87df7029ad43daa8a256bf13c893e2f1f03508f4Le commit Add signal login screen scaffolding montre que l’équipe travaille déjà sur l’interface de connexion sans numéro, même si le code cryptographique n’est pas encore présent. Cette étape prépare le terrain pour intégrer les ZKP dans le flux d’inscription, mais elle souligne aussi que la modification touche principalement la couche UI, laissant la partie protocolaire à concevoir.
En conclusion, l’usage de preuves à divulgation nulle pour éliminer le numéro de téléphone de l’inscription pourrait renforcer la confidentialité de Signal, à condition de surmonter les contraintes de taille de preuve, de gestion des récupérations et de prévention des abus. Le succès dépendra d’une implémentation soigneusement optimisée et d’une validation formelle du protocole avant le déploiement.