Bonjour,
existe-t-il une librairie javascript qui permette de générer une clé rsa (ou autre algo asymétrique) privée, publique, et d'encoder et de décoder des fichiers avec ces clés ? j'ai pas trouvé... :calim2:
Version imprimable
Bonjour,
existe-t-il une librairie javascript qui permette de générer une clé rsa (ou autre algo asymétrique) privée, publique, et d'encoder et de décoder des fichiers avec ces clés ? j'ai pas trouvé... :calim2:
Ben ici, il est surtout question de JavaScript dans le navigateur et à ce niveau, générer une clé privée n'est rien moins qu'un non sens.
Ceci dit, il existe des librairies JavaScript serveur qui semblent faire ça. Par exemple Node.js
Ah? Pourquoi?Citation:
Ben ici, il est surtout question de JavaScript dans le navigateur et à ce niveau, générer une clé privée n'est rien moins qu'un non sens.
Ben parce que si tu génères la clé privée dans le navigateur, tout le monde y aura potentiellement accès... ce qui n'est habituellement pas le but recherché :koi:
désolé de bugguer comme ça, je connais pas assez bien ces points là, mais comment quelqu'un d'extérieur pourrait accéder à ma clé privée? Comment il devrait s'y prendre pour faire ça?
j'ai peut-être trouvé quelque chose ici : http://shop-js.sourceforge.net/crypto2.htm
malgré tout je reste curieux de ta réponse Bovino
C'est juste qu'en général, JavaScript s'exécute sur une page Web, que cette page Web est donc potentiellement accessible par tout le monde et donc le code de création de ta clé aussi.
le code de création? tu veux dire l'algo ? oO
Ben l'algo de RSA est bien accessible à tout le monde. Pourtant on n'a pas abandonné le ssl...
bon, j'ai trouvé ça aussi : http://www-cs-students.stanford.edu/~tjw/jsbn/rsa2.html,
mais j'ai absolument aucune idée de comment les utiliser... je vois des e, des n, des d, p, q, etc, plein de fonctions prenant en compte différents paramètres, mais je n'ai absolument aucune idée de comment générer un paire clé publique/clé privée, et les utiliser pour crypter/décrypter...
Si quelqu'un est plus à l'aise que moi avec la crypto...
L'algo c'est une chose, le code de création, c'est ce qui va te permettre d'utiliser l’algorithme avec des paramètres déterminés qui permettront de générer la clé. Du coup, si ces paramètres sont accessibles, alors la clé le sera aussi.Citation:
Envoyé par Sharcoux
Ceci dit, j’admets que j'ai peut-être été un peu excessif dans mon jugement :aie:
Euh... ouais, parce que sur la page web tu trouveras que l'algo. Les paramètres ils seront déterminés lors de l'exécution sur la machine du client. :mouarf:Citation:
L'algo c'est une chose, le code de création, c'est ce qui va te permettre d'utiliser l’algorithme avec des paramètres déterminés qui permettront de générer la clé. Du coup, si ces paramètres sont accessibles, alors la clé le sera aussi.
Ceci dit, j’admets que j'ai peut-être été un peu excessif dans mon jugement
Sinon, je suis toujours preneur si quelqu'un a trouver un script de cryptage et qu'il arrive à l'utiliser... Parce que pour le moment y a rien qui marche...
je pense que tu devrait encore relire la théorie sur RSA et celle sur les clés privées avant de chercher la solution a ton problème !
:calim2:
Merci du conseil, mais comme tu ne m'explique pas ce qui te pousse à dire ça, ça ne m'aide pas beaucoup...
En fait le problème repose sur la génération de ta clé privée sans la recevoir du serveur sinon ça sert à rien de crypter tes données sur le reseau si on a pu intercepter la clé de décryptage juste avant.
Et comme il n'existe pas d'algo pour générer des nombres premiers(clé privés) je ne vois pas comment le client pourrait en obtenir une sans la récupérer sur le réseau.
En fait si, j'imagine bien un moyen un peu compliqué. Le serveur possède un clé privée et t'envoie une clé publique pour que tu puisses lui envoyer des messages privés.
Après il te suffit de générer un grand nombre aléatoire(très grand) et de l'envoyer au serveur. En supposant que le serveur ait accès à une grande base de données de clés privées, il pourrait en choisir une aléatoirement à t'envoyer. A laquelle il soustrairait d'abord le nombre que tu lui as envoyé.
Il t'enverrait donc(de façon non cryptée) une clé tronquée d'une valeur que seul toi et lui connaissez. Il te suffirait donc du coté client et recoller les morceau et ainsi obtenir ta clé privée. De là tu pourras générer des clés publiques et les distribuer. Par exemple au serveur qui enfin à son tour pourra t'envoyer des donner cryptées.
Si je ne dis pas de bêtises ?
pourquoi on ne pourrait pas envoyer au client un fichier contenant un très grand nombre de nombres premiers? Il n'aurait alors plus qu'à en choisir au hasard dans la liste...
Euh... C'est pas tout à fait vrai : !n - 1 est premier. Mais je vois ce que tu veux direCitation:
comme il n'existe pas d'algo pour générer des nombres premiers
Génial, tu es un génie qui vient de révolutionner la création des nombres premiers ! .... oups ah non, (!5-1) = 119 = 7*17 zut alors !Citation:
Envoyé par Sharcoux
En dehors du fait de ce que tu dis est faux, même en supposant que ça aurait pu être vrai, ça aurait généré un nombre beaucoup trop restreint de nombres qui aurait croient de façon factoriel(donc dépassant l'exponentiel à partir d'une certaine valeur) ce qui aurait vachement limité le nombre de clé, donc facilement retrouvable à moins d'en générer des infiniment grandes ce qui auraient été impossible à utiliser vu la lenteur des calculs de cryptage à partir d'un certain point.
Bon, disons que pour avoir un minimum de sécurité, une clé doit avoir être écrite de minimum 50 chiffres(pour l'exemple, certains me diront qu'il en faut plus ou moins) donc une valeur de 10^50. (taille = 50 octets)Citation:
Envoyé par Sharcoux
Maintenant, supposons que tu en envois 10.000.000.000, (bah oui, si tu n'en envoies que 2-3 le hacker aura vite fait le tour de ta liste avec un algo) donc 50octets * 10.000.000.000 = 500Go. J'espère que tu as ta réponse et que tu comprends pourquoi ce n'est pas possible pour une page web. (et encore, il me semble évident que 10 milliards c'est encore bien trop peu, même si je n'ai jamais testé ni de chiffres sous la main qui en parle.)
En plus, le hacker aura toujours toutes les clés "potentielles". Or il n'existe pas de liste exhaustible des nombres premiers. En tout cas pas à partir du moment où les valeurs deviennent intéressante pour du cryptage. (> 10^50).
edit: bon dis nous simplement ce que tu voulais faire, on pourra sans doute te donner une solution plus adaptée.
usage de page sécurisée "https" ?
euh... Oui, en fait, j'ai mélangé avec autre chose, dsl, vieux souvenirs :aie:Citation:
Génial, tu es un génie qui vient de révolutionner la création des nombres premiers ! .... oups ah non, (!5-1) = 119 = 7*17 zut alors !
Désolé.
Par contre, il y a quand même quelque chose que je ne comprends pas : les générateurs rsa actuels (celui que tu peux exécuter depuis le shell par exemple), ne prennent pas 500Go d'espace disque. Ca signifie donc qu'il y a bien un moyen de générer ces clés, sans en faire un stock de 10.000.000.000, non?
Désolé, je ne connais pas le générateur en question.Citation:
Envoyé par Sharcoux
Mais il existe plusieurs solution:
1) soit réclamer une clé au serveur( en la cryptant d'une façon ou d'une autre) (je pense que c'est le cas des connexions sécurisées https)
2) soit avoir un stock lors de l'installation (pas besoin d'en avoir 10 milliards, je disais 10 milliards dans le cas où tu le recevrais par le reseau en visible pour que le hacker ne puisse savoir choisir laquelle. on peut ici supposer que tu l'as installé avec un disque ou que le petit nombre que tu as reçu, tu l'as reçu de façon crypté.) (je pense que beaucoup de serveurs ont leurs stock [qu'ils renouvellent ou non en permanence])
3) un vrai générateur, si tu veux les générer dans un temps court, je pense qu'un ordi peut facilement en générer des de taille de 50 caractères (valeur ~10^50) avec un bon algo, après je ne connais pas les limites de javascript dans un navigateur. Et ça risque fort de déprendre de ton visiteur. (nb: je pense que le générateur utilise des algo pour créer des nombres potentiellement premiers et puis les testes pour vérifier qu'ils le sont bien, et si ce n'est pas le cas, en essaye un autre).
Oui, c'est probable, mais du coup, ça me parait parfaitement réalisable en javascript... D'où retour à la case départ...Citation:
je pense que le générateur utilise des algo pour créer des nombres potentiellement premiers et puis les testes pour vérifier qu'ils le sont bien, et si ce n'est pas le cas, en essaye un autre
Effectivement j'ai été un peu vite, il est possible de générer ces clés en javascript, mais si tu veux une clé haute sécurité, il vaut mieux que le client ait une bonne machine.
Les librairies existent mais je n'en connais pas. :oops:
Enfin, es-tu certain de l'usage que tu veux en faire ? Ca permet de RECEVOIR des données cryptés. En général c'est surtout l'envoie qu'on crypte. (d'où les clés générées par le serveur.) Un autre cryptage moins lourd ne serait-il pas suffisant ?
Citation:
Et comme il n'existe pas d'algo pour générer des nombres premiers(clé privés) je ne vois pas comment le client pourrait en obtenir une sans la récupérer sur le réseau.
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Je pense que Willpower parlait de nombre premiers de l'ordre de 10⁵⁰ au moins...
Sinon, l'objectif est que l'utilisateur envoie une clée ssh publique à un serveur de façon que celui-ci puisse lui transmettre des données cryptées que lui seul puisse décrypter.
Ha ben là faut deux semaines ^^
Et tu comptes l'envoyer comment ta clé ? :koi:Citation:
Envoyé par Sharcoux
looool
ouais. Au pire je passe des vidéos à mes utilisateurs pour faire patienter xD
Ben... Ajax. Pourquoi?Citation:
Et tu comptes l'envoyer comment ta clé ?
Non, c'est pas ça que je veux dire, c'est que si je comprends tout bien (ce qui n'est pas gagné :aie:) tu souhaites récupérer des informations d'une page sécurisée à partir d'une page qui ne l'est pas alors je vois mal comment tu vas réussir à faire accepter au serveur d'envoyer du contenu sécurisé vers une page qui ne l'est pas...
en fait, l'objectif final est d'avoir la sécurité d'un certificat ssl, sans certificat ssl. Càd créer un lien sûr entre le serveur cible et le véritable utilisateur. Explication :
L'utilisateur et le serveur sont les seuls détenteurs d'un mot de passe prédéfini.
1)L'utilisateur envoie une requête au serveur contenant ce mdp + une clé ssh_pub, le tout crypté en symétrique par le mdp.
2)Le serveur décrypte le message à l'aide du mdp. S'il retombe bien sur le mdp, il sait qu'il peut faire confiance à l'expéditeur et utilise le deuxième argument (la clé publique) pour lui envoyer des messages.
3) l'utilisateur décrypte les messages du serveur à l'aide de sa clé privée.
Avantages :
- le mdp n'a jamais circulé en clair sur le net,
- le serveur n'a pas besoin de certificat
Evidemment, c'est fait pour des cas d'utilisations particuliers.
Personnellement ce sujet m'intéresse beaucoup car j'avais dans l'idée de faire quelque chose de similaire :
- Le client demande une page au serveur
- Le serveur renvoit la page avec une clef publique
- Le client génère une clef publique et privée et renvoit sa clef publique encodée par la clef du serveur
- L'échange continue ainsi avec les clefs publiques
Maintenant, ne connaissant que le principe des clefs publiques/privées, j'ignorais qu'il était possible de générer de telles clefs de façon algorithmique (en temps fini). Aucun couple de clef n'est donc généré dynamiquement ?
Quant aux premières réponses de Bovino : je ne vois pas pourquoi ce ne serait pas sécurisé.
Au contraire, la clef étant générée sur la machine client, les "données aléatoires" se trouvent sur le client et on peut de chance d'être reproduite par une machine tierce (proxy, ...) qui intercepte les données échangées.
Edit:
Si ce n'est pas possible, il existe une autre solution apparement:
http://fr.wikipedia.org/wiki/Cryptog...ym.C3.A9trique
- Le client demande une page au serveur
- Le serveur renvoit la page avec une clef publique
- Le client génère une clef symétrique la renvoit encodée par la clef du serveur
- L'échange continue ainsi avec la clef symétrique
oui, sauf qu'ici le problème c'est que je ne fais pas confiance au serveur. Je ne peux donc pas compter sur lui pour me fournir une clé publique. Enfin, en tout cas j'aurais aucune garantie sur qui a la clé privée associée. Un serveur pirate pourrait se faire passer pour mon serveur, m'envoyer sa clé publique et, dans ce cas, avec ton système, j'échangerai en toute convivialité et en toute sécurité mes précieuses données avec le serveur pirate... :ccool:
Au passage, pour ton problème, quelle serait la différence avec un simple protocole https?
Le fait qu'il ne nécessite pas de passer par un https déjà et aussi qu'il soit configurable (SSL n'est pas forcément une valeur sure).Citation:
Envoyé par Sharcoux
Ca permet d'avoir un échange sécurisé sur un simple site en HTTP.
Sinon, si tu ne fais pas confiance au serveur, je ne comprends pas ta problématique. Qu'est-ce que tu veux faire exactement ?
Si c'est juste stocker des données de façon sécurisée sur un serveur, il te suffit de crypter les données.
Si c'est avoir un échange sécurisé entre le client et le serveur, il faut avoir confiance à la fois dans le client et dans le serveur.
Après tu peux essayer de t'assurer que le serveur sur lequel tu communiques est le bon (avec des protocoles à connaissance zéro par exemple).
@SpaceFrog: ton aglo ne GENERE pas de nombre premier, il génére des nombres qqconques et teste s'ils sont premiers.
La première solution dont je t'avais parlé pouvoir tout à fait convenir à ton cas de figure.Citation:
Envoyé par Sharcoux
Supposons un mot de passe (suffisamment long pour être bien sécurisé) du genre 15412...654654 (disons avec quasi autant de caractères que la clé privée pour ne pas diminuer la sécurité)
1) le serveur diffuse une clé publique
2) le client envoie sa requête et le mot de passe crypté par la clé publique.
3) le serveur vérifie le client et lui envoie une nouvelle clé privée (qu'il a généré ou qu'il a en stock) à laquelle il soustrait le mot de passe (conversion en entier)
4) le client reçoit une clé privée tronquée que lui seul peut reconstruire en l'additionnant à son mot de passe. Le client et le serveur possèdent ainsi chacun des clés privés pour recevoir des messages cryptés.
Enfin, c'est mon idée, je sais pas si c'est la meilleure.
Ca permettrait d'éviter le cpu de ton client. Quant au serveur, tu pourrais stocker des clés privés et les mettre à jour de temps en temps.
je pense que ça plaira à Loceka, mais moi mon problème c'est que je ne peux pas faire confiance au serveur. Donc si un serveur pirate se fait passer pour mon serveur, imagine le résultat :
1) le pirate m'envoie une clé publique
2) je lui envoie mon mot de passe crypté par SA clé publique.
3) il m'envoie "gros naze" et va se connecter tranquillou sur mon serveur avec mon mot de passe pour me piquer mes données xD
tu peux envoyer le mot de passe plus tard alors :Citation:
Envoyé par Sharcoux
1) serveur envoie clé publique
2) tu envoies un grand nombre aléatoire
3) serveur envoie une nouvelle clé privée tronquée de ce grand nombre
4) tu réajustes ta nouvelle clé privée en additionnant à ton nombre aléatoire. vous pouvez donc tous les 2 communiquer de façon crypté.
après tu peux envoyer le mot de passe crypté par le mot de passe comme tu le faisais avant, ou une simple empreinte md5. quoi qu'il en soit, personne ne pourra lire vos messages.
enfin, as-tu vraiment besoin de rsa ? utilisé le mot de passe crypté entre toi et le serveur n'est-il pas suffisant ?
1) le pirate m'envoie une clé publique
2) je lui envoie un grand nombre aléatoire
3) le pirate m'envoie une nouvelle clé privée tronquée de ce grand nombre
4) je réajuste ma nouvelle clé privée en additionnant mon nombre aléatoire. On peut donc tous les 2 communiquer de façon cryptée.
5) je lui envoie de façon ultra sécurisée mon mdp crypté par le mdp
6) le pirate récupère le résultat et le retransmet tel quel à mon serveur avec en en-tête : "sésame ouvre-toi".
J'aimerais utiliser rsa parce que je ne veux pas stocker le mdp sur l'ordinateur. Il est entré une fois, crypté, puis envoyé. Pour la suite, je veux utiliser un mdp de session. L'idée était d'utiliser la clé publique comme "login" pour la session : le serveur pouvait comme ça m'envoyer des messages en étant sûr du destinataire pour la durée de la session. Régulièrement, le client envoie au serveur un "ping" contenant juste sa clé publique, histoire de la garder active. Dès qu'il a plus de nouvelle d'une clé, hop, delete. Comme ça, impossible de restaurer la session, même avec le pc de l'utilisateur.
Bonsoir,
Peut-être une piste :
http://www-cs-students.stanford.edu/~tjw/jsbn/rsa2.html
Je n'ai pas regardé tout le code dans le détail, mais il semble qu'on y fait ce que vous semblez rechercher (en temps raisonnable)...
Sinon, à ma connaissance, tous les algorithmes implémentant RSA utilisent un générateur pseudo-aléatoire de nombre premier... donc test d'un ou plusieurs nombres quelconques ayant de très grande chances d'être premier.
Et en quoi ça t'assure qu'il n'y aura pas un espion ?Citation:
Envoyé par Sharcoux
Tu ne peux rien contre un man in the middle "actif". Si tu pars de ce principe, il a tout pouvoir : il intercepte ta première requête au serveur, la retransmet au serveur, récupère la réponse, te la retransmet en changeant potentiellement les clefs publiques.
Il est impossible de lutter contre ça.
Oulà la différence est subtile ^^Citation:
il génére des nombres qqconques et teste s'ils sont premiers.
En sortie j'ai bien un array de nombre premiers ...
=> le script génère un array de nombre premiers.
Ok ce n'est absolument pas optimisable car le script doit tester non pas des nombres quelconques, mais touts les nombres, afin de tester si ils sont premiers ou pas ... Javascript ne possède pas d'instruction native pour cela...
Faux.Citation:
Envoyé par Loceka
Simulation de mon protocole avec un man in the middle:
- j'envoie une requête au pirate contenant mon mdp + ma clé ssh_pub le tout crypté par mon mdp.
- le pirate ne peut rien en tirer n'ayant pas le mdp, et tente donc de l'envoyer tel quel au serveur en se faisant passer pour moi.
- le serveur décrypte à l'aide du mdp, retombe bien sur le mdp, et en déduit que le deuxième argument est la ssh_pub d'un utilisateur authentifié. Il crypte alors les données avec la-dite ssh_pub.
- le pirate reçoit les données du serveur cryptées avec la ssh_pub... Mais n'a pas la ssh_pr pour les décrypter...
fin de la simulation
merci, j'avais trouvé ce site aussi, mais j'ai pas compris comment utiliser les fonctions fourniesCitation:
Envoyé par nadox
Ben dans ce cas pas besoin de passer par un système de clefs publiques/privées, un simple chiffrage symétrique suffit.
Tu crypte une clef symétrique (facile à générer) + ton mdp avec ton mot de passe et voilà.