En fait même si ta tx se retrouve direct dans le prochain block et que tu la voit de suite ça ne te donne pas plus de certitude sur la validation définitive de la transaction a cause des possibilités de roll back, donc si j’intégrer le paiement en g1 sur un site je ne fournirai définitivement la prestation que si la tx est dans un block a plus de 6 du bloc courant, il suffit d’une tache cron qui check la blockchain toute les heures et c’est bon 
merci de l’eclairage, ca fait sens avec le document que je souhaite vous partager =)
Je ne comprends pas bien le sens, ici. Tu veux déléguer la signature de la TX ??
En revanche, il me parait plus sage d’avoir une fonction de création du document de TX (sans signature).
Ainsi l’appellant peut vérifier (par exemple, les destintaires, le montant, etc.) puis signer et renvoyer le tout.
Cela économise au moins la création du document, qui effectivement nécessite normalement d’avoir les sources.
Par exemple, pour une terminal de paiement “idiot”, qui n’effectue qu’une signature.
Je vais revenir sur le processus concernant la signature et son implémentation qui me pose problème.
Donc,
“La génération du document de transaction n’est pas une étape sensible” => OK
“C’est seulement et uniquement la signature du hash sha256 du document de transaction … la “carte” soit capable de calculer la signature d’un hash sha256…”
Soit,
je lis la documentation concernant le “format valide” d’un document de transaction :
.duniter/doc/Protocol.md at master · duniter/duniter · GitHub
concernant les transactions :
.duniter/doc/Protocol.md at master · duniter/duniter · GitHub
“A transaction must have signatures matching its content for each issuer”
“matching” des clés publiques => OK, par contre… “Signatures are made over the transaction’s content, signatures excepted”
"Les signatures sont faites sur le contenu de la transaction,
excepté les signatures " <= ???
je dispose également d’examples pour générer un document valide dans cette page.
je dispose de la documentation concernant le RETOUR d’un appel à => tx/process :
.duniter/doc/HTTP_API.md at master · duniter/duniter · GitHub
(au passage, je vois qu’il y a des signatures dans cette réponse…)
requête où il est stipulé en parametre
transaction : the raw transaction
soit => “Version:10\r\n…\r\n”
Maintenant, je ne comprends pas l’utilisation, ici, dans le cadre de la signature, de ces fonctions cryptographique (en l’occurence sha256 mais peu importe…).
Pour moi, une telle fonction prend en paramétre 1 seule information
et me retourne le resultat haché.
exemple sur mon poste :
sha256sum(“abcdef”) = ae06…a57
$>echo “abcdef” | sha256sum
ae0666f161fed1a5dde998bbd0e140550d2da0db27db1d0e31e370f2bd366a57 -
Dixit :
“C’est seulement et uniquement la signature du hash sha256 du document de transaction”
“Signatures are made over the transaction’s content, signatures excepted”
alors, j’applique la fonction sha256 sur mon document de transaction et je nomme le résultat R :
R = sha256(“Version:10\r\n…\r\n”)
et là, je me trouve bien embêté parce que j’en fais quoi de R ?
A quelle moment j’intègre cette information avec ma clé privée ?
Comment et a quelle étape cette information R est transmise ?
Dixit :
“la clé privée d’un compte n’est jamais stockée nulle part sur aucun support physique.” => OK
“Elle est générée a chaque fois que tu saisi ton couple identifiant secret/mot de passe …” => OK
“pour signer une transaction ou une certification” => comment ?
je fais une tentative :
var ID = “max”
var PASS = “monpass”
je concatene mon identifiant et mon mot de pass, applique une fonction de hashage sha256 et j’enregistre ce resultat dans K qui est ma clé privée.
var K = sha256(ID + PASS) ?
var R = sha256(“Version:10\r\n…\r\n”) ?
a quelle étape K signe le document ?
var SIGNED_DOC = sha256(K + R) ?
et cette nouvelle information SIGNED_DOC, j’en fais quoi ?
cette information doit elle faire partie de la requete /tx/process ?
Dixit:
“C’est seulement et uniquement la signature du hash sha256 du document de transaction … la “carte” soit capable de calculer la signature d’un hash sha256…”
Pour revenir au module dont on discute dans l’autre topic et de son fonctionnement (j’ignore ici le code PIN pour simplifier ) :
Je prends 2 parametres :
-en entrée : TX (provenant de l’exterieur, le TPE)
-en interne : K (supposons pour simplifier qu’elle est stockée en dur)
ainsi je hash selon les étapes vu précèdemment et je renvois SIGNED_DOC ?
Tout cela reviens à savoir, s’il vous plait,
selon quelle procédure ma clé privée signe un document de transaction et de quelle manière je communique les informations qui en découlent.
Un tout petit petit petit exemple de code sera le bienvenu.
Il faut signer le document avec libsodium /nacl. Voir l’exemple de la librairie python (méthode sign ) : https://github.com/duniter/duniter-python-api/blob/master/duniterpy/documents/document.py
@Max ok en fait ton problème semble être que tu ne connais pas le concept de signature cryptographique.
Ce concept est basé sur les clés asymétriques : ce qu’une clé chiffre l’autre le déchiffre.
Tu a donc deux cas d’utilisation possible :
-
chiffrer avec la clé publique et déchiffrer avec la clé privée => utilisé pour communiquer un message confidentiel (par exemple un mail chiffré)
-
chiffrer avec la clé privé puis déchiffrer avec la clé publique => utilisé pour la signature numérique.
Comme le chiffrement asymétrique est très lent, et que le but d’une signature n’est pas de cacher le contenu d’un document mais seulement de le “signer”, on signe seulement le hash du document, avec la fonction de hashage de notre choix (dans le protocole duniter c’est actuellement du sha256).
Donc l’individu qui souhaite signer un document chiffre le hash de ce document avec sa clé privée et ajoute ce hash chiffré a la fin du document. C’est ce hash chiffré que l’on nomme signature, hash chiffré = signature.
De là, toute personne ou tout programme qui reçoit ce document peut déchiffrer la signature avec la clé publique du prétendu signataire, et il doit trouver en sortie le hash en clair du document, hash en clair qu’il va vérifier en hashant lui même le document, si les deux hash sont identiques la signature est valide, s’il sont différents la signature est invalide. (c’est pour ça qu’il faut se mettre d’accord sur la fonction de hashage utilisée).
L’explication vidéo en 2min : https://youtu.be/Sx7ZNDppxQc
Dans le cas précis de duniter nous utilisons l’algo de chiffrement asymétrique ed25519, qui a l’avantage de permettre de générer une paire de clé très rapidement, ainsi il n’y a pas besoin des stocker ta clé privée contrairement a PGP par exemple, ta clé privée est régénérée a chaque fois que tu saisie ton couple (id secret+password), mais attention la clé privée n’est pas un hash de ton (id secret+password), c’est une opération mathématique complexe qui nécessite une librairie de crypto comme libsodium ou nacl.
Ceci étant la puce client n’a pas besoin se savoir générer la clé privée, elle pourrais la stockée directement mais chiffré par un code pin. Les 3 seules choses que la puce client doit savoir faire c’est :
- donner sa clé publique sur demande (stockée en clair sur la puce client)
- déchiffré la clé privée stockée vie le code pin que lui donne le terminal commerçant
- chiffré le hash que lui donne le terminal avec la clé privée et retourner ce hash chiffré au terminal commerçant, c’est tout.
Ainsi ce que doit faire le terminal commerçant c’est :
- mémoriser le montant M saisi par le commerçant
- lire la clé publique sur la puce client
- récupéré sur le réseau les sources correspondantes a la clé publique du client et créer le document transaction // Et en parallèle demander au client de saisir son code pin
- Envoyer a la puce client le hash sha256 du document transaction + le code pin
- récupérer le hash chiffré = signature qui lui renvoi le puce client
- vérifier la validité de cette signature
- Si la signature est valide, transmettre le document transaction signé au réseau duniter
3 Likes
Merci pour la procédure,
de la nature même de la fonction SHA256 qui prend 1 seul et unique paramétre,
on peut essayer la
on peut regarder ici
ou encore l’utilisation que je fais la
ALORS:
OK,
apparement c’est la question à 100 millions de Ğ1.
J’insiste :
Comment un individu n’ayant pas connaissance du fonctionnement d’un moteur d’une voiture peut-il lui même écrire la documentation le concernant ? 
La doc, la doc, la doc 
@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 Like
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 
je ne vois que du base64 pour l’encodage de la signature , l’usage de la lib de crypto, c’est où ?
“key.signature” ?
duniter-python-api/duniterpy/key/signing_key.py at master · duniter/duniter-python-api · GitHub ?
1 Like
A priori, tu as key.signature(..) ici :
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 
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 Like
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 
j’étais prêt à sabrer le champagne 
2 Likes
C’est superbe ce que tu es en train de nous produire là