[C'EST SORTI] - Support BTChip francophone

[the_beast]

Avec mes 2 clés

Code:

C:\...\BTChip\btchip-c-api-master\bin>btchip_getFirmwareVersion.exe
=> e0c4000005
<= 0100010404
Firmware version 1.4.4
Using compressed keys : yes

C:\...\BTChip\btchip-c-api-master\bin>btchip_getFirmwareVersion.exe
=> e0c4000005
<= 0100010405
Firmware version 1.4.5
Using compressed keys : yes

Je vais enfin pouvoir faire mumuse avec tout ceci.

Je vais
1) créer un soft.exe qui récupère un code à envoyer à la clé et renvoie la réponse de la clé
2) Faire un soft python (un peu comme un wrapper) qui utilise cet exe pour communiquer avec la clé.

Par exemple pour commencer,  Python enverra e0c4000005 et affichera la version

Tu as peut être des idées sur le sujet.

[1714838166]

1714838166

[1714838166]

1714838166

[1714838166]

1714838166

[1714838166]

1714838166

[1714838166]

1714838166

[btchip]

Alors oui, sans vouloir te déprimer, si ta cible c'est Python c'est plus simple d'y aller en direct sans piper du C derrière

Je suis en train d'écrire une base (ETA ... quelques jours je suppose selon mon degré d'interruptions) mais tu peux trouver quelque chose d'assez ressemblant içi, https://github.com/Plug-up/daplug-python c'est le meme tronc commun pour la comm (regarde usb.py)

[the_beast]

c'est plus simple d'y aller en direct sans piper du C derrière

OK merci. Je viens de voir, DaPlug utilise python-libusb1 qui est un wrapper (ctypes, etc..) de libusb, donc à priori ca revient un peu au meme.

C'est plus simple si c'est déjà fait que de tout refaire en python.

[prismicide]

Avec mes 2 clés

Code:

C:\...\BTChip\btchip-c-api-master\bin>btchip_getFirmwareVersion.exe
=> e0c4000005
<= 0100010404
Firmware version 1.4.4
Using compressed keys : yes

C:\...\BTChip\btchip-c-api-master\bin>btchip_getFirmwareVersion.exe
=> e0c4000005
<= 0100010405
Firmware version 1.4.5
Using compressed keys : yes

Je vais enfin pouvoir faire mumuse avec tout ceci.

Comme je pense que plein d'amis n'ont pas envie de se retaper un compile sous Mingw/msys, ect...
Pourrais-tu faire un joli zip avec les binaires Windows et les proposer quelque part ? MerccIIIIIIIII

Je referai la compile un de ces 4 moi-même, mais là... je sature

[the_beast]

on a pas envie de se retaper un compile sous Mingw/msys, etc...

Je comprends, vu comment j'en ai ch*** !

Petit  cadeau alors: Made in HuileDeCoude
http://aferron.fr/BTChip/BTChip-C-Master_Win_BIN.zip


Faudra le rajouter sur le GitHub btchip-c-api

[btchip]

thanks, je vais nettoyer un coup et faire ça oui

[kcud_dab]

Bon je confirme que j'aime bien ce produit : j'ai eu l'occasion de jouer plus en profondeur ce WE au hackathon avec un projet à base de BTChip(s) :-)

Pour info à l'aide de la lib JS, on faisait plusieurs opérations sur la chip depuis une page web :
 - check présente carte
 - initialisation de la carte avec un pin
 - unlock de la carte
 - récupération des adresses publiques
 - signature de message
etc..

Et cerise sur le gateaux, j'avais Nicaolas en face (btchip) ce qui est plutot pratique pour certaines sessions debug !

[btchip]

Thanks 

Je vais ajouter quelques exemples de l'utilisation de l'API JS sur github, ça manque dans le léger bazar de KryptoKit, et mettre le sample de signature-au-bon-format aussi.

Aussi j'attends avec impatience la migration de HID dans la mainline de Chrome (à priori pour bientot), qui permettra de se débarasser du problème des drivers sous Windows

[the_beast]

Salut, merci pour l'API Python. J'ai bien bossé dessus.

Voici d'ailleurs un petit exemple:
https://github.com/antonio-fr/BTChip-Test

Code:

>main.py

Dongle BTChip detected

Firmware version : 1.4.4
Using compressed keys : Yes
Mode enabled: standard wallet
Enter PIN:*****
PIN OK
Please Wait...
First Address is 1blablablablahash160blablabla

Avec ma clé 1.4.5, j'ai un problème. Je pense qu'elle ne doit pas être initialisée. mais quand je fais un GET_MODE (0x24) je recois le code erreur N°6985
Ce numéro n'est pas documenté. Et la doc indique que la clé devrait plutot fournir le "flag" 0x80 dans son mode (avec le status 9000).
La doc explique en détails que le "flag" 0x80 indique que le "mask added if forward setup mode was used and the seed has not been redeemed yet".
Est-ce que ca veut dire que c'est seulement le cas quand quand la clé n'est qu'à moitié initialisée?
C'est pas très clair, à la première lecture j'avais compris que 0x80 indiquait une clé non-initialisé.
Voilà c'est pas un gros problème, mais je pense que tu pourrais ajouter "6985" dans les status de GET_MODE en indiquant que ca veut dire "not initialized" (si c'est le cas).

J'ai plus qu'à ajouter la prise en charge de BTChip dans FSV (voir dans ma signature) et Electrum !


Un dernier mot sur la MAJ du firmware. On peut utiliser les fonctions dédiées (0x42) décris en §16.4 et §17.3 pour MAJ. Peut être as-tu déjà un soft tout fait pour MAJ. Peux-tu donner un peu plus de détails pour procéder, et également les liens vers les binaires?

[btchip]

Salut, merci pour l'API Python. J'ai bien bossé dessus.

Voici d'ailleurs un petit exemple:
https://github.com/antonio-fr/BTChip-Test

Code:

>main.py

Dongle BTChip detected

Firmware version : 1.4.4
Using compressed keys : Yes
Mode enabled: standard wallet
Enter PIN:*****
PIN OK
Please Wait...
First Address is 1blablablablahash160blablabla

re-merci pour les tests j'avais vu ça sur twitter, je vais linker sur mes liens refaits de la page dèv ce week-end

Avec ma clé 1.4.5, j'ai un problème. Je pense qu'elle ne doit pas être initialisée. mais quand je fais un GET_MODE (0x24) je recois le code erreur N°6985
Ce numéro n'est pas documenté. Et la doc indique que la clé devrait plutot fournir le "flag" 0x80 dans son mode (avec le status 9000).
La doc explique en détails que le "flag" 0x80 indique que le "mask added if forward setup mode was used and the seed has not been redeemed yet".
Est-ce que ca veut dire que c'est seulement le cas quand quand la clé n'est qu'à moitié initialisée?
C'est pas très clair, à la première lecture j'avais compris que 0x80 indiquait une clé non-initialisé.
Voilà c'est pas un gros problème, mais je pense que tu pourrais ajouter "6985" dans les status de GET_MODE en indiquant que ca veut dire "not initialized" (si c'est le cas).

oui, c'est bien ça, elle n'est pas initialisée, et les status sont documentés n'importe comment, il faut que je refasse une passe, pour l'instant partir du principe que tout ce qui n'est pas "9000" est foireux c'est une bonne base

tu auras un status "8x" uniquement si tu as fait un "forward setup"

J'ai plus qu'à ajouter la prise en charge de BTChip dans FSV (voir dans ma signature) et Electrum !

great

Un dernier mot sur la MAJ du firmware. On peut utiliser les fonctions dédiées (0x42) décris en §16.4 et §17.3 pour MAJ. Peut être as-tu déjà un soft tout fait pour MAJ. Peux-tu donner un peu plus de détails pour procéder, et également les liens vers les binaires?

je suis toujours en train de revoir ça, avec un bon espoir pour le week-end à nouveau. mais normalement ça marche (c)

[the_beast]

re-merci pour les tests j'avais vu ça sur twitter, je vais linker sur mes liens refaits de la page dèv ce week-end

Yep, sur teuteur, je t'avais juste envoyé un petit soft car il y avait un ficher vide et rien de fonctionnel. Alors j'ai fait un tout petit soft de demo pour afficher la version. Puis j'ai fait un truc un peux plus élaboré qui est devenu BTChip-Test. ca me permet surtout de "prendre en main le bignou". (et d'aider d'autres avec ton API)
J'ai fait une petit maj à l'instant, les data send à la clé n'étaient pas bien pris en charge.
Tu as du voir aussi que j'ai essayé de bien documenter comment tout faire fonctionner ton API python sur PC. ca peut servir... (bref, tu peux le recopier/modifier dans ta page de ton API)

oui, c'est bien ça, elle n'est pas initialisée, et les status sont documentés n'importe comment, il faut que je refasse une passe, pour l'instant partir du principe que tout ce qui n'est pas "9000" est foireux c'est une bonne base
tu auras un status "8x" uniquement si tu as fait un "forward setup"

Ca , j'avais bien compris que si ya pas 9000 ya un pb, et donc il faut tout faire pour avoir 9000. Je comprends bien que tu ne peux pas documenter tous les codes d'erreur. Je trouve que la doc est pas mal quand meme (comparé à d'autre soft ;P)

J'ai plus qu'à ajouter la prise en charge de BTChip dans FSV (voir dans ma signature) et Electrum !

great

Ouais enfin je ne suis pas du tout à l'aise avec BIP32, HDW, les transactions , le protocole Bitcoin. Je maitrise bien mieux ECC, DSA, FIPS186-3 , SEC2, ... (et python  ).
Dans un premier temps, je vais juste remplacer les fonctions sign() dans Electrum (ou FSV) , pour faire un PoC. J'aurais peut être besoin d'aide. Je propose une session cet été à la Maison du Bitcoin pour finaliser tout cela (il parait que c'est gratuit pour toi ^^).

Un dernier mot sur la MAJ du firmware. On peut utiliser les fonctions dédiées (0x42) décris en §16.4 et §17.3 pour MAJ. Peut être as-tu déjà un soft tout fait pour MAJ. Peux-tu donner un peu plus de détails pour procéder, et également les liens vers les binaires?

je suis toujours en train de revoir ça, avec un bon espoir pour le week-end à nouveau. mais normalement ça marche (c)

Depuis le temps que tu m'annonces quelque chose, ca devient un serpent de mer cette histoire...  Je crois que c'est juste pour faire le teaser quand tu distribues des clés gratuites (et nous faire regretter notre absence , le cas échéant) 

[btchip]

Yep, sur teuteur, je t'avais juste envoyé un petit soft car il y avait un ficher vide et rien de fonctionnel. Alors j'ai fait un tout petit soft de demo pour afficher la version. Puis j'ai fait un truc un peux plus élaboré qui est devenu BTChip-Test. ca me permet surtout de "prendre en main le bignou". (et d'aider d'autres avec ton API)
J'ai fait une petit maj à l'instant, les data send à la clé n'étaient pas bien pris en charge.
Tu as du voir aussi que j'ai essayé de bien documenter comment tout faire fonctionner ton API python sur PC. ca peut servir... (bref, tu peux le recopier/modifier dans ta page de ton API)

voilà, merci, j'aime bien les samples

Ouais enfin je ne suis pas du tout à l'aise avec BIP32, HDW, les transactions , le protocole Bitcoin. Je maitrise bien mieux ECC, DSA, FIPS186-3 , SEC2, ... (et python  ).
Dans un premier temps, je vais juste remplacer les fonctions sign() dans Electrum (ou FSV) , pour faire un PoC. J'aurais peut être besoin d'aide. Je propose une session cet été à la Maison du Bitcoin pour finaliser tout cela (il parait que c'est gratuit pour toi ^^).

ouais quelque part à partir de mi Juillet ça devrait etre jouable pour moi

Depuis le temps que tu m'annonces quelque chose, ca devient un serpent de mer cette histoire...  Je crois que c'est juste pour faire le teaser quand tu distribues des clés gratuites (et nous faire regretter notre absence , le cas échéant) 

mais ça va super bien marcher quand ça va sortir, et j'ai vachement moins de pre-order que BFL aussi 

[the_beast]

J'ai bien regardé la doc des fonctions: pour l'instant, je pense rapidement implémenter la signature des messages dans FastSignVerify avec le BTChip (0x4E). Ca a l'air assez simple, et ca sera un bon début.

[btchip]

Oui, 4E et la key recovery devraient faire ton bonheur - par contre en 1.4.5, toutes les clés demandent une confirmation second facteur, mais bon je pense que tu vas t'en rendre compte assez vite 

[btchip]

Plus d'APIs et de tests pour les fans du serpent : https://github.com/btchip/btchip-python

[the_beast]

Plus d'APIs et de tests pour les fans du serpent : https://github.com/btchip/btchip-python

J'ai pas mal avancé depuis hier soir. Un grand merci pour avoir ajouté pas mal de choses dans l'API. J'ai essayé les signatures de messages, et fait mon propre squelette de signature. j'ai pas mals de petites questions (évidement  )  

Voici un de mes sample-dev-early-PoC qui permet de donner un message complet signé (PGP style)
http://pastebin.com/K0Rc9WFQ

Code:

USER-DIR> testsig.py
-----BEGIN BITCOIN SIGNED MESSAGE-----
Campagne de Sarkozy : une double comptabilite chez Bygmalion
-----BEGIN SIGNATURE-----
17JusYNVXLPm3hBPzzRQkARYDMUBgRUMVc
H5oNKDkcBTWuwQd7u4ZhTI88OEo+mqGhJL+5zpZJGWt+Dvoa3AEKe93keE7phEHkAvk7PFCidgywndoHUB4CyB8=
-----END BITCOIN SIGNED MESSAGE-----

 

- Le dongle pourra t-il fournir une information de parité de yR, comme expliqué dans SEC1-v2? Ca évite de refaire tout un tas de calculs try & guess pour trouver un simple bit.

- S est-il fourni dans le "lower part" du champ de Z(n), comme le spécifie la "norme Bitcoin" ? Cela réduit la malléabilité des signatures. Par exemple dans FSV c'est le cas à la génération, mais pas encore à la vérification (pour bien respecter RFC1958 §3.9 LOL)

- Dans ton exemple de test de signature, r (xR) est donné sur 33 bits avec le premier byte à x00. Est-ce là la parité de yR (x00 / x01) ?
Ca ne respecte pas la norme DER (ITU X690), on doit minimiser la longueur utilisée, dont pas de leading zero. Alors d'accord, tu n'évoques uniquement ASN-1 et pas DER dans ta doc, Mais ca me semble "suspect'" ou une "mauvaise pratique".
Et normalement dans SEC1 si un point est compressé, il commence par "02 ou "03" (OK, r = xR n'est pas un vecteur/point mais un scalaire, enfin la composante sur "x")

- Comment savoir si la pub key est compressée à partir de l’adresse bitcoin "hash160"? Le BTChip fonctionne t-il toujours avec des adresses compressé? (parceque bon, j'ai bien galéré en me demandant ou je m'étais planté avant de voir que c'est simplement l'adresse publique qui est donné 'compressée') Ca semble être un paramètre à l'init du dongle, mais peut on avoir cette info par la suite (~ get setup)?


En parcourant la datasheet du composant de la clé, j'ai vu qu'il y avait un TRNG, accessible via ton API. J'ai aussi créé un petit script python de création d'adresse dont la source est un dongle. C'est cool parceque je cherchait un dongle entropy key TRNG pour m'amuser et BTChip permet de le faire.  


PS: Dans le prochain test vector, tu pourras mettre:
"Faouzi Lamdaoui, conseiller de Hollande, soupconne de fraude fiscale" (ici)  

[the_beast]

Pour les compressed addresses, c'est un flag dans get_version ? "Using compressed keys : Yes" ?

[btchip]

J'ai pas mal avancé depuis hier soir. Un grand merci pour avoir ajouté pas mal de choses dans l'API. J'ai essayé les signatures de messages, et fait mon propre squelette de signature. j'ai pas mals de petites questions (évidement  )  

Voici un de mes sample-dev-early-PoC qui permet de donner un message complet signé (PGP style)
http://pastebin.com/K0Rc9WFQ

Code:

USER-DIR> testsig.py
-----BEGIN BITCOIN SIGNED MESSAGE-----
Campagne de Sarkozy : une double comptabilite chez Bygmalion
-----BEGIN SIGNATURE-----
17JusYNVXLPm3hBPzzRQkARYDMUBgRUMVc
H5oNKDkcBTWuwQd7u4ZhTI88OEo+mqGhJL+5zpZJGWt+Dvoa3AEKe93keE7phEHkAvk7PFCidgywndoHUB4CyB8=
-----END BITCOIN SIGNED MESSAGE-----
 

mais tu le pré-prépares pas bien pour la key recovery là non ?

- Le dongle pourra t-il fournir une information de parité de yR, comme expliqué dans SEC1-v2? Ca évite de refaire tout un tas de calculs try & guess pour trouver un simple bit.

un petit lien ? pour moi ils font une boucle (4.1.6 / 1.6)

- S est-il fourni dans le "lower part" du champ de Z(n), comme le spécifie la "norme Bitcoin" ? Cela réduit la malléabilité des signatures. Par exemple dans FSV c'est le cas à la génération, mais pas encore à la vérification (pour bien respecter RFC1958 §3.9 LOL)

je vote que non (et que je n'ai pas forcément la place pour corriger, après si le client officiel le vérifie, faudra probablement que je trouve la place )

- Dans ton exemple de test de signature, r (xR) est donné sur 33 bits avec le premier byte à x00. Est-ce là la parité de yR (x00 / x01) ?
Ca ne respecte pas la norme DER (ITU X690), on doit minimiser la longueur utilisée, dont pas de leading zero. Alors d'accord, tu n'évoques uniquement ASN-1 et pas DER dans ta doc, Mais ca me semble "suspect'" ou une "mauvaise pratique".
Et normalement dans SEC1 si un point est compressé, il commence par "02 ou "03" (OK, r = xR n'est pas un vecteur/point mais un scalaire, enfin la composante sur "x")

c'est codé comme spécifié dans la partie "DER encoding" de BIP 62

"R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required."

donc je ne vois pas le hic.

- Comment savoir si la pub key est compressée à partir de l’adresse bitcoin "hash160"? Le BTChip fonctionne t-il toujours avec des adresses compressé? (parceque bon, j'ai bien galéré en me demandant ou je m'étais planté avant de voir que c'est simplement l'adresse publique qui est donné 'compressée') Ca semble être un paramètre à l'init du dongle, mais peut on avoir cette info par la suite (~ get setup)?

ça rejoint ta question d'après, si tu as fait un setup normal (sans mode 'uncompressed keys'), tous les calculs internes sont réalisés à partir de la version compressée de la clé. Quand on fait un GET WALLET PUBLIC KEY, le dongle renvoie toujours la version non compressée, par contre, histoire de pouvoir rejouer les calculs / vérifier plus rapidement la signature. Donc pour savoir si tu es dans ce mode là ou pas, GET FIRMWARE VERSION effectivement.

En parcourant la datasheet du composant de la clé, j'ai vu qu'il y avait un TRNG, accessible via ton API. J'ai aussi créé un petit script python de création d'adresse dont la source est un dongle. C'est cool parceque je cherchait un dongle entropy key TRNG pour m'amuser et BTChip permet de le faire.  

oui, plaisir d'offrir (en attendant la clé de Mycelium ...)

PS: Dans le prochain test vector, tu pourras mettre:
"Faouzi Lamdaoui, conseiller de Hollande, soupconne de fraude fiscale" (ici)  

pas de bol, le sample a été écrit au mauvais moment  
meme si statistiquement parlant j'avais plus de chances de tomber sur eux

[the_beast]

tu le pré-prépares pas bien pour la key recovery là non ?

Non, j'attendais tes réponses avant de continuer. Parceque justement la key recovery c'est plus compliqué qu'une lecture de bit ;P (pas de key recovery dans FSV à la signature). Faire une key recovery alors qu'à un moment on a la clé, c'est un peu bete, il suffit juste d'extraire un bit de yR à la signature (cf point suivant et pull-req Electrum)

- Le dongle pourra t-il fournir une information de parité de yR, comme expliqué dans SEC1-v2? Ca évite de refaire tout un tas de calculs try & guess pour trouver un simple bit.
- Un petit lien ? pour moi ils font une boucle (4.1.6 / 1.6)

SEC1-v2 §4.1.3 Signing Operations p45:
Optionally, output additional information needed to recover R efficiently from r.
The additional information needed to compute R can consist of the point R itself, in either compressed
or uncompressed form. However, since r provides considerable information about xR, it
is often sufficient to provide no extra information to determine xR. At worst, log2(h + 1) bits are
needed to find xR from r. In any case, information needed to recover yR can take the form of single
bit, or the full value of yR depending on whether compactness or speed is preferred.

C'est d'ailleurs ce qui est fait dans la signature de message Bitcoin, le header contient un flag de parité de yR (LSB du premier char, 27 ou 28 en std).
Ca permet de rendre déterministe (sans boucle) le recovery de yR et ensuite de Q (=s.R-e.G /r ). Sans cette information, il y a 2 yR possibles, il faudrait les tester jusqu'à matcher Q.
Dans une transaction Bitcoin, on a la clé publique entière, on vérifie autrement. Mais là on vérifie une self-signature, et le document SEC indique que dans ce cas (§4.1.6) : "Several candidate public keys can be recovered from a signature. At a small cost, the signer can generate the ECDSA signature in such a way that only one of the candidate public keys is viable, and such that the verifier has a very small additional cost of determining which is the correct public key."

- S est-il fourni dans le "lower part" du champ de Z(n), comme le spécifie la "norme Bitcoin" ? Cela réduit la malléabilité des signatures. Par exemple dans FSV c'est le cas à la génération, mais pas encore à la vérification (pour bien respecter RFC1958 §3.9 LOL)
- Je vote que non (et que je n'ai pas forcément la place pour corriger, après si le client officiel le vérifie, faudra probablement que je trouve la place)

Ce sont les utilisateurs qui votent, pas toi  . Par contre, au niveau de la vérification je ne sais pas. C'est vérifié pour les nouvelles transactions au moins? Je crois qu'effectivement ce n'est pas vérifié pour les messages (sinon risque de répudier les anciens). En tout cas dans FSV, j'essaye de coller au plus près du standard (reference client master). BIP62 NewRule #1 indique: "We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range)."
Tu devrais faire pareil, ca évite certains problèmes. D'un autre coté si c'est jamais vérifié, je ne vois même pas à quoi sert cette modification à la génération. Provisoirement, le retour en lower peut peut être fait dans le PC (le code existe dans FSV).

c'est codé comme spécifié dans la partie "DER encoding" de BIP 62
"R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required." donc je ne vois pas le hic.

Ah OK, je pensais le DER plus simple. Autant pour moi... C'est bon alors, je vais juste devoir compléter un peu l'extraction de r et s.

Si tu as fait un setup normal (sans mode 'uncompressed keys'), tous les calculs internes sont réalisés à partir de la version compressée de la clé. Quand on fait un GET WALLET PUBLIC KEY, le dongle renvoie toujours la version non compressée, par contre, histoire de pouvoir rejouer les calculs / vérifier plus rapidement la signature. Donc pour savoir si tu es dans ce mode là ou pas, GET FIRMWARE VERSION effectivement.

Je récapitule pour bien comprendre:

• GET WALLET PUBLIC KEY retourne toujours la clé non-compr (même en mode compr)
• GET FIRMWARE VERSION permet de connaitre le mode compr or not
• Lors de l'écriture du message de confirmation (keyboard), la clé fournie est la clé selon le mode

(je me disais aussi, mince la clé get_pub_key et la clé fournie dans le message "keyboard" est différente.)

[btchip]

tu le pré-prépares pas bien pour la key recovery là non ?

Non, j'attendais tes réponses avant de continuer. Parceque justement la key recovery c'est plus compliqué qu'une lecture de bit ;P (pas de key recovery dans FSV à la signature). Faire une key recovery alors qu'à un moment on a la clé, c'est un peu bete, il suffit juste d'extraire un bit de yR à la signature (cf point suivant et pull-req Electrum)

- Le dongle pourra t-il fournir une information de parité de yR, comme expliqué dans SEC1-v2? Ca évite de refaire tout un tas de calculs try & guess pour trouver un simple bit.
- Un petit lien ? pour moi ils font une boucle (4.1.6 / 1.6)

SEC1-v2 §4.1.3 Signing Operations p45:
Optionally, output additional information needed to recover R efficiently from r.
The additional information needed to compute R can consist of the point R itself, in either compressed
or uncompressed form. However, since r provides considerable information about xR, it
is often sufficient to provide no extra information to determine xR. At worst, log2(h + 1) bits are
needed to find xR from r. In any case, information needed to recover yR can take the form of single
bit, or the full value of yR depending on whether compactness or speed is preferred.

C'est d'ailleurs ce qui est fait dans la signature de message Bitcoin, le header contient un flag de parité de yR (LSB du premier char, 27 ou 28 en std).
Ca permet de rendre déterministe (sans boucle) le recovery de yR et ensuite de Q (=s.R-e.G /r ). Sans cette information, il y a 2 yR possibles, il faudrait les tester jusqu'à matcher Q.
Dans une transaction Bitcoin, on a la clé publique entière, on vérifie autrement. Mais là on vérifie une self-signature, et le document SEC indique que dans ce cas (§4.1.6) : "Several candidate public keys can be recovered from a signature. At a small cost, the signer can generate the ECDSA signature in such a way that only one of the candidate public keys is viable, and such that the verifier has a very small additional cost of determining which is the correct public key."

ok, vu, malin pour accélérer, avec un peu de chance peut etre meme que ça pourra tenir, je savais que j'avais bien fait de ne pas valider la 1.4.6 

- S est-il fourni dans le "lower part" du champ de Z(n), comme le spécifie la "norme Bitcoin" ? Cela réduit la malléabilité des signatures. Par exemple dans FSV c'est le cas à la génération, mais pas encore à la vérification (pour bien respecter RFC1958 §3.9 LOL)
- Je vote que non (et que je n'ai pas forcément la place pour corriger, après si le client officiel le vérifie, faudra probablement que je trouve la place)

Ce sont les utilisateurs qui votent, pas toi  . Par contre, au niveau de la vérification je ne sais pas. C'est vérifié pour les nouvelles transactions au moins? Je crois qu'effectivement ce n'est pas vérifié pour les messages (sinon risque de répudier les anciens). En tout cas dans FSV, j'essaye de coller au plus près du standard (reference client master). BIP62 NewRule #1 indique: "We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range)."
Tu devrais faire pareil, ca évite certains problèmes. D'un autre coté si c'est jamais vérifié, je ne vois même pas à quoi sert cette modification à la génération. Provisoirement, le retour en lower peut peut être fait dans le PC (le code existe dans FSV).

voilà, vais relire pour voir le niveau de nécessité. Sur le fond je suis d'accord, là le pauvre chip est juste ras la gueule (jusqu'à notre prochaine optimisation magique, en général on est assez doués pour déclencher un nouveau cycle quand la situation devient vraiment trop désespérée  )

c'est codé comme spécifié dans la partie "DER encoding" de BIP 62
"R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required." donc je ne vois pas le hic.

Ah OK, je pensais le DER plus simple. Autant pour moi... C'est bon alors, je vais juste devoir compléter un peu l'extraction de r et s.

Si tu as fait un setup normal (sans mode 'uncompressed keys'), tous les calculs internes sont réalisés à partir de la version compressée de la clé. Quand on fait un GET WALLET PUBLIC KEY, le dongle renvoie toujours la version non compressée, par contre, histoire de pouvoir rejouer les calculs / vérifier plus rapidement la signature. Donc pour savoir si tu es dans ce mode là ou pas, GET FIRMWARE VERSION effectivement.

Je récapitule pour bien comprendre:

• GET WALLET PUBLIC KEY retourne toujours la clé non-compr (même en mode compr)
• GET FIRMWARE VERSION permet de connaitre le mode compr or not
• Lors de l'écriture du message de confirmation (keyboard), la clé fournie est la clé selon le mode

(je me disais aussi, mince la clé get_pub_key et la clé fournie dans le message "keyboard" est différente.)

en mode compressé (par défaut donc), GET WALLET PUBLIC KEY doit renvoyer le hash160 de la clé compressée (idem keyboard), et la clé publique non compressée. Sinon c'est qu'il y a un soucis.