Régulièrement, je tourne en rond et je reviens à mon point de départ. C’est le cas aujourd’hui sur le secret de Shamir.
J’ai hésité entre l’ancêtre ssss et le plus récent libgfshare. En poussant un peu j’ai identifié d’autres implémentations qui se veulent plus fiables, par exemple en implémentant une vérification d’intégrité. Plus j’avançais et plus je trouvais d’alternatives et de dérivés. Le dernier étant SLIP-0039.
Je ne vous colle pas tout mais il y a au moins:
- ssss, le dinosaure, dont l’URL originale n’est même plus en ligne mais qui est encore dans Debian et qui le restera probablement à vie. Il y a un portage Javascript, et même une version qui permet d’ajouter de nouvelles clés à un partage existant.
- libgfshare, qui par rapport à ssss permet de partager un secret d’une taille infinie, et qui lui aussi est dans Debian probablement à vie. Des portages JS existent mais je n’en ai pas trouvé qui permettent d’ajouter de nouvelles clés.
- sss, qui se veut plus sécurisé et qui ajoute une garantie d’intégrité du secret. Le README a la bonne idée de faire une liste d’alternatives. Malheureusement je n’ai pas vu de portage JS et je n’ai pas forcément envie de le faire moi sur un objet mathématique que je ne comprends pas. Il ne semble de toutes façons pas particulièrement connu hors de github.
- sssa, qui semble avoir plusieurs implémentations, mais à priori ni récentes ni très utilisées.
- SLIP39, qui va beaucoup plus loin, avec des notions de groupes sur deux niveaux, une vérification d’intégrité. Il y a l’avantage d’un standard établi (à priori pour des questions de blockchain. Il y a même un portage JS, mais j’ai eu peur de complexifier inutilement la procédure de récupération manuelle.
Bref, j’ai fini par exactement la même conclusion que l’autre fois : Je préfère quelque chose de simple, éprouvé, et le fait de pouvoir ajouter des nouvelles clés après coup a un énorme avantage.
J’ai donc amélioré une vieille implémentation de ssss, et je vais partir de là.
Laisser un commentaire