L’épisode des DDoS qui a amené à l’usage répandu d’Anubis (l’anti-DDoS qui fait une preuve de travail dans le navigateur), puis le fait malheureux que les spammeurs pouvaient très bien encaisser le coût supplémentaire pour continuer les attaques, m’ont motivé à voir si on pouvait faire la même chose en remplaçant la preuve de travail par une preuve d’appartenance à la TdC. (je parle des DDoS non-intentionnels causés par des débiles inconséquents qui crawlent Internet pour entraîner de l’IA, je ne parle pas des DDoS volontaires qui sont un autre problème)
L’idée est d’envoyer avec sa requête une signature anonyme prouvant qu’on possède bien une clé membre. Le serveur vérifie la preuve, et donne un jeton de session qui peut être réutilisé pendant un certain temps.
Il faut aussi que deux signatures émises par la même clé puissent être détectées comme venant de la même clé.
Ainsi, le serveur peut compter le nombre de requêtes faites par un membre, sans l’identifier, et peut fermer les connexions quand un seuil est dépassé. Posséder 1000 adresses IP n’aidera pas, si on possède une seule clé membre.
Pour limiter l’impact sur la vie privée (pouvoir identifier un utilisateur unique dans le temps même s’il change d’appareil), il y a deux voies complémentaires :
- permettre à chaque membre d’obtenir simultanément un nombre fini de jetons distincts et dissociés. (e.g. si ce nombre est 2, alors je peux utiliser 2 adresses IP sans que le serveur sache que les deux appartiennent à la même personne, mais si je veux en utiliser une troisième elle pourra être reliée à l’une des précédentes)
- réinitialiser les jetons périodiquement. (si j’émets une signature au jour 1 et une au jour 2, elles ne seront pas liées)
Pour cela on peut utiliser les event-based linkable ring signatures. Je viens de trouver un papier (avec une implem en Rust 
) qui décrit un schéma intéressant :
- taille de signature logarithmique en le nombre de membres (en pratique quelques dizaines de ko)
- temps de signature de quelques secondes (notez que la signature n’a pas besoin d’être calculée à chaque requête, une fois par jour peut suffire)
- temps de vérification de quelques millisecondes (important, le but étant de soulager le serveur)
- ces temps courts sont permis par un pré-calcul un poil plus long qui doit être fait à chaque changement de l’ensemble des membres (peut-être quotidiennement)
- post-quantique