Oui, c’est bon pour moi !
As tu aussi regarder si une visu de clef publique pouvait être faite, de manière standard (reproductible) pour générer un avatar reconnaissable ? Ce serait chouette 
avec couleur si possible !
1 Like
Non. (et ce, d’autant moins que le client que je développe est en ligne de commande 
)
Oui, ce serait chouette pour les clients graphiques, ajoutant une sécurité “visuelle” en plus du checksum. Il y a eu des explorations sur le forum d’en face, mais rien n’a été formalisé spécifiquement pour les clefs publiques Duniter.
Ça peut au contraire faciliter le phising donc être encore plus dangereux ! Car si l’image générée à une entropie trop faible, ça ne prendra que quelques minutes voir seconde pour générer un autre trousseau qui donne la même image de contrôle.
Et s’il y a une image de contrôle, les gens se fieront uniquement à l’image et ne regarderont pas la clé publique.
On a creusé cette voie avec @poka pour ğecko, et la conclusion c’est qu’il vaut mieux ne pas mettre d’image de contrôle du tout, car rien dans l’existant n’a d’entropie suffisante pour servir d’anti-phising. En pour avoir une entropie suffisante il faudrait tellement d’images différentes que la plupart seraient trop indiscernable entre elles, sauf à générer des visages (ce que le cerveau humain sait le mieux discerner), mais on a rien trouvé d’existant qui fasse ça.
3 Likes
L’entropie n’est plus un indicateur pertinent, au délà d’une certaine valeur. Par exemple, s’il s’agit de visualisation graphique d’une pubkey, dans une icône de 30px * 30px, l’oeil humain pourra t il distinguer des subtilités au delà d’une certaine limite ? Pas sûr.
jdenticon par exemple, avec ses 800 000 possibilités d’images, ma parait bien mieux qu’un checksum de 3 caractères, pour ajouter un controle supplémentaire graphique et rapide.
On parle d’entropie surtout quand on cherche l’unicité, qu’on veut être précis, mais ici on parle de contrôle additionnel.
Mon idée, dans Cesium, est de mettre l’icone de la pubkey en face de celle-ci. Cela vient donc s’ajouter à la clef et son checksum.
C’est pas vraiment un checksum (ca ne le remplace pas - lui a besoin d’une forte entropie), mais un contrôle moins précis, mais complémentaire.
1 Like
Non ce n’est pas vrai. On parle aussi d’entropie quand on veut savoir le nombre de combinaisons possibles. Ce qui permet dans notre cas de savoir à quel point c’est simple ou difficile de reproduire une valeur.
Non c’est toi qui parles de contrôle additionnel. Moi le dit que c’est un non-sens, ça complexifie la compréhension pour rien d’avoir plusieurs contrôles. Et ça rend plus difficile l’explication des bonnes pratiques de sécurité. «Y a une image mais faut pas s’y fier». On voudrait le faire exprès pour embrouiller l’utilisateur qu’on ne ferait pas mieux.
Je ne te comprends pas @kimamila, j’ai l’impression que tu fais exprès de faire les mauvais choix pour que Cesium soit le plus confusant possible à utiliser tout en étant moins sécure 
Pourquoi veut tu ajouter un «contrôle additionnel», plus il y a de trucs différents à contrôler plus c’est compliqué, pourquoi bordel ??
1 Like
alors disons plutot que contrôle additionnel, parlons d’indicateur.
=> «Y a une image mais ce n’est qu’un indicateur »
une image, ca reste de toute façon quelque chose de “non précis” par définition. Mais la perte de précision est compenser la rapidité de lecture.
Exemple : un enfant qui ne sait pas lire peu distinguer deux figures entre elles, mais cela sera moins précis qu’un identifiant.
Image : Précision-- Rapidité ++
Clef /identifiant : Précision++ Rapidité –
Je vois pas ce qui est dangereux la dedans.
Oui, je le vois bien : tu as beaucoup d’impressions à mon égard. Je n’y peux rien, et tant pis si ca t’énerve.
J’explore des voies, sans pour autant dire que j’irai jusqu’au bout : plutôt que j’ai envie de tester, et toi tu t’offusque avant d’avoir mal (ou que c’est grave !) avant même que ca commence. Calmes toi un peu. On discute c’est tout.
2 Likes
Je l’ai déjà dit je ne suis pas fan des indicateurs supplémentaire.
Il me semble préférable d’avoir un truc plus compliqué mais sécure.
Donc les premiers caractères de la clé + checksum me semble très bien.
La question de savoir si les utilisateurs vont “prendre le temps de vérifier” ou pas (le checksum, etc.). Il faut garder en tête que ces identifiants sont sensible à la case.
Si l’utilisateur ne veut pas prendre le temps, un indicateur visuel rapide (quasi instinctif) peut lui mettre la puce à l’oreille, pour lui signifier "quelque chose ne va pas, mieux vaut que je prennes le temps de vérifier la clef)
Oui, ou bien un écran en plus intermédiaire qui attire l’attention sur clé courte + checksum lors de gros mntant énvoyé et si c la première fois que tu fait un virement sur cette clé, me semble le mieux (né"cessite de sotcker un historique des transactions passés effectués)
Faudrait leur demander 
Et ça va aussi dépendre de l’information qui est affichée en gros, gras, central. Parce que les utilisateurs normaux regardent d’abord ce qui est affiché en gras, gros, et central.
Si cette information centrale est modifiable, pas unique, (par ex. une photo + pseudo CS+) c’est la porte ouverte aux erreurs.
Si cette info centrale, c’est la forme courte de la clef publique, bien sûr qu’ils vont la retenir et la vérifier.
Ce que j’observe actuellement, c’est que les gens qui veulent vérifier la clef publique (au moins une personne sur deux, de mon observation) vérifient d’un coup d’oeil les premiers caractères, parfois les trois derniers. Je suis absolument certain que :
- s’il y a un checksum séparé et mis en valeur par de la couleur, il sera vérifié en plus des premiers caractères, en un coup d’oeil.
- si la clef publique est de forme courte, elle pourra être vérifiée en un coup d’oeil
- si la clef publique sous forme courte est l’information principale, elle sera vérifiée par tous les utilisateurs.
Je copie un extrait de discussion que j’ai eu avec @poka :
Je pense que l’info principale devrait être la clef pub+checksum, de forme courte XXXXXX…:XXX, cliquable pour pouvoir copier la clef complète. […] si tu veux afficher des informations CS+, elles doivent pour moi être d’ordre inférieur à la clef pub + checksum.
Je parle bien de l’affichage de clefs publiques non encore connues du client. Si le client veut stocker un répertoire de contacts fréquents (comme on le fait pour des numéros de téléphone), le fait d’afficher un nom à ces contacts en information principale ne pose pas de souci de sécurité particulier, je pense (tant que la clef pub est toujours présente).
2 Likes
Je plussoie.
@kimamila, le plus confusant dans Cesium, c’est quand il met en gros et gras l’info du profil Cs+ en lieu et place de l’UID.
Il faut trouver une façon d’afficher les clefs et les infos supplémentaires annexes, et la façon de faire des téléphones est devenu un standard. On gère d’abord des numéros. Et si on veut identifier ces numéros, alors on ajoute des infos de contact.
Exemple pour Cesium :
- Clef raccourcie avec checksum en gros et gras : abc…def:xyz
- "Non Membre" ou UID en gros et gras
- En moins gros et non gras les infos Cs+
ErZ…Bh2:Gh8
Kimamila
Benoît Lavenier
(le beau gosse qui passe à la TV…)
Dtc…Rem:MdR
Non Membre
Emmanuel Macron
(le gars jaloux du beau gosse qui passe à la TV)
Ainsi plus de confusion.
5 Likes
Même pour Bernard Arnaud ?
Sauf que
- le uid est BenoitLavenier et pas Kimamila ;-),
- le format court XXXX…XXXX:YYY
- la clef pub 38ME…k4aE:5su
Dois-je vraiment préciser que c’est un exemple ne contenant pas de données personnelles par volonté, et flemme de les chercher ? 
3 Likes