Mar 09/07/2013 - Actualités

Xavier
Administrateur du site
Messages : 817
Enregistré le : mer. 22 juin 2011 18:25

Mar 09/07/2013 - Actualités

Message non lu par Xavier »

Cryptage AES


Le premier dossier a été crypté, ainsi que l'identifiant qu'il contenait.
(Pour le moment le mot de passe est codé en dur dans l'application...)

L'encodage en Base64 fait que le résultat ressemble à un cryptage XT3 (SHA-1 + RC6) mais c'est bien un cryptage XT4 (SHA-512 + AES-256). :)
FirstAES.png
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Denis
Messages : 180
Enregistré le : jeu. 23 juin 2011 09:21

Re: Mar 09/07/2013 - Actualités

Message non lu par Denis »

Tu n'encrypte pas tout le bloc "properties" ou tout le "Text"??? Mais propriété par propriété, et ligne par ligne??? Dommage, non? Au final tu ne décrypte jamais une propriété seule ou une ligne seule? Ca protégerais mieux les données un cryptage du bloc entier??
Xavier
Administrateur du site
Messages : 817
Enregistré le : mer. 22 juin 2011 18:25

Re: Mar 09/07/2013 - Actualités

Message non lu par Xavier »

DMo a écrit :Tu n'encrypte pas tout le bloc "properties" ou tout le "Text"??? Mais propriété par propriété, et ligne par ligne??? Dommage, non? Au final tu ne décrypte jamais une propriété seule ou une ligne seule? Ca protégerais mieux les données un cryptage du bloc entier??
Si, les Properties et Text sont traités chacun en tant que StringList, comme dans XT3.
Ce service de cryptage pour les listes initialise le crypteur une seule fois, puis crypte chaque ligne à la suite.
Si tu as 10 lignes identiques, le résultat crypté sera 10 lignes différentes, puisque chaque ligne "suivante" bénéficie de l'état "déjà utilisé" du crypteur.
Si je cryptais les 10 lignes identiques avec le service réservé aux chaines, le crypteur serait réinitialisé pour chaque ligne et le résultat serait 10 lignes cryptées identiques.

C'est pour cela que je ne peux pas décrypter la 5ème ligne seulement, car elle a été cryptée en fonction des 4 premières.
Mon Prop.Get fait donc un décryptage/recryptage complet :

Code : Tout sélectionner

//------------------------------------------------------------------------------
// XT400 / GetProp - Retourne la valeur d'une Property
//------------------------------------------------------------------------------
function TData.GetSProp(Prop: String): String;
begin
	// Décryptage si besoin
	if	Self.Encrypted
	then	XSL_Crypt(Self.Properties, False);

	// Récupération de la Property
	Result := Self.Properties.Values[Prop];

	// Recryptage si besoin
	if	Self.Encrypted
	then	XSL_Crypt(Self.Properties, True);
end;

//------------------------------------------------------------------------------
Denis
Messages : 180
Enregistré le : jeu. 23 juin 2011 09:21

Re: Mar 09/07/2013 - Actualités

Message non lu par Denis »

ok, du coup, quel interet de conserver les balises pour chaque property / line??? Ne peux-tu pas crypter tout le bloc sous "Properties" et "Text", balises incluses? EN écrivant cela, je m'interroge sur l'intéret réel de ma demande ;-)
Xavier
Administrateur du site
Messages : 817
Enregistré le : mer. 22 juin 2011 18:25

Re: Mar 09/07/2013 - Actualités

Message non lu par Xavier »

DMo a écrit :ok, du coup, quel interet de conserver les balises pour chaque property / line??? Ne peux-tu pas crypter tout le bloc sous "Properties" et "Text", balises incluses? EN écrivant cela, je m'interroge sur l'intéret réel de ma demande ;-)
Je n'étais pas sûr ce matin que ta question posait sur ce point.

Sur une donnée en mémoire, j'ai une TStringList, qui est intégralement cryptée et c'est tout. Les balises visibles dans le fichier ne sont bien que l'enveloppe XML qui est rajoutée lors de l'écriture du fichier, elles n'ont aucun besoin d'être cryptées en tant que "conteneurs" de données cryptées.

Je me souviens de ta demande de passer les Properties [A=1] en balise <A>1</A> au lieu de <Prop>A=1</A>.
J'avais refusé car cela aurait cassé ma mécanique qui utilise des Properties [.A=1] écrivables pour debug mais non lues, car cela impliquait l'écriture de balises <.A>1</.A> incompatibles.
Cela aurait demandé un cryptage de la balise et de sa valeur différents du cryptage "interne" de la StringList.
Répondre