je manque de temps pour comparer. Si quelqu'un a un avis...
Pour commencer, je dirais déjà que ce n’est pas tant à mon projet (celui présenté dans le journal) que ssss doit être comparé, mais plutôt au projet libgfshare.
Après un bref coup d’œil au code et sauf erreur de ma part, je pense que la différence la plus importante est que ssss semble appliquer l’algorithme de Shamir sur l’intégralité du secret en un seul bloc, raison pour laquelle le programme est limité au partage de secret d’au maximum 128 octets (1024 bits).
Libgfshare, de son côté, applique l’algorithme octet par octet, et n’a de fait pas de limitation intrinsèque sur la taille du secret à partager.
Sur un plan plus pratique, le mode de fonctionnement de ssss-combine, où l’utilisateur est supposé rentrer les valeurs des fragments « à la main » à l’invite du programme, me semble beaucoup plus fastidieux et error-prone que le mode de fonctionnement de gfcombine, qui lit les fragments depuis des fichiers.
[^] # Re: ssss
Posté par gouttegd . En réponse au journal Gfsecret, le secret réparti en pratique. Évalué à 5.
Pour commencer, je dirais déjà que ce n’est pas tant à mon projet (celui présenté dans le journal) que ssss doit être comparé, mais plutôt au projet libgfshare.
Après un bref coup d’œil au code et sauf erreur de ma part, je pense que la différence la plus importante est que ssss semble appliquer l’algorithme de Shamir sur l’intégralité du secret en un seul bloc, raison pour laquelle le programme est limité au partage de secret d’au maximum 128 octets (1024 bits).
Libgfshare, de son côté, applique l’algorithme octet par octet, et n’a de fait pas de limitation intrinsèque sur la taille du secret à partager.
Sur un plan plus pratique, le mode de fonctionnement de ssss-combine, où l’utilisateur est supposé rentrer les valeurs des fragments « à la main » à l’invite du programme, me semble beaucoup plus fastidieux et error-prone que le mode de fonctionnement de gfcombine, qui lit les fragments depuis des fichiers.