Discussion :

[ol9245]

Bonjour,

J'ai un problème qui est un cas particulier de cryptage et pour lequel je cherche une solution simple.

J'ai des données (quelques millions) qui sont repérées par des codes en 64 bits.
Je veux un algo simple et rapide qui génère un nombre aléatoire unique à partir de chaque donnée. unique = la même donnée génèrera toujours le même nombre aléatoire.

ce n'est pas pour crypter. je n'ai pas besoin de secret ou quoi que ce soit.

Merci de vos conseils.

PS. comme d'habitude, je préfère un truc tout écrit que me palucher le débogage d'un code original alors que je suis sur qu'il y a plétore de codes disponibles là dessus. simplement, comme je n'y connais pas grand chose en nombre léatoires ou en cryptologie, je ne sais pas où chercher. Le peu que je connais me fait penser qu'un encodage d'il y a 20 ans à base de xor et de bitshift devrait être ce que je cherche ?

[FR119492]

Salut!

Le peu que je connais me fait penser qu'un encodage d'il y a 20 ans à base de xor et de bitshift devrait être ce que je cherche ?

C'est probablement la meilleure solution: tu te donnes une clef Y de 64 bits, la même pour chacune de tes données X.
Jean-Marc Blanc

[ol9245]

merci Jean-Marc,

tu connais des noms d'algo pour que je puisse chercher sur Mathworks ?
J'ai lu un gros pavé de cryptographie il y a longtemps, mais il ne m'en reste rien

PS: à un moment, j'aurais besoin d'inverser mon codage, mais je suppose qu'avec un algo sur étagère, j'aurais les deux : eccryptage et décryptage.

j'ai besoin de ça parceque mes clés sont des clés de position. J'ai besoin de les trier dans un ordre aléatoire et que, quelque soit le sous-ensemble de clé soumis au tri, l'ordre relatif entre elles soit inchangé. d'où l'idée d'utiliser un outil cryptographique.

la question subsidiare : soit x la longueur de du code d'origine, quelle doit être la longueur de sa version cryptée pour que la relation soit univoqye (pas tomber sur le même cryptage pour deux codes différents)

[Dutiona]

Salut,

Il ne s'agit même pas d'algo à ce niveau là, un cryptage xor consiste à appliquer xor sur ses données.

Principe simple :
- choix d'une clé (de même longueur que la donnée à crypter).
- cryptage : valeur_cryptée = valeur_origique XOR clé
- décryptage : valeur_origine = valeur_cryptée XOR clé

C'est un cryptage sûr, je te renvoie à wikipédia ^^

Ce système, bien que très simple dans son principe, peut s'avérer inviolable si la suite de bits de la clé est vraiment aléatoire. Cette dernière ne doit en outre être utilisée qu'une seule fois (on parle de masque jetable, ou encore de «one-time pad»). Dans cette phrase, c'est surtout le mot «aléatoire» qui s'avère être le plus difficile à mettre en œuvre. Mais lorsque la clé est vraiment aléatoire --- techniquement, qu'elle est tirée selon la distribution uniforme parmi toutes les suites possibles de cette longueur --- ce système est parfaitement sûr, en un sens rigoureusement défini par Claude Shannon, en 1949, dans un article fondateur «Communications theory of secrecy systems». Il convient d'ajouter que c'est le seul chiffrement aboutissant à une sécurité absolue, en théorie.

Ca donne ça en php par exemple (sur 4 bit) :

Code php :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
$arr = array(0xF, 0x1, 0x5);
$k = 0xA;
 
echo '--Cryptage';
//Cryptage
foreach($arr as $v){
	printf("%04b, 0x%s \n", $v^$k, dechex($v^$k));
}
 
echo '--Décryptage';
//Decryptage
foreach($arr as $v){
	$original = ($v^$k)^$k;
	printf("%04b, 0x%s \n", $original, dechex($original));
}

Ca t'affiche :

Code :

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

1
2
3
4
5
6
7
8
9
 
-- Cryptage
0101, 0x5
1011, 0xb
1111, 0xf
-- Décryptage
1111, 0xf
0001, 0x1
0101, 0x5

[dividee]

Utiliser xor est certainement le plus simple, mais beaucoup de codes proches au départ resteront proches à l'arrivée (si seuls quelques bits de poids faibles changent).

Un algo de chiffrement par bloc (en mode ECB, pour coder un stream de codes directement) devrait donner des résultats plus "aléatoires". DES utilise des blocs de 64 bits et il devrait être facile de trouver une librairie qui l'implémente quel que soit le langage de programmation utilisé.

la question subsidiare : soit x la longueur de du code d'origine, quelle doit être la longueur de sa version cryptée pour que la relation soit univoqye (pas tomber sur le même cryptage pour deux codes différents)

J'ai peut-être mal compris la question, mais il me semble trivial que la longueur minimale est x. S'il faut pouvoir représenter 2^x valeurs, il faut au minimum x bits, quel que soit le codage utilisé.

[ol9245]

Utiliser xor est certainement le plus simple, mais beaucoup de codes proches au départ resteront proches à l'arrivée (si seuls quelques bits de poids faibles changent).

Un algo de chiffrement par bloc (en mode ECB, pour coder un stream de codes directement) devrait donner des résultats plus "aléatoires". DES utilise des blocs de 64 bits et il devrait être facile de trouver une librairie qui l'implémente quel que soit le langage de programmation utilisé.



J'ai peut-être mal compris la question, mais il me semble trivial que la longueur minimale est x. S'il faut pouvoir représenter 2^x valeurs, il faut au minimum x bits, quel que soit le codage utilisé.

Merci à tous de votre passage sur mon fil.

en effet, avec un xor simple, les bits de poids fort seront toujours ceux de la clé. donc le côté aléatoire ne sera pas obtenu.
Pour la question du minimum, je conçois bien ta remarque. Je me demandais simplement si le résultat crypté ne doit pas être plus long que la donnée d'origine et s oui, de combien.