CRYPTAGE DECRYPTAGE RSA 32 BITS (C++/MFC)

Commentaire de DeAtHCrAsH le 10/06/2004 09:56:38

Pour info, actuellement les cryptage les plus évolué utilisé en informatique pour le net, sont des clés SSL 128bits.
Récemment, un groupes de chercheurs européen on pu décrypter en 3 mois une clé de 512bits créer par une boite allemande ...

C'est dire si le RSA 32bits est encore très utilisé dans le cryptage de données!

A++ et bonne continuation ...

Samir

Commentaire de BruNews le 11/06/2004 00:20:45 administrateur CS

Kirua > sur win32 int ou long c'est idem 32 bits, que soit signe ou non.

Commentaire de Kirua le 11/06/2004 07:46:26

et les double? c'est sur 32 ou 64 bits? parce que sinon je vois pas la différence avec un float ...

Commentaire de BruNews le 11/06/2004 09:32:45 administrateur CS

float : 32 bits
double : 64 bits par defaut au niveau du C (80 en interne).

Commentaire de cosmobob le 11/06/2004 17:04:36

la clé publique est par nature connue de tous. seule la clef secrete est cachée...

Commentaire de newic500 le 13/06/2004 16:16:04

Le cahier des charges de mon projet stipulait des petits nombres, mais j'ai voulu mettre du beurre dans mes epinards en faisant des grands nombres.
J'ai testé deux classes sur CPPFrance gerant les grands nombres
L'une avait un bug à l'affichage (rajouts de 0),...
Une autre fonctionnait bien.... mais pour des petits nombres.  J'ai essayé de faire une puissance modulaire avec des nombres avec une precision superieur à 16 bits, le resultat etait faux :(

Il existe par contre des bibliotheques GNU qui gerent parfaitement les grands nombres (je m'excuse, je ne me souviens plus de leurs noms), et qui sont de plus tres rapides (car comportant des portions en assembleur).
Par contre elles sont plus lourdes a mettre en place qu'une classe...

Commentaire de Kirua le 26/02/2005 22:27:05

Je relis à l'instant votre rapport (devant moi aussi réaliser un travail sur RSA) et je constate ceci:

"Cette fonction prend en entrée le nombre à tester ainsi qu’une variable devant stocké le nombre de division nécessaire pour déterminer si le nombre à tester est premier. Elle renvoie ensuite 0 ou 1 selon que le nombre est déterminé premier ou non.
Le principe est le suivant : on prend la racine du nombre à tester, puis on effectue un modulo de cette racine par 1, 3, 5, etc. jusqu’à ce que l’on atteigne la racine ou bien que le n du mod n soit inférieur au dernier résultat obtenu. Des que le modulo vaut 0, la condition n’est plus remplie et on sort de la boucle, du coup on renvoie la dernière valeur trouvée qui indique si il y a eu un diviseur trouvé."

En réalité, il ne faut diviser que par les nombres premiers de 1 à la racine carrées du nombre, or le nombre en question est compris entre 0 et 2^32-1, sa racine carrée vaut donc 65535 au maximum, ce qui fait que tu ne dois générer les nombres premiers que de 1 à 65535. Avec l'algorithme d'Eratosthène bien optimisé, cela prend un temps trop petit pour être calculé ... ça vaut le coup, non? :)

Commentaire de SilverEleven le 25/03/2005 22:53:36

J'aime beaucoup la manière dont vous transcoder une chaîne de caractère en un nombre :D.

Je cite : "Ensuite, la fonction découpe par groupe de 3 chiffres en partant par la fin le nombre décrypté. Ce groupe de 3 chiffres représente la valeur ASCII d’un caractère."

Donc, sois la chaîne de caractère "ABC" dont les valeurs ASCII sont 65 66 67. Le nombre représenté sera donc 065066067. Hum, ça fait peur.

Faut pas réfléchir en décimal, mais dans une autre base. Pourquoi ne pas avoir utiliser l'octal ou l'héxadécimal, voir même une base de 2^8 pour transcoder une chaîne de caractère en un nombre. Parce que sincèrement, la méthode que vous utilisez est très (très) mauvaise, d'autant plus que vous perdez énormément de place. A la place d'avoir un nombre de (65066067) 8 chiffres, avec une base de 256, j'ai 4276803 soit 7 chiffres. Certes ce n'est pas beaucoup à cette échelle, mais allez travailler avec des mégas :).

J'avoue que lors de la première lecture, j'ai été tellement surpris que je me suis dit que c'était moi qui avait mal compris : c'était tellement gros. Mais non, c'est bien une erreur.

Commentaire de newic500 le 10/06/2005 15:00:51

Oui, c'est juste une question d'affichage (on utilise pas de DCB).

Commentaire de dtcube le 15/11/2005 15:41:28

Comparer des clefs ssl 128 bits et des clefs rsa est un non sens. SSL concerne le chiffrement symetrique, RSA est un chiffrement asymetrique.

Pour faire simple, dans le cadre symetrique le secret --appele la clef secrete-- sert a CHIFFRER (et non crypter qui n'est pas francais) et a DECHIFFRER (et non decrypter qui a un autre sens). Dans le cadre asymetrique, deux clefs existent, une publique l'autre privee. La publique sert a CHIFFRER et la privee a DECHIFFRER. Comme les noms l'indique : seule la clef privee doit etre secrete.

Quoi qu'il en soit RSA avec des entiers de 32 bits ne peut avoir qu'une utilie pedagogique. Precisons qu'il y a egalement une difference entre le principe implemente ici et un <<vrai>> systeme utilisant ce principe tel qu'on peut le trouver dans OAEP par exemple.

Pour conclure je conseile : http://fr.wikipedia.org/wiki/Portail:Cryptologie .
Notamment :
http://fr.wikipedia.org/wiki/Cryptographie_asymétrique
et
http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman

Dtcube

Commentaire de dtcube le 17/11/2005 11:19:30

Helas, non Teletubiz. C'est un non sens. Puisqu'il faut etre technique soit : pour les chiffrements symetriques, le nombre de bits de la clef mesure exactement le nombre de clefs possible, e.g. 128 -> 2^128 clefs. Pour les algo asymetriques ce n'est plus le cas. Dire que RSA a une clef de 1024 bits ne signifie par qu'on a choisi une clef parmi 2^1024. Cela serait de toute facon une inepsie. Conclusion : la taille de la clef n'a pas la meme signification. Corolaire : comparer les tailles entre algo symetrique et asymetrique n'a pas de sens. cdfq.

Une autre maniere de presenter les choses est la suivante : sur un algo symetrique, la methode la plus bete possible, l'attaque par force brute, demande effectivement de tester 2^128 clefs. Pour un algo asymetrique, on ne peut pas essayer toutes les clefs de 2^1024 bits puisque certaines ne sont pas valable (e.g. dans le cas de RSA pas un produit de nombre premier). L'attaque par force brute, dans le sens essai de toutes les clefs valables, n'est plus directement la taille de la clef