Discussion :

[Derboe]

Bonjour,

Dans le cadre de mes études, je dois imaginer un protocole me permettant d'échanger de manière sûre un secret entre A(lice) et B(ob). J'ai donc imaginé le protocole suivant, faisant appel à un serveur S que l'on supposera inattaquable :
A->S : A,{Na,B}Kas
S->B : A, {Na}Kbs
B->S : B,{Nb}Kbs
S->A : B,{Nb}Kas
A->B : {Secret,Hash(Na,Nb,Secret)}Pub(B)

Pourriez vous me dire si vous voyez, très rapidement, des attaques simples permettant de deviner le Secret ? Je ne suis pas encore très à l'aide dans cette matière et je crains de faire des erreurs "de débutant".
Remarque : ce protocole doit avoir le plus faible coup possible selon une fonction de calcul de coup dans laquelle le chiffrement par pai est très onéreux, voilà pourquoi je n'en ai pas utilisé plus que ça.

Par avance merci !

[manticore]

Il serait agréable que tu fournisses les légendes de tes symboles.

[Derboe]

Kas : clé privée partagée par A et le serveur S
Kbs : clé privée partagée par B et le serveur S
Pub(B) : clé publique de B
Na et Nb sont des nonces respectivement de A et B.

[manticore]

C'est bien ce que je pensais si tu utilises des clés privé, publique il ne te sert à rien d'utiliser un serveur tier.

Tu fais une architecture de type kerberos (qui utilise des clés symétrique), avec des clés asymétrique.

Donc en gros ce que tu fais est attaquable par attaque de type re-jeu, il te faut ajouter des timestamps chiffrés. Mais surtout ça n'a pas de sens

Soit tu utilises du kerberos, que tu peux ré-inventer si c'est le projet. Et tu utilises des clés symétrique.

Soit tu utilises simplement la cryptographie asymétrique. Qui permet de faire ce que tu cherches. Il te faut simplement incorporer la clé publique de l'autorité de certification sur A et B.

Je te conseille de lire des articles (l'ordre est relativement important) sur :

a) La cryptographie symétrique
b) Les fonctions de hachages
c) la cryptographie asymétrique
d) Kerberos
e) RSA ou DSA

Wikipedia suffit pour les notions dont tu as besoin

[Derboe]

Le serveur peut servir car on n'a pas de clé privée entre A et B (sinon ça allait vite ^^) mais uniquement entre les différents acteurs et le serveur. Je vais regarder les notions que vous m'avez détaillées et qui sont encore une peu vagues pour moi. Mais je ne pourrai pas refaire un kerberos, notre enseignante a insisté pour qu'on fasse quelque chose d'inédit. Et je pense qu'elle saura reconnaitre un protocole aussi répandu, même modifié... Mais je vais tout de même étudier ce protocole, ne serais-ce que pour avoir des idées.

Quand vous dites que ce n'a pas de sens, qu'entendez vous par là ? Que le protocole ne sécurise en rien le secret, ou que les 4 première opérations ne servent à rien ?

Par avance merci !

[manticore]

ça serait inédit, en faite les protocoles asymétriques sont très très lent !

Donc en gros on utilise généralement l'asymétrie pour échanger des clés et pour authentifier.

La ou je dis que cela ne fait pas de sens c'est d'utiliser de l'asymétrie qui permet justement de s'affranchir d'un serveur tier à la kerberos.

Maintenant oui si la consigne est de créer quelques chose de novateur avec un intérêt éducatif... Il te faut comprendre les notions de bases que je t'ai énuméré.

Sinon pour ton algo il te faut ajouter un timestamp pour éviter le rejeu et en cinq minutes j'ai rien vu de trop dangereux.

[Derboe]

La volonté est de faire quelque chose d'inverse à ce qui se fait réellement, car la fonction de calcul de cout dont j'ai parlé dans le premier message rend peu couteux le chiffrement asymétrique et cher le chiffrement symétrique (et encore plus le chiffrement d'une paire). Ceci afin d'éviter de faire quelque chose ressemblant trop à un protocole existant. Je ne crois pas que nous ayons droit au timestamp... Mais je demanderai. Merci en tout cas pour vos réponses, je vais me pencher sur l'étude des notions évoquées.

[manticore]

J'avais mal lu ton premier poste

Je trouve l'exercice intéressant, pour ce qui est du timestamp je t'en parle parce que ton système ressemble pas mal à du kerberos qui avait justement un problème de timestamp dans ces premières versions.