Faire un XOR sur une chaine/long binaire TRES/TROP longue

**bobic** · 29/08/2011, 11h02

Bonjour,

J'ai un petit problème avec l'utilisation d'un XOR.

En effet, j'ai deux String qui représentent en réalité chacun un code héxadécimal (mais bon.. qu'importe), et je dois faire un XOR entre ces deux chaines.
Ma première chaine est la suivante:
String o1 = "63cc5fb23fbc4de060e38437898de623"
Ma seconde: String d2 = "673000114F38fc00"

J'ai lu que pour faire le XOR il fallait au préalable convertir la chaine en un String de binaire, puis la parser en tant que Long et faire ensuite le XOR.
Ainsi, cela donne le code suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
//Conversion de o1 en binaire
StringBuffer buffo1 = new StringBuffer();
   for (int i = 0; i < o1.length(); i++) {
	buffo1.append(StringUtils.leftPad(Integer.toBinaryString(Integer
	.parseInt(String.valueOf(o1.charAt(i)), 16)), 4,
	"0"));
   }
 
StringBuffer buffd2 = new StringBuffer();
   for (int i = 0; i < d2.length(); i++) {
	buffd2.append(StringUtils.leftPad(Integer.toBinaryString(Integer
	.parseInt(String.valueOf(d2.charAt(i)), 16)), 4,
	"0"));
   }

J'ai donc bien deux buffers contenant ma chaine représentée en binaire

Il ne me reste ainsi qu'à faire le XOR dessus:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
long lbuf2 = Long.parseLong(buffd2.toString(), 2);
long lbuffo1 = Long.parseLong(buffo1.toString(), 2);
 
long resultXOR = lbuf2 ^ lbuffo1;

Le problème c'est que lors du parseLong de mon buffer de mon premier String, celui-ci étant trop long, cela plante...

java.lang.NumberFormatException: For input string: "01100011110011000101111110110010001111111011110001001101111000000110000011100011100001000011011110001001100011011110011000100011"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Long.parseLong(Unknown Source)

Alors du coup, comment puis-je faire ??

Je ne sais vers quoi partir, je suis un peu dans la panade

Réaliser ce genre de chose n'est pas habituel pour moi, et du coup, je galère un peu là

Je vous remercie tous pour votre aide

**Jimmy_** · 29/08/2011, 11h22

Bonjour,

Que ce soit short, int ou long, ca ne change rien : la taille est limité, il faut découper ton String et procéder par bloc.

Bon courage,

**tchize_** · 29/08/2011, 11h40

c'est quoi ces bidouilles avec les stringbuffers? Je comprend même pas ce qu'est censé faire ce code

Ceci devrait suffire, en utilisant des BigInteger vu la taille de vos données:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
		String o1 = "63cc5fb23fbc4de060e38437898de623";
		String d2 = "673000114F38fc00";
		BigInteger l1 = new BigInteger(o1,16);
		BigInteger l2 = new BigInteger(d2,16);
		BigInteger resultat = l1.xor(l2);
		System.out.println(resultat.toString(16));

**bobic** · 29/08/2011, 11h40

slt,

Je ne suis pas contre le couper, mais par rapport à mon XOR, comment faire pour que le résultat soit correct ?

Je ne suis pas à l'aise avec ce genre de choses

Comment dois je donc faire pour faire bit à bit par exemple, avec un résultat valide ?

**bobic** · 29/08/2011, 11h42

Merci tchize_, j'essaie ça !

L'histoire des buffers, c'est clair c'est des bidouilles pourries, des compilations de bouts de code...

**Jimmy_** · 29/08/2011, 11h47

On dirait que tu veux faire du padding à gauche en fonction de la taille de tes Strings. Il y a une raison ?
Quoi qu'il en soit prend le type qui convient a ton traitement.

**thelvin** · 29/08/2011, 11h53

Il y a quand même un petit problème, c'est que les deux chaînes ne contiennent pas le même nombre de chiffres. Comment on fait un xor entre deux séries de bits de longueurs différentes ??

**bobic** · 29/08/2011, 11h59

tchize_, ça marche impec ! Merci
Jimmy_ non le padding ne sert à rien ici. C'est juste que je l'ai récupéré sur une autre fonction

thelvin: En effet, c'était une question que je gardais pour la fin

En fait, je dois suivre un algo bien défini. En gros, un première chaine passe dans un DES , et on fait un XOR sur le résultat de ce DES et la troisième chaine.
Le prob est que le résultat du DES est bien plus long que ma troisième chaine...

**thelvin** · 29/08/2011, 12h13

Envoyé par bobic

thelvin: En effet, c'était une question que je gardais pour la fin

Ben... On va pas le dire à ta place -_-°. Un xor, ça se fait entre séries de bits de même longueur, point final.

Maintenant, bon, vu que tu nous parles d'une histoire de DES, je me dis que cette "troisième chaîne" est une fait une clé qu'on doit utiliser pour faire un xor sur le résultat de la première.
Un truc commun, avec les clés, c'est de les répéter en boucle jusqu'à faire la même taille que le contenu sur lequel faire un xor. Mais bon, c'est peut-être pas ton cas, j'en sais rien.

**tchize_** · 29/08/2011, 12h24

Hou, un vieux DES et un XOR de derrière les fagots, ça sent l'algo cryptographique foireux quelque part

En ce qui me concerne, j'avais juste supposé qu'il y avait des zeros devant. Si tu dois répéter la partie courte, regarde dans l'algo "que tu dois suivre" comment ça se passe

**bobic** · 29/08/2011, 12h32

Envoyé par tchize_

Hou, un vieux DES et un XOR de derrière les fagots, ça sent l'algo cryptographique foireux quelque part

En ce qui me concerne, j'avais juste supposé qu'il y avait des zeros devant. Si tu dois répéter la partie courte, regarde dans l'algo "que tu dois suivre" comment ça se passe

Je vois que tu connais ça ^^
En fait, mon problème c'est que j'ai juste une donc technique, avec le schémas
http://www.uv.es/fsoriano/efc/cardme.pdf page 106

Mais je n'ai pas trouvé plus d'infos pour le moment pour savoir comment ce problème est géré

**tchize_** · 29/08/2011, 13h23

Envoyé par bobic

Je vois que tu connais ça ^^

C'est juste qu'en général ça sent la bidouille pas très réfléchis quand on rajoute une couche d'encryption au dessus d'une autre.

**Jimmy_** · 29/08/2011, 13h40

A ok c'est du chiffrement par bloc, tu as donc 3 DES et tu fais un Xor entre chaque. Du grand classique.
Fallait le dire plus tôt.

un vieux DES et un XOR de derrière les fagots, ça sent l'algo cryptographique foireux quelque part

Non pas foireux, c'est du tripleDES, un peu obsolète, mais encore utilisé.
Tu enchaines 3 algos DES. L'avantage c'est que ça reste compatible avec du DES simple si tu utilises la même clé.

Donc c'est un découpage en bloc de 64 bits exactement qu'il te faut faire.
Un long convient parfaitement puisque c'est codé sur 64 bits. Ca tombe bien...

C'est quoi le but au final ?

**Jimmy_** · 29/08/2011, 14h22

Envoyé par bobic

/fsoriano/efc/cardme.pdf[/URL] page 106

C'est pas ben compliqué en fait.

Tu as 2 clés maitresses , une pour les émeteurs et une pour les opérateurs.

A l'aide de leur caractéristiques propres (numéro de compte, date etc ...)
Le système calcule une clé spécifique en faisant passer un tripleDES en mode EDE (Encrypt, Decrypt, Encrypt).
Cela donne 2 clés de 8 octets.

Puis après il t'explique qu'ils découpent la chaine à chiffrer (M) en 3 blocs de 8 octets :
D1 = I1 = Sub(M, 0, 8) = "01 20 40 52 75 12 34 56"
D2 = Sub(M, 8, 8) = "78 90 12 FF FF 21 21 00"
D3 = Sub(M, 16, 8) = "00 04 1A 61 A9 85 00 00"

Comme le schéma le montre il fond un tripleDES en mode EEE avec la même clé, pour obtenir le résultat.

Ce système basé sur DES est complètement obsolète, cela dit en passant...

Pour ton problème, oublie les Strings, tu as du Binaire de bout en bout.

Bon courage,

**bobic** · 29/08/2011, 14h41

Je suis content de voir que ça gère bien ici !

Bon ben, je vais un peu bosser sur le sujet, et je reviendrai sur ce topic si j'ai un prob

En tout cas, merci beaucoup à vous !!

**tchize_** · 29/08/2011, 14h44

Envoyé par Jimmy_

Non pas foireux, c'est du tripleDES, un peu obsolète, mais encore utilisé.

J'ai pas dis le contraire, sauf qu'en général dans ce cas on appelle directement les routines triple DES on essaie pas de faire ça "à la main" quand java fournis déjà tous les nécessaire. Ma réaction était plutot par rapport à utiliser un truc obsolète (le DES simple) couplé à un XOR sorti d'on ne sais où

**Jimmy_** · 29/08/2011, 15h08

Oui c'est effectivement un peu surprenant leur truc de tripeDES en mode EEE avec la même clé. On peut le voir comme ça.

Ca ressemble plus a une fonction de Hashage comme utilisation dans leur document. Puisque après ils vérifient l'authentification avec ça. Mais comme c'est de l'embarqué ils sont peut-être limité en terme d'algo, ils n'ont peut-être qu'un DES simple déjà câblé en hard, à disposition. Je ne connais pas les détails de leur implémentation.

**tchize_** · 29/08/2011, 15h23

page 106:
"Compute the Issuer Authenticator (Auth_Iss) according to the DES algorithm ISO 8731-1"

Définition de ISO 8731/1
en sigl.
Il s'agit d'une tentative faite par l'ISO pour définir un standard d'algorithme de chiffrement DES à un niveau internationnal (et pas seulement sur un plan américain comme c'est le cas avec l'ANSI). Appelé DEA-1, il devait servir de base pour faire évoluer le standard dans le futur. Malgré cela, l'algorithme défini par l'ISO 8731/1 n'a jamais été approuvé et c'est l'ANSI X3.92 qui fait référence.

Je le dit, ça sent pas bon

Blague à part, pour plus de détails, il y a de fortes chances que tu doive te procurer cet iso 8731/1

mais le problème c'est que, comme indiqué ici
http://www.iso.org/iso/fr/catalogue_...csnumber=16137

État: Annulee

Je ne suis même pas sur qu'un document officiel existe. En plus 1987, tu va galérer pour en trouver une copie.

maintenant, si je suis le document que tu donne, O1 et D2 doivent avoir le même nombres de bits. Si ce n'est pas le cas, c'est que t'as commis déjà une erreur à la génération de O1.

**Jimmy_** · 29/08/2011, 15h31

Parfaitement abandonné au profit de l'algorithme AES il y a bien longtemps (2001).

Comme dit depuis le début, DES est obsolète.

Aujourd'hui sur une carte graphique programmé en CUDA, une clé DES, qui n'a que 56bits en réalité, se casse très vite.

Ils ont peut-être pensé à l'époque que DES était suffisant pour ce genre de carte de péage. Et que personne n'emporte avec lui de quoi casser les clés DES dans sa voiture