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

cs_Stormy Messages postés 255 Date d'inscription samedi 20 avril 2002 Statut Membre Dernière intervention 16 janvier 2007 - 9 juin 2004 à 22:11
mimimi21 Messages postés 1 Date d'inscription lundi 27 avril 2009 Statut Membre Dernière intervention 9 mai 2009 - 9 mai 2009 à 20:52
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/23557-cryptage-decryptage-rsa-32-bits-c-mfc

mimimi21 Messages postés 1 Date d'inscription lundi 27 avril 2009 Statut Membre Dernière intervention 9 mai 2009
9 mai 2009 à 20:52
j ai telecharger le ZIP mais je ne sais pas comment l executer avec le DEV-C++
pouvez vous m aider svp?
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
18 nov. 2005 à 19:43
un éclaircissement bien utile, merci :)
dtcube Messages postés 2 Date d'inscription mardi 15 novembre 2005 Statut Membre Dernière intervention 17 novembre 2005
17 nov. 2005 à 11:19
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
Utilisateur anonyme
15 nov. 2005 à 18:20
Non, ca n'est certainement pas un non sens. C'est comme ca que l'on mesure la puissance d'un codage(*). En fait, on calcul seulement le temps nécessaire au cassage en force brute. Pour cela, on suppose (ou vérifie, c'est au choix) que l'algorithme est sûr (ie: il n'existe pas ou très peu d'algorithmes permettant de raccourcir le calcul).

Sinon, tout à fait d'accord: WikiPedia propose un très bon portail de cryptologie (peut être pas aussi complet que d'autres ressources, mais c'est lui qui en concentre le plus).
Dommage qu'il manque parfois tout les aspects mathématiques derrière.
dtcube Messages postés 2 Date d'inscription mardi 15 novembre 2005 Statut Membre Dernière intervention 17 novembre 2005
15 nov. 2005 à 15:41
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
clem0338 Messages postés 65 Date d'inscription mercredi 19 juin 2002 Statut Membre Dernière intervention 9 mars 2008
3 août 2005 à 11:32
Je viens de télecharger le prog, jusqu'a la pas de probleme, très bien fais (j'irai même jusqu'à dire que ca fais pro :) ). Bonne continuation @+

J'enverrais les critiques plus tard ...... si le coeur m'en dit.

@+
newic500 Messages postés 6 Date d'inscription vendredi 26 mars 2004 Statut Membre Dernière intervention 10 juin 2005
10 juin 2005 à 15:00
Oui, c'est juste une question d'affichage (on utilise pas de DCB).
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
25 mars 2005 à 23:09
C'est juste une question d'affichage, le programme travaille sur les valeurs binaires, non?
SilverEleven Messages postés 3 Date d'inscription dimanche 23 mars 2003 Statut Membre Dernière intervention 25 mars 2005
25 mars 2005 à 22:53
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.
Utilisateur anonyme
26 févr. 2005 à 22:54
Pas maaaaaaaaal !!!
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
26 févr. 2005 à 22:27
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? :)
cs_rob85 Messages postés 16 Date d'inscription samedi 7 février 2004 Statut Membre Dernière intervention 29 octobre 2006
26 févr. 2005 à 03:26
génial ! on voit qu'il y a eu du boulot et j'en remercie les auteurs !

@+ Rob
newic500 Messages postés 6 Date d'inscription vendredi 26 mars 2004 Statut Membre Dernière intervention 10 juin 2005
13 juin 2004 à 16:16
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...
Utilisateur anonyme
13 juin 2004 à 16:01
Effectivement sous VC il existe les __int64 qui sont des ENTIERS de 64 bits. Les doubles ne sont pas utilisables car imprécis.
Le mieux est d'utiliser un objet BigInt (une classe peut être trouvée sur CPPFrance elle permet d'utiliser des nombres d'une taille illimitée (sauf qd y'a plus de mem), de faire les opérations classiques (+ - / * affectation, décalage des bits, exponentielle modulaire, et contient un générateur aléatoire).

Enfin, précisons que l'utilisation de RSA est soumise à certaines règles. Il existe une faille connue dans RSA qui permet de décrypter un message sans passer par le cassage de la clé.
Les détails ici: http://www.bibmath.net/crypto/chasseur/erreurrsa.php3

Enfin, une puissance de 2048 bits est censé tenir jusqu'en 2059 selon les lois de croissance de la puissance de l'informatique (privée et publique).

Je conseil ce site http://www.bibmath.net/crypto/ pour tous ceux qui veulent en savoir plus sur la crypto: crypto, arithmétique, hachage, discussion, stégano, histoires; mais aussi de nombreuses connaissances pour comprendre ce que signifie 2048 bits et comment calcul t-on cette puissance sosu différent algorithme. De plus, pour ceux qui font des maths, il y'a une partie appronfondie de théorie et des nouvelles méthodes: factorisation par courbes éliptiques, utilisatoin de la physique quantique, méthode de crypt-analyse, génération de très grands nombres premiers, mathématiques probabilistes, divers raisonnemets, etc...
cosmobob Messages postés 700 Date d'inscription mardi 30 décembre 2003 Statut Membre Dernière intervention 27 janvier 2009 4
11 juin 2004 à 17:04
la clé publique est par nature connue de tous. seule la clef secrete est cachée...
newic500 Messages postés 6 Date d'inscription vendredi 26 mars 2004 Statut Membre Dernière intervention 10 juin 2005
11 juin 2004 à 11:00
En relisant mon livre de C++, les unsigned long font 32 bits en standard. Toutefois, nous avons utilisé des unsigned _int64, qui est un type non standard défini par microsoft....

Sinon, vous n'avez qu'a tester le module de crackage de clefs (menu "Cles"), pour vous rendre compte qu'une cle 32 bits n'est pas sure. Par contre, si la clef public et la clef privée sont inconnues, je pense que c'est beaucoup plus compliqué a decrypter.
Pour info, je crois que les cles pour SSH sont des cles 768 bits.
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
11 juin 2004 à 09:32
float : 32 bits
double : 64 bits par defaut au niveau du C (80 en interne).
cs_LordBob Messages postés 2865 Date d'inscription samedi 2 novembre 2002 Statut Membre Dernière intervention 11 mai 2009 9
11 juin 2004 à 09:23
tres bon programme !!!
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
11 juin 2004 à 07:46
et les double? c'est sur 32 ou 64 bits? parce que sinon je vois pas la différence avec un float ...
cosmobob Messages postés 700 Date d'inscription mardi 30 décembre 2003 Statut Membre Dernière intervention 27 janvier 2009 4
11 juin 2004 à 02:37
Deathcrash : "C'est dire si le RSA 32bits est encore très utilisé dans le cryptage de données!"
ben heureusement que non, un RSA 32 bits se casse en moins d'un millieme de seconde... les meilleurs algo de factorisation (crible quadratique) sont en n^(1/4), alors t'imagines pour n= 2^32... ca fait que 256 itérations !! d'ailleurs meme le crible d'Eratosthène factorise un entier de 32 bits en un temps tres court (< 1/1000e seconde)
pour info les clés utilisées pour les serveurs qui gerent les annuaires de clés publiques sont en général de 2048 bits. avec les méthodes actuelles, et en supposant que la vitesse des ordinateurs évolue dans le futur comme dans le passé, il faudrait plusieurs millers (millions?) d'années pour casser une clé de 2048 bits
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
11 juin 2004 à 00:20
Kirua > sur win32 int ou long c'est idem 32 bits, que soit signe ou non.
cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
10 juin 2004 à 14:41
"éles librairies standard du langage C++ ne permettent au maximum que des clefs de 32 bits."

et les unsigned long ? c'est sur 64 bits pour une architecture 32 bits (win32 typiquement puisque tu utilises les MFC).

je suppose que ton rapport est à rendre. dans la mesure du possible, si tu ne l'as pas encore rendu, fais le relire par qq un d'autre pour l'ortho! c'est pas catastrophique, mais il y en a qq unes qui font tache ;-) j'vais pas t'embeter avec ça ici, mais ça me paraît important :)

pour le reste, j'ai parcouru le dossier, mais je manque de connaissances en math pr vrmnt comprendre, malheureusement :/
DeAtHCrAsH Messages postés 2670 Date d'inscription vendredi 25 janvier 2002 Statut Membre Dernière intervention 6 février 2013
10 juin 2004 à 09:56
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
cs_Stormy Messages postés 255 Date d'inscription samedi 20 avril 2002 Statut Membre Dernière intervention 16 janvier 2007
9 juin 2004 à 22:11
Franchement très impréssionant! C'est vrai qu'une clé RSA est particulièrement faible sous 256/512 bits mais votre programme qui se limite à 32 bits est une bonne méthode pour comprendre le principe ++
Rejoignez-nous