Dev / transaction process / usage

@Max cette fameuse fonction de signature c’est la fonction de chiffrement de l’algo ed25519, c’est une fonction mathématique complexe que je serait bien incapable de te décrire, il faut nécessairement passer par une librairie tierce de crypto qui intègre l’algo ed25519, comme c’est le cas pour NaCl et libsopdium

1 « J'aime »

merci @elois

comme cela n’etait pas explicitement dit dans ton dernier post,
alors que tu m’as bien décrit que l’on passé par la lib de crypto concernant le hash(id, pass)
maintenant
je sais a quoi m’en tenir :slight_smile:

Oui, cf cette spec : http://nacl.cr.yp.to/sign.html

1 « J'aime »

je ne vois que du base64 pour l’encodage de la signature , l’usage de la lib de crypto, c’est où ?
“key.signature” ?
https://github.com/duniter/duniter-python-api/blob/master/duniterpy/key/signing_key.py ?

1 « J'aime »

A priori, tu as key.signature(..) ici :
https://github.com/duniter/duniter-python-api/blob/7fb1e4d5c909203cf42c72cd1536820e3ed33f4c/duniterpy/documents/document.py#L58

on est bon ou pas ?

4 « J'aime »

Oui a ceci près qu’il est également possible de stocker en clair la clé publique sur la puce client de manière a ce que le terminal commerçant puisse commencer a récupérer les sources et rédiger le document transaction sans avoir a attendre que le client saisisse son code pin, c’est donc beaucoup plus rapide :slight_smile:

Reste 1 doute:

comment tu check ca ?

clé publique+lib crypto pour déchiffrer la signature, on obtient normalement a la sortie quelque chose qui doit être égal au hash sha 256 du document transaction, si c’est différent c’est que la signature est invalide, soit le client s’est tromper dans son code pin sont les données de sa puce sont corrompus.

1 « J'aime »

C’est pas mal, il y a juste “<<< envoi vers SHA256” et sa boîte noire associée “SHA256(TX)” qui en fait n’existent pas.

La signature par la lib de crypto peut se faire sur l’entièreté de la transaction (Version\n...). Pour les blocs c’est vrai qu’on passe par une moulinette de SHA256 pour réduire sa taille, mais pour les transactions on ne le fait pas.

Pour l’explication technique pour les blocs : la signature Ed25519 coûte très cher en CPU, et son coût est directement fonction de la taille des données à signer. Si l’on ne hachait pas le bloc avant signature, alors les gros blocs mettraient sensiblement plus de temps à apparaître que ceux avec peu de données du fait de la preuve de travail.

Bref, on donnerait un handicap aux blocs qui font le plus vivre le réseau. Ce qu’on ne veut pas bien évidemment !

Quand tu auras produit les graphiques que tu voulais, on les mettra dans le Wiki !

vous allez me rendre chèvre :rofl: j’étais prêt à sabrer le champagne :champagne:

2 « J'aime »

C’est superbe ce que tu es en train de nous produire là :slight_smile:

Oui mais n’es-tu pas satisfait d’avoir enfin ces tant attendus graphiques, qu’en plus tu vas pouvoir partager à d’autres nouveaux arrivants souhaitant la même compréhension que toi ?

N’auras-tu pas fait grandement avancer le projet Duniter de cette façon ?!

C’est une super contribution ce que tu fais :slight_smile:

1 « J'aime »

la on est ok ?

3 « J'aime »

Oui mais les emplacement choisis me semblent trompeurs, ainsi il serait plus judicieux de placer a gauche tout les éléments fournis par A (celui qui paye) et a droite tout les éléments fournis par B (celui qui reçoit), car là quelqu’un qui regarde ce graphique et qui ne connais pas peut s’emmêler les pinceaux.

bravo pour ce graph !

plutot que ID, j’aurais mis salt, pour ne pas confondre avec l’UID qui sert à identifier l’utilisateur. Le salt, lui, reste secret.

A noter également (je sais pas si c’est important) que le salt+pass sont d’abord transformé en seed, par la lib Scrypt, et ensuite passé à la lib de crypto NaCL. Les deux lib sont complémentaires.

1 « J'aime »

oui ca l’est :slight_smile:
le salt, en deux mots , c’est quoi ?
Comment a partir de mon identifiant et mot de pass je me retrouve jusqu’a ma case bleu ID ?
l’UID => sert a identifier l’user, a partir de quoi ? et comment il est generer ?

Bon en fait c’est des quiproquo de langages :

salt = identifiant secret dans cesium = Key’s salt dans duniter = secret key dans sakia

Ta case bleu ID ont te propose de remplacer le mot ID par le mot salt c’est tout :slight_smile:
Et la 1ere case libcrypto tu peut préciser si tu veut que c’est la lib scrypt, cette lib donne une seed (graine) donc la private key est un dérivé déterministe tu peut donc rajouter une case seed entre la 1ere case libcrypto et la case priv_key_a.

A noter que dans le cas d’un système puce/carte client cette première étape peut être faite lors de l’initialisation de la puce/carte, pas besoin de la refaire a chaque transaction :wink:

1 « J'aime »

@elois comme il y aura tout un tas de solutions envisageable a mettre en oeuvre, selon les implementations [ technique / coût ] pour le cadre « CB/TPE » je ne fais pas la distinction de qui peut faire quoi :wink: .

En tout cas, ca nous donne une base de référence sur laquelle communiquer :slight_smile:

ceci étant, derniere mouture… jusqu’a ce que je démonte entièrement le code :face_with_monocle:
:joy:

1 « J'aime »

je suis chiant mais je remplacerai “check datas integrity” par “check signature validity” :slight_smile:

1 « J'aime »