générateur de clés de cryptage asymétrique

Version imprimable

Voir 40 message(s) de cette discussion en une page

01/08/2011, 13h49
Willpower

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:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 var resultat=new Array() var Max=0 function ListePrem(max){ var i = 1 while(Max<=max){ var Prem=true for (j=2; j<=Math.sqrt(i); j++){ (i%j==0) && (Prem= false) } Prem && Max++ && resultat.push(i) i++ } return resultat; } function init(){ var res=document.createElement('span') res.innerHTML=ListePrem(1000).join('<br/>') document.body.appendChild(res) }

01/08/2011, 14h44
Sharcoux

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.
01/08/2011, 14h48
SpaceFrog

Ha ben là faut deux semaines ^^
01/08/2011, 14h52
Bovino

Citation:

Envoyé par Sharcoux

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.

Et tu comptes l'envoyer comment ta clé ? :koi:
01/08/2011, 14h53
Sharcoux

looool
ouais. Au pire je passe des vidéos à mes utilisateurs pour faire patienter xD

Citation:

Et tu comptes l'envoyer comment ta clé ?

Ben... Ajax. Pourquoi?
01/08/2011, 14h57
Bovino

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...
01/08/2011, 15h10
Sharcoux

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.
01/08/2011, 15h34
Loceka
Personnellement ce sujet m'intéresse beaucoup car j'avais dans l'idée de faire quelque chose de similaire :
1. Le client demande une page au serveur
2. Le serveur renvoit la page avec une clef publique
3. Le client génère une clef publique et privée et renvoit sa clef publique encodée par la clef du serveur
4. 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
1. Le client demande une page au serveur
2. Le serveur renvoit la page avec une clef publique
3. Le client génère une clef symétrique la renvoit encodée par la clef du serveur
4. L'échange continue ainsi avec la clef symétrique
01/08/2011, 16h31
Sharcoux

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?
01/08/2011, 16h51
Loceka

Citation:

Envoyé par Sharcoux

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).
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).
01/08/2011, 16h59
Willpower

@SpaceFrog: ton aglo ne GENERE pas de nombre premier, il génére des nombres qqconques et teste s'ils sont premiers.

Citation:

Envoyé par Sharcoux

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.

La première solution dont je t'avais parlé pouvoir tout à fait convenir à ton cas de figure.

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.
01/08/2011, 17h08
Sharcoux

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
01/08/2011, 17h20
Willpower

Citation:

Envoyé par Sharcoux

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 :

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 ?
01/08/2011, 17h45
Sharcoux

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.
01/08/2011, 22h40
nadox

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.
02/08/2011, 08h22
Loceka

Citation:

Envoyé par Sharcoux

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.

Et en quoi ça t'assure qu'il n'y aura pas un espion ?

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.
02/08/2011, 08h23
SpaceFrog

Citation:

il génére des nombres qqconques et teste s'ils sont premiers.

Oulà la différence est subtile ^^
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...
02/08/2011, 10h13
Sharcoux

Citation:

Envoyé par Loceka

Et en quoi ça t'assure qu'il n'y aura pas un espion ?

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.

Faux.
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

Citation:

Envoyé par nadox

Peut-être une piste :
http://www-cs-students.stanford.edu/~tjw/jsbn/rsa2.html

merci, j'avais trouvé ce site aussi, mais j'ai pas compris comment utiliser les fonctions fournies
02/08/2011, 10h23
Loceka

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à.

Voir 40 message(s) de cette discussion en une page