Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

implémentation de DIFFIE-HELLMAN

3 réponses
Avatar
nomail
Bonsoir à tous,
Je voudrais soumettre un petit bout de code pour avoir votre avis sur
mon implementation ainsi que pour savoir si l'implementation vous semble
suffisament sure.

Dans mon code j'ai tenté de résoudre le problème lié aux grands nombres.
Pour memoire la methode est la suivante :

A et B souhaitent s'echanges des données
A génére un nombre x et calcule X = (g^x) modulo p
B génére un nombre y et calcule Y = (g^y) modulo p
A et B s'echyangent leur X et Y respectifs
et calculent k = (X^y)modulo p = (Y^x) modulo p

J'ai donc procedé par génération de n k de petite taille (3 bit) affin
de pouvoir calculer leur puissance à l'interieur d'un entier.
chaque k est par la suite ramené à 2 bit K%4 afin de constituer des
blocs de 2 bits.

Si vous avez comprit, ceci signifie que pour une clef d'echange K de
longeur 56 bits (DES) il me faut générer 28 clefs k

Voici le code, je vous prie de ne pas tenir compte :
- Du random, j'ai pris ici le bête random du c
- De l'affichage un peut ésothérique

Merci de vos commentaires.
- Fato
fatoReMoVeThIs@free.fr
fatoAefFaCeR@free.fr

/**********************************************************************/
#include <memory.h>
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <math.h>


#define g 7
#define n 5
#define KEYLEN 28



int BuildMatrix()
{


unsigned int X,Y,x,y;
int c;

int Matrixx[KEYLEN];
int MatrixX[KEYLEN];
int Matrixy[KEYLEN];
int MatrixY[KEYLEN];
int MatrixK[KEYLEN];

x = 0;

// Clear the buffers
//******************
memset((void *)&Matrixx,0,KEYLEN);
memset((void *)&MatrixX,0,KEYLEN);
memset((void *)&Matrixy,0,KEYLEN);
memset((void *)&MatrixY,0,KEYLEN);
memset((void *)&MatrixK,0,KEYLEN);

// Generate the x,y,X,Y matrix
//*****************************
for(c = 0;c<KEYLEN;c++)
{

// Take x and y 2 random numbers between 0 and 12
//*************************************************
x = rand()%12;
y = rand()%12;

// Calculate X and Y
//********************************
X = ((unsigned int)pow(g,x))%n;
Y = ((unsigned int)pow(g,y))%n;

// Fill the matrix
//******************
Matrixx[c] = x;
MatrixX[c] = X;
Matrixy[c] = y;
MatrixY[c] = Y;

// Calculate the shared key matrix
//*************************************
MatrixK[c] = ((unsigned int)pow(Y,x))%n;
}

// DISPLAY THE X KEY MATRIX
//********************************
printf("\n X = 0x");
for(c = 1;c<KEYLEN;c++)
{
x = MatrixX[c];
printf("%0X",x);
}
printf("\n Y = 0x");

// DISPLAY THE Y KEY MATRIX
//********************************
for(c = 1;c<KEYLEN;c = c++)
{
x = MatrixY[c];
printf("%0X",x);
}
printf("\n K = 0x");

// DISPLAY THE COMPUTED EXCHANGE KEY
//************************************************
for(c = 1;c<KEYLEN;c = c+2)
{
x = (MatrixK[c]%4) + ((MatrixK[c-1]%4)<<2);
printf("%X",x);
}
printf("\n");
return 0;
}



int main()
{
int ct = 0;
srand( (unsigned)time( NULL ) );

while(getc(stdin) != 'q')
{
BuildMatrix();
printf("\nPress 'q' to quit or another key to continue :");
}

return 0;
}

3 réponses

Avatar
Laurent Fousse
Dans fr.misc.cryptologie, nous disait:
Bonsoir à tous,
Je voudrais soumettre un petit bout de code pour avoir votre avis sur
mon implementation ainsi que pour savoir si l'implementation vous semble
suffisament sure.


Ma réponse est non. Le problème de Diffie-Hellman devient trivial si
le problème du log discret est facile, or dans ton implémentation il
l'est (à en juger par les déclarations en début de code et la taille
de tes nombres).

Quand on convient d'un premier p et d'un nombre g, on veut que le
sous-groupe généré par g soit suffisamment grand dans Fp pour que le
problème du log discret (trouver x connaissant y = g^x mod p) soit
difficile.

Résoudre le problème des grands nombres en décomposant le nombre en
une liste de petits nombres est une mauvaise solution car tu as
transformé un problème de grande taille que l'on juge difficile en une
multitudes de problèmes de taille nettement plus petite et donc
triviaux. En tout cas c'est ce que j'ai cru comprendre du code.

La bonne façon de traiter les problèmes de grands nombres en C est
d'utiliser une bibliothèque performante déjà écrite : je te conseille
de regarder du côté de gmp (http://swox.com/gmp/).

Avatar
ultrix
From Fato
----------
En fait si j'ai bien compris ton explication
l'emploi de petites valuers pour x dans X = (g^x)modulo p
facilite grandement une ataque car pour quelqu'un connaissant
q et p et X - ce qui est probable - car le nombre limité de x
rend la deduction d'un petit nombre de x donc de clefs K
et d'une attaque par force brute.

si 0 <= x < 30 et p = 5 il y a donc pour un X donné environs
(5.8 majoré) 6 x possibles et ramene le nombre de solutions
à 6^26 clefs possibles ce qui est égal à 170581728179578208256
clés ce qui ne garantir pas une bonne sécurité.

Donc, si je comprends bien une bonne implémentation de D-H
doit pour un X donné fournur un nombre maximum de x
donc avoir un grand écart entre g et p ou p < g.

Merci pour ta réponse
Fato
----------
Laurent Fousse wrote in message news:...
Dans fr.misc.cryptologie, nous disait:
Bonsoir à tous,
Je voudrais soumettre un petit bout de code pour avoir votre avis sur
mon implementation ainsi que pour savoir si l'implementation vous semble
suffisament sure.


Ma réponse est non. Le problème de Diffie-Hellman devient trivial si
le problème du log discret est facile, or dans ton implémentation il
l'est (à en juger par les déclarations en début de code et la taille
de tes nombres).

Quand on convient d'un premier p et d'un nombre g, on veut que le
sous-groupe généré par g soit suffisamment grand dans Fp pour que le
problème du log discret (trouver x connaissant y = g^x mod p) soit
difficile.

Résoudre le problème des grands nombres en décomposant le nombre en
une liste de petits nombres est une mauvaise solution car tu as
transformé un problème de grande taille que l'on juge difficile en une
multitudes de problèmes de taille nettement plus petite et donc
triviaux. En tout cas c'est ce que j'ai cru comprendre du code.

La bonne façon de traiter les problèmes de grands nombres en C est
d'utiliser une bibliothèque performante déjà écrite : je te conseille
de regarder du côté de gmp (http://swox.com/gmp/).



Avatar
Laurent Fousse
Salut,

Dans fr.misc.cryptologie, ultrix nous disait:
From Fato
----------
En fait si j'ai bien compris ton explication
l'emploi de petites valuers pour x dans X = (g^x)modulo p
facilite grandement une ataque car pour quelqu'un connaissant
q et p et X - ce qui est probable - car le nombre limité de x
rend la deduction d'un petit nombre de x donc de clefs K
et d'une attaque par force brute.


Si g est un générateur de Z/pZ, ce qu'on essaie de faire, alors le
nombre de x possibles c'est p - 1.

si 0 <= x < 30 et p = 5 il y a donc pour un X donné environs
(5.8 majoré) 6 x possibles et ramene le nombre de solutions
à 6^26 clefs possibles ce qui est égal à 170581728179578208256
clés ce qui ne garantir pas une bonne sécurité.


En réalité pour p = 5 il n'y a que 4 possibilités pour X mod p. Et
encore, en supposant que g soit bien choisi.

Donc, si je comprends bien une bonne implémentation de D-H
doit pour un X donné fournur un nombre maximum de x
donc avoir un grand écart entre g et p ou p < g.


Il faut que p soit suffisamment grand, et il faut que l'ordre de g
dans Z/pZ* soit grand (c'est-à-dire le nombre de X possibles).