Discussion :

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

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 ?

[SpaceFrog]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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)
}

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

[SpaceFrog]

Ha ben là faut deux semaines ^^

[Bovino]

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é ?

[Sharcoux]

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

Et tu comptes l'envoyer comment ta clé ?

Ben... Ajax. Pourquoi?

[Bovino]

Non, c'est pas ça que je veux dire, c'est que si je comprends tout bien (ce qui n'est pas gagné ) 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...

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

[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

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

Au passage, pour ton problème, quelle serait la différence avec un simple protocole https?

[Loceka]

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

[Willpower]

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

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.

[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

[Willpower]

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 ?

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

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

[Loceka]

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.

[SpaceFrog]

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

[Sharcoux]

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

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

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