Somme de contrôle de la clé publique

@vit @Moul @kimamila pouvez-vous approuver la fusion de la RFC si elle vous sied ?

3 Likes

5 messages ont été scindés en un nouveau sujet : Contrôle visuel de la clé publique

2 messages ont été fusionnés à un sujet existant : Contrôle visuel de la clé publique

Je débarque après la bataille :
Qu’est ce qui à amené au choix de xxxx…xxxx:yyy ?
plutôt que bien plus simple à mémoriser pour moi : xxx…xxx:yyy ?
J’ai conscience que le premier est plus difficile à reproduire pour du phishing, mais avez vous calculé si le 2nd est trop peu robuste ?

1 Like

Demande à @poka, il est à côté de toi :wink:

Ca a été calculé très précisément, à une vache près.

Les 4+4 = 8 caractères viennent du fait que le format court proposé actuellement dans Cesium (et repris dans Silkaj) est de 8 caractères (les 8 premiers).

Non. L’entropie de ce format a été calculée par @elois, qui flotte à coté de toi :innocent:

C’est possible que la question soit posée ici pour servir de reminder

Ok, du coup, si c’est parce qu’historiquement on affiche les 8 premiers, on garderais le même degré de sécurité en affichant :
xxx…xxx:yy
et les … et : facilite le découpage mental et donc facilite la mémorisation.

Pourquoi complexifier en rajoutant 3 caractères à retenir en élevant le tout à 11 caractères ?
Personnellement je serais très favorable à descendre le format court au moins à :
xxx…xxx:yyy (entropie : 58^9 = 7.4e15)
voir à :
xxx…xxx:yy (entropie : 58^8 = 1.2e14)
plutôt que l’actuel :
xxxx…xxxx:yyy (entropie : 58^11 = 2.4e19)

2 Likes

Because 3, is a magic number:wink:

Pour moi le checksum est très important et 2 caractères ne riment plus à grand chose, déjà trois c’est pas beaucoup…

Quitte a réduire, je préfère nettement réduire la clef à 3…3:3. On est pas à une vache près, hein…

1 Like

3…3:3 ça me va

3 Likes

@matograine ça te va aussi ?

Pour la sécurité, je comprend, pour les fautes de frappe, ça me semble suffisant :

Nos CB par exemple intègre un checksum à 1 chiffre.

Je ne sais pas, je ne sais pas à partir de quel niveau l’entropie est acceptable.

Notamment, en considérant qu’on peut faire du fishing avec deux caractères faux, ça ferait une entropie de 58^7 soit ~2.10^12. C’est encore correct ?

En quoi ?
Moins il y a de caractères affiché / à mémoriser, plus il est difficile d’en changer un sans que ça se voit, non ?

Le format court est pour de l’affichage.

Erc…tju:567 // Ero…tju:567 sont très semblables visuellement.

Sinon demandé à élois cequ’il entend par :

10^12 est suffisant comme entropie, ou non?

Oui c’est ça une attaque phishing avec une collision imparfaite, réussir à créer une clé qui ressemble suffisamment pour tromper des gens.

Ça fait une semaine de calcul non-stop pour explorer toutes les combinaisons, je pense que c’est suffisant mais qu’il ne faut pas moins :slight_smile:

1 Like

Bonsoir !

Je viens de proposer un brouillon pour la nouvelle version de la RFC. J’y ai ajouté :

  • la possibilité d’accepter les checksums tels que définis par Tortue pour la compatibilité,
  • la gestion des clefs publiques trop longues,
  • le fait de n’utiliser qu’une passe de sha256. (l’argument de @1000i100 m’a convaincu : si ça change, autant que ça change pour tout le monde.)

En revanche, je ne suis pas du tout convaincu par la forme courte 3…3:3. J’ai donc conservé la forme 4…4:3 définie précédemment.

Notez que la MR est en brouillon justement pour qu’on parle de ça :wink: ping @poka @kimamila @vit @moul @tuxmain si vous voulez en parler.

Ca, c’est un calcul:

  • pour un PC particulier haut de gamme actuel
  • pour attaquer une seule clef pub

Un.e attaquant.e qui veut faire perdre confiance dans le réseau Ğ1 peut chercher des collisions parmi toutes les pubkeys membres voire toutes les pubkeys provisionnées. Les usager.e.s ont actuellement la pratique de rechercher les destinataires par l’intermédiaire de Cesium. Je trouve cette fonctionnalité très pratique, et je trouverais encore plus pratique qu’on puisse le faire pour toutes les clefs publiques provisionnees. Mais ceci implique qu’il soit compliqué de trouver des collisions aussi “facilement”.

S’il est possible de trouver une collision pour une clef pub en une semaine, on peut trouver 1000 collisions (1/3 des membres actuels) en trois jours. Et si on peut tromper 1000 fois une personne… Non, attends, c’est pas ça.


Question sur la forme : dois-je créer un nouveau numéro de RFC et passer la version précédente (0016) en “Discontinued” ?

5 Likes

Non tu peux rester en RFC0016 tant qu’elle n’est pas définitivement approuvée (voir dans le README) et en prod il peut y avoir des changements cassant.

1 Like

Oui, à ma connaissance aucun client en prod n’a implémenté cette RFC.

3 Likes

Cool pour le simple sha256 :slight_smile:

Et pour la forme 3…3:3 même si je la trouve plus simple à mémoriser, effectivement, une semaine de calcul sur un pc standard me semble un peu léger, d’où le fait que je ne me sois pas précipité pour proposer une révision de la RFC.

Peut-être pas pour cette RFC avec le format court de pubkey et peut-être plus pour les adresses envisagées par @elois, je me pose la question d’une forme de checksum constitué de 2 mots de Mnémonic. C’est plus long à écrire que 3 caractères de checksum, mais ça me semble avoir une bien plus grande entropie pour une mémorisation qui me semble plus aisée.
Je ne suis pas sûr que ce soit une bonne idée, mais j’aimerais avoir vos avis histoire de voir si je creuse plus ou non.