[resolu] maj 2.9 : probleme de publicKey

A

Anonymous

Invité
#1
Bonjour à tous,

suite à la maj 2.9 de D****, je rencontre de sérieux problèmes dans l'adaptation des fichiers as3 decompilés de façon approximative par le swf decompiler.
Aussi j'aimerais avoir l'avis (entre autres^^) de ceux qui ont codé leur bot en as3 et qui ont réussi l'intégration (la connexion) de la nouvelle maj.

Le 1er problème se situe dans le "AuthentificationManager.as", avec la fonction "setPublicKey".

Code:
public function setPublicKey(param1:Vector.<int>) : void {
	var _loc_2:* = new ByteArray();
	var _loc_3:int = 0;
	while (_loc_3 < param1.length){
	
		_loc_2.writeByte(param1[_loc_3]);
		_loc_3++;
	}
	_loc_2.position = 0;
	var _loc_4:* = new ByteArray();
	var _loc_5:* = PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length));
	PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)).verify(_loc_2, _loc_4, _loc_2.length);
	this._publicKey = "-----BEGIN PUBLIC KEY-----\n" + Base64.encodeByteArray(_loc_4) + "-----END PUBLIC KEY-----";
	return;
}// end function
Mis à part les incohérences liées à la décompilation et l'utilisation (inutile ?) d'une sous-sous-classe de ByteArray (AuthentificationManager__verifyKey), je trouve bizarre que la clé publique ait besoin à ce stade d'être décryptée (RSAKey.verify()).
Bref, le code actuel retourne un _loc_5 == null et fait planter "verify",
ou,
si j'utilise le byteArray _loc_2 (qui contient la clé) à la place du byteArray vide dans "PEM.readRSAPublicKey()", j'obtient une erreur de dépassement de longueur du byteArray en arrivant à "DER.parse(...)".

Si je court-circuite la partie PEM pour créer la "this._publicKey" comme dans la 2.8, en utilisant directement le ByteArray _loc_2 :
Code:
this._publicKey = "-----BEGIN PUBLIC KEY-----\n" + Base64.encodeByteArray(_loc_2) + "-----END PUBLIC KEY-----";
... alors la fonction setPublicKey(...) se termine proprement, mais le 2eme problème survient plus loin, dans le "getIdentificationMessage()".
Et là, c'est le "this.cipherRsa(...)" qui me plante ici :
Code:
_loc_5 = RSA.publicEncrypt(this._publicKey, _loc_4);
... comme par hasard, à cet endroit dans le "RSA.as" :
Code:
PEM.readRSAPublicKey(param1) // param1 = publicKey !!!
... retour à la case départ :(

En gros, je patauge grave.
- Est-ce-que ma "publicKey" est mauvaise ?
- Est-ce-que mes fichiers de crypto (PEM, RSAKey, DER) sont incompatibles ? (j'utilise ceux du package 'hurlant' de 'as3Crypto' et non les décompilés du d*Invoker)
- Est-ce-que je dois absolument utiliser le "Base64.as" de "by.blooddy.crypto" plutôt que celui de "hurlant.util" ? (pourtant un Base64 est un Base64...)

Alors désolé pour ce déballage brutal, mais vraiment toute piste est la bienvenue, car je m'arrache les cheveux avec toute cette m***e :(

Sur ce, bonne soirée et merci d'avance :)

Atlantide-Le-Dépressif
 
A

Anonymous

Invité
#2
Re: maj 2.9 : probleme d'encryptage à la connexion

Désolé pour ce pavé indigeste que j'ai posté hier...
mais j'ai pu cibler un peu mieux l'origine de mon problème.

Il vient de la propriété "key" reçue à réception du HelloConnectMessage.
Elle semble formatée différemment dans la 2.9 et dans la 2.8
et je ne réussis pas faire le bon traitement pour la rendre utilisable dans la fonction setPublicKey() de AutentificationManager.

Alors si quelqu'un pouvait me dire comment il a réussi à contourner ce problème, ça m'aiderait vraiment.
Merci d'avance.

Atlantide
 

bouh2

Membre Actif
Inscrit
12 Septembre 2008
Messages
184
Reactions
21
#3
Re: maj 2.9 : probleme de publicKey

Je n'ai pas exploré completement le problème mais il est possible que les BigInteger contenu dans la clé (voir le fonctionnement du cryptage RSA) soit encodé en big endian et pas en little endian, d'ou le problème.

Ce n'est qu'une hypothèse
 
A

Anonymous

Invité
#4
Re: maj 2.9 : probleme de publicKey

Sachant que de la 2.8 à la 2.9, la clé a gagné 11 bytes (je crois) donc il ne s'agit pas de ce problème.

Sachant que une clé publique RSA fini généralement par 01 00 01 (65 537)

Alors que la clé sur 2.9 :
10 84 19 EF D6 F1 0D 61 41 5D 35 5F 58 F8 A0 61 C8 B3 45 03 E1 B1 AE 03 4C 22 CD
90 11 34 A4 51 42 BB 8F E8 0C 7A 09 DB 29 20 3C 9D 04 AA 8B E2 65 ED 30 42 21 CD
70 09 5C DA 23 2E 50 92 87 36 6B 3F EA 07 D1 68 4C BF 26 FC 86 56 AC 92 84 EB BE
C8 95 CD DD F0 77 64 2D 6B 27 EB 3C F4 24 25 B4 FE 1A 3C CB 3F 25 1C FE 71 B9 E1
29 20 65 B8 30 A7 77 00 D3 D1 25 F8 93 FA 0D 8F BA 70 A9 01 D5 5B 94 B5 FA 4E A9
63 57 DB 8C 1F 1D 14 1C 18 4C B9 4D 49 76 0B 52 DA CE DC F5 D9 A1 76 74 D6 DB 8E
97 7E 68 3C 41 06 63 1D E8 5B 61 7D DC 0B 38 2F FD C2 00 23 91 C0 47 37 18 A1 AD
EA 03 DC 61 F5 A8 09 F4 8F E0 79 F3 D7 51 57 2B 77 D8 7D 03 E3 BB A1 5E A9 4C A0
52 E2 A4 2B 14 48 92 64 04 2C CA 56 1F F1 29 10 74 2F DF CC 4F 12 F2 0B A7 62 CA
D4 51 26 62 D6 60 80 D8 90 5E 80 42 03 16 6D CF DB 95 B5 8E 0B 41 EB 80 C1 6D B8
49 DE C4 67 D9 02 E1 40 AB E7 61 D4 C4 6F C2 7F 57 44 C4 BE B3 A7 25 73 0A 2E 7B
4E 7C 49 6D 11 70 70 6A

Il y avait une histoire avec DER ou PEM, a voir?

Bon courage !
 
A

Anonymous

Invité
#5
Re: maj 2.9 : probleme de publicKey

Merci pour vos pistes, je vais étudier ça :)

Mais avant tout, je trouve étrange d'être le seul à qui ce problème se pose.
Comment vous (et tous les autres) avez réussi à remettre votre bot à jour sans y avoir été confronté ???
Car ça pourrait également être une solution pour moi (pas que le fait de fouiller dans le bytecode me dérange... quoique !)

Enfin, je vais me préparer une BigCafetière et me replonger dans les sources :)

Atlantide-Nouvel-Espoir
 

BlueDream

Administrateur
Membre du personnel
Inscrit
8 Decembre 2012
Messages
2 010
Reactions
149
#6
Re: maj 2.9 : probleme de publicKey

MITM ;)
 
A

Anonymous

Invité
#7
Re: maj 2.9 : probleme de publicKey

En faite, ceux utilisant un bot type MITM n'ont pas ce probleme, puisque la connection ne se fait pas grace au bot mais bien par le client.

Dans mon cas, j'ai mis en pause mon émulateur, puisque j'ai commencer un autre projet et donc je n'ai pas trop cherché.


Sinon, le fait que ca ne marche pas viens du fichier RSAKey, l'erreur se fait dans une fonction appellé verify ou _Decrypt, si mes souvenirs sont bon.
Tiens moi au courant !
 
A

Anonymous

Invité
#8
Re: maj 2.9 : probleme de publicKey

ok, merci, je te dirai tout ça

Atlantide
 
A

Anonymous

Invité
#9
Re: maj 2.9 : probleme de publicKey

j'ai essayé de remplacer le package hurlant initial de d**** par d'autres packages hurlant originaux tels que as3Crypto et hurlant_tls, mais aucun changement. Quelquesoit le package utilisé, le plantage s'effectue toujours au même endroit : PEM.readRSAPublicKey()

Alors je me dis que ce ne sont peut-être pas les fichiers DER, PEM ou autre qui sont en cause et avant de les décortiquer, il est peut-être utile de regarder en amont.

Effectivement, la clé envoyée par le serveur est plus longue que dans la 2.8. Si j'utilise une clé de 2.8, là, le PEM.readRSAPublicKey() fonctionne correctement.

Ce qui me pousse à penser que l'utilisation de la clé n'a pas changé, mais qu'il est nécessaire de la décrypter (ce qui est nouveau) avant de pouvoir l'utilliser.

... et c'est ce bout de code que je tentais d'ignorer jusqu'alors qui reste un mystère :

Code:
var _loc_5:* = PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length));
PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)).verify(_loc_2, _loc_4, _loc_2.length);
malgré les incohérences de décompilation, on a bien l'exécution d'une fonction "verify" qui est censée décrypter quelquechose... quoi ?
et c'est le résultat de cette verif/decryptage qui est ensuite utilisé pour définir réellement la clé publique dont on va se servir.

Je suis donc persuadé que si l'on résoud cette énigme, on résoud le problème de la publicKey valide, et donc, de la connexion.
Je reposterai ce soir (là je n'ai pas le temps), pour exposer mon début d'analyse de ce code.
Mais je pense qu'il faut commencer à chercher de ce côté avant de remettre en question le package hurlant

Atlantide
 
A

Anonymous

Invité
#10
Re: maj 2.9 : probleme de publicKey

bon là j'ai un peu de temps devant moi, je vais décortiquer la fonction setPublicKey(param1:Vector.<int>) : void de AuthentificationManager.as version 2.9
afin d'y voir un peu plus clair dans le fonctionnement "théorique" de la création de la publicKey "utilisable".

Code:
public function setPublicKey(param1:Vector.<int>) : void {
            var _loc_2:* = new ByteArray();
            var _loc_3:int = 0;
            while (_loc_3 < param1.length){
                
                _loc_2.writeByte(param1[_loc_3]);
                _loc_3++;
            }
            _loc_2.position = 0;
            var _loc_4:* = new ByteArray();
            var _loc_5:* = PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length));
            PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)).verify(_loc_2, _loc_4, _loc_2.length);
            this._publicKey = "-----BEGIN PUBLIC KEY-----\n" + Base64.encodeByteArray(_loc_4) + "-----END PUBLIC KEY-----";
            return;
        }// end function
1) Analyse des nombres (int) qui vont composer la clé publique
Code:
var _loc_2:* = new ByteArray();
            var _loc_3:int = 0;
            while (_loc_3 < param1.length){
                
                _loc_2.writeByte(param1[_loc_3]);
                _loc_3++;
            }
            _loc_2.position = 0;
Ici, c'est la partie commune aux versions 2.8 et 2.9.
Pas de problème, on parse le vecteur d'int passé en paramètre (param1) pour remplir un ByteArray (_loc_2), qui contient donc le corps de la clé "brute" en binaire.

2) Nouveau ByteArray
Code:
            var _loc_4:* = new ByteArray();
On crée ensuite un nouveau ByteArray (_loc_4).
Attention, dans la v2.8, _loc_4 est une String, qui servait à contenir le corps de la clé "brute" encodé en String. C'était suffisant, il restait à ajouter le header et le footer et la publiqueKey était utilisable en l'état.
Ici, ce n'est plus le cas. _loc_4 est un ByteArray qui, semble-t-il, est destiné à recevoir le corps de la clé "purifiée", ou "vérifiée" ou "décryptée" (c'est comme on veut). On verra plus loin la "purification".

3) Création d'une RSAKey (fictive ???)
Code:
            var _loc_5:* = PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length));
On crée _loc_5 qui, malgré le *, sera de type "RSAKey".
Et c'est là le premier problème : créer une RSAKey à partir de rien : ça ne marche pas, et ça donne ... rien
Car (new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length) est égal à "".
En effet, la chaine passée en paramètre de PEM.readRSAPublicKey(...) est celle lue dans un ByteArray vierge (de longueur 0). Ca ne donne effectivement pas grand chose ^^
Et ça soulève le second problème : l'utilisation du "this._verifyKey", cette propriété de type "Class" qui contient justement la classe AuthentificationManager__verifyKey. Cette classe, qui hérite au second degré de la classe ByteArray, n'apporte rien en plus, ni props, ni méthodes (si l'on s'en tient à sa déclaration)...
Code:
package com.ankamagames.dofus.logic.connection.managers
{
    import mx.core.*;

    public class AuthentificationManager__verifyKey extends ByteArrayAsset {

        public function AuthentificationManager__verifyKey() {
            return;
        }// end function

    }
}
Y aurait-il eu un problème de décompilation ? (sait-on jamais)
Bref, à ce stade, on est sensé avoir une RSAKey de "référence" dans la variable _loc_5. En réalité ce n'est pas la cas, et _loc_5 a la valeur "null" :(

4) "Purification" de la clé "brute"
Code:
            PEM.readRSAPublicKey((new this._verifyKey() as ByteArray).readUTFBytes((new this._verifyKey() as ByteArray).length)).verify(_loc_2, _loc_4, _loc_2.length);
qui aurait dû être (pour justifier la création de la variable temporaire _loc_5) :
Code:
            _loc_5.verify(_loc_2, _loc_4, _loc_2.length);
C'est donc ici, en théorie qu'on décrypte le corps de la clé "brute" (actuellement sous forme d'octets dans le ByteArray _loc_2) pour obtenir un corps de clé décrypté dans le ByteArray _loc_4 (toujours sous forme d'octets). Je parle de "décryptage" car la méthode "verify(...)" fait elle-même appel à la méthode "_decrypt(...) de la classe RSAKey.
La nécessité de décrypter une clé "brute" reçue par le "HelloConnectMessage" pourrait expliquer le fait que la String résultante ait (anormalement ?) gagné en longueur en passant de la 2.8 à la 2.9 (de 396 à 408 : +12 caractères).
Evidemment, puisque _loc_5 (notre RSAKey de référence) est "null", ça plante...
Mais toujours est-t-il qu'à ce moment là, on est sensé avoir _loc_4, un beau ByteArray rempli des octets d'une clé publique utilisable.

5) Finalisation de la publicKey
Code:
            this._publicKey = "-----BEGIN PUBLIC KEY-----\n" + Base64.encodeByteArray(_loc_4) + "-----END PUBLIC KEY-----";
            return;
Dernière étape : à partir de notre corps de clé "décrypté" dans le ByteArray _loc_4, on crée le corps de clé décrypté sous forme de chaine auquel on ajoute le footer ("-----BEGIN PUBLIC KEY-----") et le header ("-----END PUBLIC KEY-----").
On obtient (là c'est encore purement théorique, puisque je ne suis encore jamais parvenu à cette étape) la clé publique : this._publicKey, qui sert à encrypter les données sensibles de la connexion.

6) Conclusion (enfin... ouf !)
Il se peut que certaines parties de cette analyse soient incomplètes ou inexactes étant donné qu'elle sont issues de ma simple interprétation du code que je ne suis pas en mesure de faire tourner correctement.
Alors j'attends vos réactions et vos suggestions.
Et je suis sûr que beaucoup sont concernés par les problèmes que j'ai rencontrés, ou qu'ils ont déjà réussi à les solutionner ou à les contourner.
Tous les membres de ce forum ne bottent pas en MITM, il doit bien rester encore quelques bots socket traditionnels :)
Merci d'avance.

Atlantide-Le-Bavard
 
A

Anonymous

Invité
#11
Re: maj 2.9 : probleme de publicKey

J'en suis au même problème que toi. On pourrais voir ça ensemble sur skype ? Enfin je veux dire en discuter afin de trouver une solution.

Edit: Sais-tu ce que sont que : %, ++, ?, |, :, et tout les autres qui leur ressemble ? Je code en et j'ai du mal à comprendre ça. J'ai chercher un peu sur google mais rien.

Je ne comprend pas aussi ça :

Code:
Private _verifyKey As Class
 
Inscrit
29 Septembre 2011
Messages
393
Reactions
3
#12
Re: maj 2.9 : probleme de publicKey

Jilakin a dit:
J'en suis au même problème que toi. On pourrais voir ça ensemble sur skype ? Enfin je veux dire en discuter afin de trouver une solution.
Edit: Sais-tu ce que sont que : %, ++, ?, |
Si je me trompe pas c'est des Opérateur :

% = modulo et le reste d'une division.

++ = Augmente d'une unité la variable ( exemple Dim x as Integer = 0) { x++} resultat x = 1

{ Ma source pour ci-dessous = http://www.commentcamarche.net/contents/cpp/cppop.php3 }
| = Retourne 1 si l'un ou l'autre des deux bits de même poids est à 1 (ou les deux)

Cordialement tifoux.
 
A

Anonymous

Invité
#13
Re: maj 2.9 : probleme de publicKey

Jilakin a dit:
J'en suis au même problème que toi. On pourrais voir ça ensemble sur skype ? Enfin je veux dire en discuter afin de trouver une solution.

Edit: Sais-tu ce que sont que : %, ++, ?, |, :, et tout les autres qui leur ressemble ? Je code en et j'ai du mal à comprendre ça. J'ai chercher un peu sur google mais rien.

Je ne comprend pas aussi ça :

Code:
Private _verifyKey As Class
pour skype je suis ok, mais pour discuter de quelquechose, il faut avoir des pistes, et là je n'en ai vraiment plus aucune...
Sinon, pour les commandes en as3 que tu me demandes :

% : modulo, ça donne le reste entier d'une division : ex. 15 % 6 = 3 (car 15/6 = 2 reste 3)
++ : comme dans tous les langages de prog, ça incrémente de 1 : ex. i++ revient à faire i = i+1
| : le "pipe" est le "ou" logique, et dans les tests, on les met par 2 : ex. if(i<1 || i>5) trace("i est plus petit que 1 ou plus grand que 5");
? et : sont utilisés dans les affectations conditionnelles condensées, c'est à dire que au lieu d'écrire :
Code:
if(toto == 5){
     i = 1;
} else {
     i = 2;
}
tu peux écrire directement :
Code:
i = toto == 5 ? 1 : 2;
sinon, pour ça :
Code:
Private _verifyKey As Class
ce code n'est pas de l'as3
Dans AuthentificationManager.as, _verifyKey est déclarée comme ça :
Code:
private var _verifyKey:Class;
là on déclare une variable privée qui contiendra la référence à une classe au lieu d'un int ou d'une String...
ça permet ensuite d'instancier par exemple une classe sans vraiment savoir laquelle c'est :
Code:
this._verifyKey = AuthentificationManager__verifyKey;
var _loc_1 = new this._verifyKey();
revient au même que si on fait :
Code:
var _loc_1 = new AuthentificationManager__verifyKey();
Atlantide
 
A

Anonymous

Invité
#14
Re: maj 2.9 : probleme de publicKey

bouh2 a dit:
Je n'ai pas exploré completement le problème mais il est possible que les BigInteger contenu dans la clé (voir le fonctionnement du cryptage RSA) soit encodé en big endian et pas en little endian, d'ou le problème.

Ce n'est qu'une hypothèse
bouh2, j'ai testé ton hypothèse. Par défaut, un byteArray as3 est bigEndian.
J'ai passé en littleEndian le byteArray _loc_2 dans lequel on a inséré les 305 int du vecteur "key" (issu de HelloConnectMessage) pour que le Base64.encodeByteArray le traite en tant que littleEndian.
J'ai aussi supprimé la vérif de la clé pour utiliser directement la séquence reçue (comme dans la 2.8)

Code:
                            public function setPublicKey(param1:Vector.<int>) : void {
			var _loc_2:ByteArray = new ByteArray();
			var _loc_3:int = 0;
			while (_loc_3 < param1.length){
				
				_loc_2.writeByte(param1[_loc_3]);
				_loc_3++;
			}
			_loc_2.position = 0;
			_loc_2.endian = Endian.LITTLE_ENDIAN;
			this._publicKey = "-----BEGIN PUBLIC KEY-----" + Base64.encodeByteArray(_loc_2) + "-----END PUBLIC KEY-----";
			
			return;
		}// end function
Je ne sais pas si c'est ce à quoi tu pensais dans ta réponse, mais la _publicKey résultante est la même que si je laisse en bigEndian.
J'ai peut-être pas fait exactement ce qu'il fallait, mais je ne suis pas expert dans la compréhension et la manipulation des données binaires :(

Atlantide
 
A

Anonymous

Invité
#15
Re: maj 2.9 : probleme de publicKey

Merci pour vos réponses elles vont beaucoup m'aider. J'en ai rencontré d'autres comme : ==, >>>, >>, <<, <<<, !=, ByteArray, Array. Si vous pouviez m'accorder un peu d'aide s'il vous plaît. En particulier sur le ByteArray et le Array que je ne trouve aucunes correspondances en VB.
 
A

Anonymous

Invité
#16
Re: maj 2.9 : probleme de publicKey

Array c'est un tableau.

Pour ce qui est de '<<<', je me pose aussi la même question, première fois que je vois cela.
 
A

Anonymous

Invité
#17
Re: maj 2.9 : probleme de publicKey

Jilakin a dit:
Merci pour vos réponses elles vont beaucoup m'aider. J'en ai rencontré d'autres comme : ==, >>>, >>, <<, <<<, !=, ByteArray, Array. Si vous pouviez m'accorder un peu d'aide s'il vous plaît. En particulier sur le ByteArray et le Array que je ne trouve aucunes correspondances en VB.
Jilakin, crée un nouveau post pour les correspondances as3 / vb et je te répondrai volontiers, parce que celui-ci est plutôt dédié à tout ce qui peut aider à recréer la connexion :)

... et tant qu'on y est :
<< : Décalage gauche au niveau du bit
>> : Décalage droit au niveau du bit
>>> : Décalage droit non signé au niveau du bit
== : Egalité
!= : Inégalité
ByteArray : c'est une sorte de tableau, mais qui contient des données sous forme d'octets, en hexadécimal
 
A

Anonymous

Invité
#18
Re: maj 2.9 : probleme de publicKey

Oui excuse moi je me suis complètement égaré ^^'.
 
A

Anonymous

Invité
#19
Re: maj 2.9 : probleme de publicKey

j'ai trouvé sur le net que l'émetteur de la clé publique pouvait l'accompagner de sa signature électronique, pour garantir qu'un tiers ne vienne pas intercepter le message et interférer entre les deux.

[url:3cvmbw52]http://www.cryptage.org/rsa.html[/url] a dit:
La signature électronique
Après la confidentialité de la transmission d'un message subsiste un problème : son authenticité. Alice voudrait bien envoyer un message M à Bob de telle façon que celui-ci soit sûr qu'elle est réellement l'émettrice du message, et qu'un intrus ne tente pas de venir semer la confusion.
Le système RSA fournit une solution à ce problème :
Rappelons les données :
•Alice seule détient la clé secrète d et diffuse la clé publique (n,e)
•Alice va se servir de la clé publique pour chiffrer le message M

( 1 ) Alice accompagne son message chiffré de sa signature, qui correspond à : M^d
( 2 ) Bob va donc voir si l'égalité (M^d)^e mod n = M est vérifiée. Si c'est le cas, Alice est bien l'émettrice du message.
Le concept est facile à comprendre, mais la mise en oeuvre n'est pas claire du tout :(
ce pourrait-il que notre problème vienne de là ?
et si oui, comment extraire la signature électronique ?
comment retrouver la clé publique ?


Atlantide
 
A

Anonymous

Invité
#20
Re: maj 2.9 : probleme de publicKey

Si j'ai bien compris le d correspond au résultat de (P-1)(Q-1) à la création de la clé privée.
 
Haut Bas