@kimamila @vit @tuxmain @Moul voici un premier brouillon de RFC pour le chiffrement des commentaires de transaction :
On pourrait supporter jusqu’à 173 caractères ascii pour le message en lui-même.
@kimamila avec ta lib il te faut utiliser crypto_box_precompute qui correspond bien à crypto_box_beforenm comme l’indique leur doc 
Pour le type de message, pourquoi 0x00 0x01 0x10 0x11 et pas 0b00 0b01 0b10 0b11 ? Ne pourrait-on pas vouloir le chiffrer ?
Pourquoi le préfixe sur 2 octets et pas en uvarint ? L’uvarint permet de ne jamais risquer d’être à court de préfixes.
Parce que 0b n’est pas un préfixe standard, il faudrait prendre le temps de l’expliquer au début de la RFC, tu veux le faire ?
Bof, oui on peut, l’intéret est limité
Oui en uvarint c’est mieux, tu veux faire une MR ? 
À noter que ça complexifie le calcul de la longueur du padding
Ou tout simplement 0x00 0x01 0x02 0x03…
Edit: Le padding a aussi un problème, actuellement ça devrait être 4-len%4 il me semble.
Si on utilise la base64 on a 169 octets au lieu de 204 en base z85. Utiliser une base exotique pour ne gagner que 15 octets à peu d’intérêt, je propose de repasser en base64 pour que ce soit plus simple à implémenter
Aussi il faut réfléchir à l’impact de chiffrement des commentaires en termes d’UX, car déchiffrer tous les commentaires directement peut produire trop de latences si les pages sont grandes et la machine modeste.
Il pourrait par exemple être possible de ne déchiffrer le commentaire d’une transaction que lorsque l’utilisateur clique sur la ligne de la transaction
Trop compliqué, il faut que l’implémentation soit la plus simple possible à réaliser, car contrairement au DEWIF par exemple, cette RFC nécessite une adoption beaucoup plus large par les développeurs des clients, si j’envoie ma transaction à un utilisateur dont le logiciel client ne peut pas déchiffrer le commentaire ça va être problématique.
Après réflexion je pense que non il ne faut pas le chiffrer. Il faut qu’on sache si le commentaire est destiné à être lu par un humain sans avoir à le déchiffrer, pour des raisons de performances.
Du fait du passage en base64 il n’y à plus de padding
J’ai simplifié et précisé la RFC :
@kimamila @vit @Moul pouvez vous relire la RFC ? Êtes vous ok pour chiffrer les messages de cette façon ?
Je précise ce qui devrait être évident afin que ça ne parte pas en hors-sujet ici : cette RFC précise comment chiffrer et déchiffrer des commentaires de transaction, elle ne dit pas s’il faut chiffrer systématiquement où non ni comment décider quand chiffrer où non, ce n’est pas son rôle. Pour ces question la, merci de créer un sujet dédié.
Ici, je souhaite juste qu’on se mette d’accord sur le format de chiffrement, afin de s’assurer que tous les clients seront compatibles entre eux là-dessus. Je compte implémenter ça très rapidement dans ğcli et ğecko, j’aimerais donc avoir vos retours rapidement sur cette RFC, merci
J’ai du mal à comprendre le rôle du champ message type. Il ne sert pas dans la RFC, donc n’est pas utile au chiffrement/déchiffrement. De plus il concerne le contenu possible du message, ce qui ne rend pas la séquence de bytes agnostique du contenu. Je ne pense pas en avoir besoin dans Tikka en tout cas.
Pour le chiffrement/déchiffrement, je dois faire une POC en Python pour voir si j’y arrive 
Idem que @vit : quel est l’intérêt du message type ?
Il ne sert pas dans l’algo.
Sinon le reste me va bien. Bravo !
Je vais aussi faire un PoC rapide dans Cesium.
On pourra ensuite corriger le tir si besoin.
Savoir si le message est destiné à être lu par un humain où une machine. Ainsi on ne perdrais pas des ressources coté client à déchiffrer un message qui n’est pas destiné à être lu par un humain
Question: y a-t-il un intérêt à masquer la longueur des messages, par exemple en ajoutant des espaces derrière le message jusqu’à atteindre la longueur max de 169 ?
Si oui, est-ce le rôle de la RFC de le préciser, ou est-ce libre à chaque client ?
Oui bien vu. On pourrait le gérer dans la RFC en définissant un caractère de fin de chaîne (on utiliserait alors probablement le caractère \0). Mais j’y vois 2 inconvénients:
On pourrait aussi ne pas le gérer dans la RFC. Il suffit au logiciel client émetteur de mentir sur la longueur réelle du message et de caler un caractère de fin de chaîne à la fin du message (par exemple le caractère \0).
J’aimerais avoir l’avis de @kimamila et @vit la dessus. À quel point est il gênant que l’on puisse connaître la longueur d’un commentaire chiffré ? L’obstruction de la longueur doit-elle être gérée dans la RFC où en dehors ?
Si les clients ont la possibilité de le faire, alors la RFC doit á minima définir le caractère utilisé.
Pourquoi ne crées-tu pas de MR pour pouvoir y faire des retours ?
J’ai noté une typo sur un titre.
Fait sur cette MR, je sais pas si ça a été vu.
Je croyais l’avoir déjà créée en même temps que la branche, c’était juste un oubli, voila la MR est créée
Non je ne l’avais pas vu, gitlab ne notifie pas. @tuxmain ce n’est pas la première fois que tu fais une action sur gitlab et que je ne la voie que bien plus tard car je ne suis pas notifié. Pense à me tager la prohaine fois pour que je sois notifié, merci
Peut tu le refaire sur la bonne MR stp ? Merci
Quid des champs commentaires/références vides ?
On laisse le champ vide ou on chiffre le vide, pour se rendre compte que le c’est vide après déchiffrement ? Ça permettrait d’éviter l’authentification pour certaines transactions.
Si le champ est vide, on ne va évidemment pas chiffrer du vide, on envoie un champ vide, c’est indispensable pour ne pas perdre des perfs à déchiffrer des transactions sans commentaire.
J’avoue que je ne sais pas… Mais l’idée d’alourdir la BC ne me plaît pas trop. Autant choisir d’alléger. Ceux qui veulent plus d’anonymisation pourrait le faire via un autre système que les commentaires, non ?
Pour le message type, je dois réfléchir au cas de figure. Car il n’est pas dit qu’un message destiné au machine ne doivent pas, dans certains clients, être aussi lu… En fait l’émetteur peut se tromper, en quelque sorte, sur qui peut lire le message.
Et puis pas sur que ça prenne énormément de ressource de déchiffrer (déjà il n’y aura pas d’accès réseau comme je l’envisageais au départ : l’App devrait donc avoir le temps de déchiffrer)
J’ai un problème dans l’implémentation du déchiffrement :
Compute R = beforenm(crypto_box_beforenm(Sb, Pa))
Il ne semble pas exister de fonction beforenm(argument) dans la bibliothèque Python Nacl…