je sais pas quand je pourrai regarder ça...
mais je m'y jetterai dès que possible
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
je sais pas quand je pourrai regarder ça...
mais je m'y jetterai dès que possible
Alors, pour ce qui est de PGP (je vais répondre ici) :
1)qu'est-ce que j'en pense ?
je ne l'ai jamais regardé de très près et ça fait très longtemps que je ne l'ai plus utilisé, mais si mes souvenir sont exactes (je ferai quelques recherches pour vérifier ça...) PGP n'est rien de plus qu'un client ou qu'une interface de cryptage RSA... je n'en suis pas sûr, mais c'est ce qu'il me semble...
Voilà, je viens de jete un coup d'oeil sur leur site Web :
http://www.pgp.com/products/desktop/personal/techspecs.html
http://www.pgp.com/products/commandline/index.html
http://www.pgp.com/products/commandline/techspecs.html
http://www.pgp.com/products/commandline/screenshots.html
Il s'agit donc d'un client de cryptage multi-algorithmique... il n'existe pas d'algorithme PGP... Il s'intègre aux système et mailers pour rendre le cryptage/décryptage de mail transparent...
2) Pourrait-il faire l'affaire aussi?
A priori, oui : grâce au module command-line, il permet grâce aux commandes exec de crypter//décrypter des informations en les stockant dans des fichiers temporaires, mais toujours pareil, je ne sais pas ce qu'il utilise comme flux d'info, j'ai DL les sources : http://informatique-en-vrac.homedns.org/ESPM/files/PGP/PGPCL_Src.zip
je vais y jeter un oeil (après le reste, chaque en son temps, il va plus me restr beaucoup d'yeux à la fin, déjà que j'en ai que deux)
3) Quelle différence fondamentale avec le RSA?
Bah, comme dit ici : il n'existe pas d'algorithme PGP...
PGP est une interface, alors que RSA est un algorithme...
PGP se sert (peut se servir) de RSA (entre autre), quand tu utilises RSA via PGP, tu as trois couches :
client/PGP/RSA
mais tu peux utiliser PGP sans RSA et inversement :
par exemple :
client/PGP/MD5 (PGP sans RSA)
ou
client/Class_de_Bob/RSA (RSA sans PGP)
...
ils sont indépendants...
donc faudra regarder tout ça...
puis choisir si on prend PGP ou si on DVP notre propre interface RSA...
À voir...
Au fait : si besoin j'héberge un serveur FTP et un serveur HTTP...
je peux tout à fait nous faire un petit espace pour le stockage des fichiers où tout les participant auront accès, à voir....
Merci Swoög pour ces explications détaillées!
C'est ce qu'il me semblait avoir compris, qu'il serait possible d'extraire l'algo et le code RSA d'une librairie PGP. Je n'ai pas encore bien étudié les sources RSA des 7 fichiers que je t'ai envoyé tout à l'heure, mais ça à l'air vraiment costaud! (Si d'autres membres sont curieux de voir ces sources, n'hésitez pas à me contacter par mail, mp ou sur messenger.)
Comme je te le disais Swoög, il serait bien à mon avis d'en faire une classe dans un seul fichier si possible. Je n'ose pas m'y mettre car je ne sais pas ce que vous allez décider. Soit utiliser ces scripts, soit s'en servir pour améliorer celui d'avant, soit utiliser carrément un autre script / algo.
J'ai commencé à regarder cette interface de cryptage, et je la trouve très intéressante, un poil complexe certe, mais extrêmement intéressante !
Le code est peu commenté (et il est commenté en allemand qui plus, est moi et l'allemand : ça 36.5) donc je me suis mis en devoir de le commenter de manière à ce qu'il soit compréhensible pour tout le monde !
Si vous le souhaitez, je mettrais les sources commentées en lignes...
(je les ferais de toutes façons parvenir à Sub0...)
Ensuite, je regarderai les autres interfaces puis, je me pencherai sur les sources de PGP...
C'est semble-t-il du C//C++, (peu suprenant...) .... malheureusement j'ai peu de connaissances en C//C++, donc il faudra décider ce qu'on utilise comme module de cryptage... (je rechercherais en faite quel est le type du flux utiliser pour encrypter//décrypter les donnéees, le reste m'importe à vrai dire peu... c'est juste que je veux voir s'il utilise un flux de type byte[] (c'est celui qui me convient le mieux car il permet de manipuler presque n'importe quoi ! c'est une démarche personnelle que je fais, on peut tout à fait décider d'utiliser un autre flux...)
je ne vois aucun incovénient à passer par l'interface PHP que je suis en train de commenter (la réduire ne devrais pas poser de problème outre-mesure et l'adapter ensuite à un type de flux quel qu'il soit non plus...)
Voilà....
Tant que j'y suis, je vais faire un petit listing de ce qui est à voir :
Ces questions sont celles auxquelles il faut répondre pour que le module de cryptage prenne forme...
[list=1][*]Utilise-t-on ou non RSA ?
[*]Si oui : Quel module de base utilise-t-on :
- Un Nouveau Entièrement Neuf
- On adapte un module existant(sûrement l'interface dont j'ai parlé ici)
- On utilise PGP
[*]Si on prend (a) ou (b) : Quel type de flux utilise-t-on ?[/list:o:48aa947241]
- string
- byte[]
- Autre (Préciser)
Je tient également à proposer un espace Web/FTP pour le projet (voir mon POST précédent...)
Aussi : que pensez-vous de l'idée de passer (peut-être pas tout de suite, mais quand le projet commencera à être aboutit (pour la release 1 par exemple)) en projet sourcesforges ?...
J'ai le mail de tous ceux qui participe au projet, je m'occupe de la distribution. Cela dit, nous pourrions distribuer la classe directement avec la v2.Envoyé par Swoög
C'est clair que ce sera intérressant de comparer et de choisir ce qu'il ya de meilleur, mais bon, sache que ce n'est pas indispensable d'après moi. Le script de la classe RSA va te demander déjà pas mal de travail. D'ailleurs si tu as besoin d'une aide quelconque "de sous-traitance" par exemple, n'hésite pas.
oui, ben en ce qui me concerne, ça fait une raison de plus de mettre de côté PGP (pour l'instant en tous les cas). Et puis vu la taille de l'archive qui contient les sources, je suis pas sûr que c'est que nous recherchons...
Je suis entièrement d'accord avec toi! Ces scripts ont vraiment l'air de tenir la route! Mais dans le cas où il ne nous donnerait pas satisfaction, on pourra essayer d'extraire le RSA de PGP.
1) Oui bien entendu, il n'y a pas mieux pour le chiffrement des données selon moi! Cette classe RSA nous sera d'une grande utilité... Elle pourrait nous servir à d'autres fins par la suite (que du bon quoi).
2) On adapte le module existant.
3) byte[] car c'est le plus souple d'utilisation je trouve aussi. Cela dit, string est pas mal non plus et il serait peut-être intérressant de l'ajouter en option si cela est possible et pas trop compliqué à programmer (on verra ça par la suite, en particulier si nous en avons une utilité).
Oui ce n'est pas une mauvaise idée. On en reparlera tous ensemble lorsque nous aurrons une version déjà bien avancée. On se réunira alors sur msn ou icq pour en discuter!
Les prochaines versions et script, doc divers peuvent-être hébergés sur ton site. Perso, mon abonnement chez Levillage se termine à la fin du mois et je ne le renouvelle pas. Il me reste mon ftp sur dvp mais je ne dispose pas de bdd. Et enfin, un ftp chez free avec une bdd, mais ce sera pas mieux que sur ton propre serveur, c'est clair! Ta proposition tombe plutôt bien en fait!
attention à PGP qui n'estpas open source, regardez plutôt du côté de Gnu PG
Quelques precisions :
+ La generation de cles RSA n'a pas besoin d'etre automatique. En general, on genere une paire de cles RSA et on y touche plus. Si c'ets pour crypter des cles mdp, on generera la paire de cles une fois pour toute a la crzation de l'espace membre.
+ Une cle RSA ne doit pas etre derivee d'un mot de passe. Elle doit etre aleatoire (et c'est assez complexe a generer). Ensuite, pour la stocker, on la crypte avec un algo comme AES (Rijndael), par exemple. De cette maniere, il suffit de connaitre son mot de passe pour utiliser la cle RSA.
+ Creer soi meme un script RSA est complexe. Il doit manipuler des nombres de 512 a 1024 bits pour etre efficace (on est loin des 32 bits standard). PHP peut, avec des classes specialisees, realiser cela, mais il est tres lent, j'ai fait les test avec le script que sub0 a du vous mailer. Le mieux est donc d'utiliser un code source en C/C++ et de creer un script CGI (a mon avis). Le code source en C du RSA est facilement trouvable sur le net (une version est meme fournie par RSA Security Inc).
+ Pour PGP, il utilise en fait un systeme de cryptage hybride tres resistant. PGP genere une cle aleatoire, crypte le message avec (avec un algo symetrique comme TripleDES, blowfish, Towfish, ...) et crypte la cle avec RSA ou un autre algo asymetrique. Il envoie ensuite le tout au correspondant. Le correspondant, decrypte la cle, puis le message avec cette cle. C'est un systeme tres performant et bcp plus resistant a la cryptanalyse que d'utiliser RSA directment. Si certains membres sont interesse, je peux expliquer ca plus en detail.
+ Pour le mode de cryptage, le plus simple dans ce genre de situation est le cryptage par blocs (c'est le plus courant).
OK, pour l'espace Web, le temps de configurer un VHOST, de le mettre accessible en ligne etc... et ça sera Ok (d'ici la fin de la semaine je pense !)
OK, c'est donc à ce niveau là qu'il y a mot de passe.... d'acc, merci pour ces précisions !!
Ok, à voir si vous préférez, par contre, je ne sais pas du tout comment faire passer un script en CGI, et comment utiliser les CGI... (de plus, je suppose que le développement d'un script CGI est différent que pour une appli C//C++ "classique"...
par bloc, soit, mais des blocs de quoi ? quand je pensais à un flux sous forme de byte[], je pensais encoder soit tous les bytes concaténés ensembles (problème de taille ?) soit par paquet de n bytes concaténés....
Alors, quelques precisions :
Developper un script CGI c'est exactement comme une appli C/C++ classique. Tu cree un executable qui sera appele par le site. Donc il suffit de trouver le code source de RSA en C/C++ (ca sera bcp bcp plus rapide qu'un script PHP).
Le cryptage par bloc signifie qu'on crypte un bloc de donnees de taille fixe. La taille depend des algo. Par exemple, on va crypter des blocs de 64 bits. Ca signifie qu'il faut toujours crypter les caracteres 8 par 8. si on veut crypter 1 seul caractere, il faudra ajouter des blancs et crypter 8 quand meme. Les fonctions de crypto de PHP se chargent de ca d'elles meme. On peut donc crypter des chaine de taomme quelconque. Mais si vous utilisez un algo en C/C++ il faudra le faire (enfin c'est simple).
Mes Connaissances en C//C++ sont très "réduites", je n'ai jamais développé grand chose (voir su mon Site Web : Downnload => Progra => Perso), je suis capable "de le lire, mais pas de l'écrire"
d'un autre côtés, si on peut trouver des CS tous prêts, pourquoi pas, Qu'en pensent les autres ?
Si toutes les données doivent être cryptées, alors, il vaudrait mieux que ce soit rapide...
Pour ce qui est de remplir les blocs, je ne pense pas que ce soit le plus dur (même si, je le répète, mes connaissances en C//C++ sont limitées) et pour la taille des blocs... je pensais à une taille proche de celle de la clée... je sais pas pourquoi... mais ça me semble naturel... ensuite... faut voir les avantages et inconvénients...
Désolé, d'insister, mais j'aimerais comprendre un point :
Dans l'interface PHP que je viens de finir de lire (faut que je finnisse les commentaires, ce sera fait sous peu...) le générateur de clés génére des nombres premiers à partir de nombres pseudos-aléatoires, et le générateur de nombres pseudo-aléatoires est initialisé par un nombre choisi...
pourquoi ne pas généré ce nombre à partir du hash d'un mot de passe ? problème de sécurité ? autre ?
De plus, une même initialisation du générateur de nombres pseudo-aléatoires donnera toujours les même nombres, et donc les même clées... Donc plutôt que de crypter les clés avec un algo symétrique sous pass, pourquoi ne pas regénérer à chaque fois les clées privées à partir du pass, ainsi, si le pass donné est mauvais, un décryptage est tout de même effectué, mais le message décrypté sera incompréhensible... pour les clées publiques, on les récupères et on les publies à une première génération des clées par exemple...
cela permet de plus de gérer très facilement une bibliothèque de clés : chacun se souvient de son propre pass, et tout va bien, et c'est toujours plus simple à mémoriser qu'un couple de grands chiffres premiers... ou qu'un ensemble de 5 nombres très grands...)
Quels sont les désavantages présentés par cette méthode ? ==> insécurité ?
possibilité de bugs ?
ou Méthode pas très orthodoxe simplement ??
Je souhaite juste comprendre pourquoi la méthode est pas bonne...
Merci d'Avance...
Ok, dsl j'avais pas tout a fait compris ce que tu voulais faire. Tu peux effectivement dériver la clé RSA d'un mot de passe dans le sens ou tu va générer tes nombres aléatoires en fonction du hash du mdp. Si tu fais ca, tu peux effectivement générer les clés à chaque fois.
Ca pose plusieurs pbs :
1. Générer une clé de 4096 bits est long et couteux en processeur. Si a chaque identification tu dois générer une clé, ton serveur sera tout le tps a 100% CPU, ce qui est une tres mauvaise idee. C'est pour ca qu'on genere une fois pour toute la cle et qu'on la stocke sur le disque protegee par un mot de passe.
2. Plus grave. Un HASH est generalement sur 128 bits. Donc si tu initialise le MD5 a partir du HASH d'un mdp cela pose plusieurs pbs de securite graves. Tout d'abord, on peut tenter de casser le RSA par dictonnaire, il suffit d'essayer de generer les cles avec les mdp d'un dico. C'est impossible si les cles sont generees aleatoirement. Ensuite, ton hash ne fait que 128 bits. Donc c'est comme si ta cle faisait 128 bits (au lieu de 1024 par ex.). Tu donnes l'illusion d'utiliser des cles de 1024 bits, mais comme la cle depend d'un HASH de 128 bits, tu as en fait une cle de 128 bits...
J'anticipe une reponse :
On va me dire que si la cle est stockee sur le disque et cryptee on peut aussi faire une attaque par dico. Oui MAIS il faut commencer par pirater le serveur (ca fait une chose de plus a faire).
La methode que tu proposes fonctionnerait, c'est sur. Mais elle fragilise considerablement le RSA, ce qui est tres dangereux.
OK, c'est donc un problème de pratique (charge CPU) mais surtout d'insécurité ! donc j'abandonne l'idée !!!
Merci pour tes explications !!
J'ai cherché (pour pouvoir commencer à me pencher sur le module CGI) le module RSA C//C++ dont tu parlais, sur ce site : http://www.rsasecurity.com/ et avec, mais je ne l'ai pas trouvé...
Je peux toujours essayer de le coder (va falloir que je me replonge dans le C//C++ et que je trouve de la doc sur le CGI...) mais s'il existe déjà des modules Open Sources pourquoi réinventer l'eau chaude ?
Est-ce que tu pourrais me dire où je puis trouver ce module ?
Merci D'avance
Swoög
Alors pour le RSA :
http://www.google.fr/search?q=cache:...download&hl=fr
Ou alors sur http://www.sourceforge.net/, il te suffit de trouver un soft qui utilises RSA, tu aura le code source.
Sinon, un script CGI c'est simple. C'est une appli en mode console. Sauf que si tu fais un printf, ca ecrit sur la page WEB. Donc tu dois faire :
Pour creer ta page WEB.
Code : Sélectionner tout - Visualiser dans une fenêtre à part printf("<html><body>.......");
A part ce detail, c'est une appli normale.
ok pour ça, & pour faire passer les paramètres ?
notamment ceux envoyés par les méthodes GET & POST ?
Pour la methode GET, c'est tout simplement considere comme une ligne de commande. C'est donc passe en parametre a ta fonciton main.
Pour POST, il me semble que c'est la foncation getenv(), mais le je suis plus trop sur.
ok, je me pencherais sur le module CGI pour les versions futures, qu'en pensent les autres ???
Je suis en train de voir avec Sub0 pour l'hébergement... je vous tiendrais au courant de la façon dont ça évolue...
Salut!
Merci Bob pour ces éclaircissements!
Le top serait d'avoir une option pour optimiser le RSA en fonction du niveau de sécurité...
Du genre 128, 256, 512, 1024bits et/ou CGI.
Le programme gagnerait en temps de calcul.
Il faudrait voir jusqu'à quelle grandeur de clé nous pouvons conserver le script du RSA en PHP...
Le script CGI serait-t-il simple à installer pour les webmasters?
+1
De ce côté là, aucun problème, il s'agirait d'un paramètre passé au constructeur de clés...
le CGI serait je pense à utiliser automatiquement si le serveur l'utilise...
Car il garanti une rapidité supplémentaire, je ne pense pas qu'au niveau sécurité il y ait une grande différence...
Je pense que quand on en sera là...
Un BenchMark peut-être fait très vite
à mon avis, ça peut être fait de manière transparente...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager