Je résume le problème.
A veut communiquer avec B.
Seul moyen de communication : l'e-mail.
Or un tiers C intercepte (potentiellement) toutes les communications
entre A et B.
Il est impossible d'échanger une clef par mail.
Comment communiquer par chiffre ?
Génial :) ça devient hyper intéressant !!
J'ai deux solutions à vous proposer (pour le prix de... 0 !). Je ne vous
donne la seconde que par jeu, par amusement. Cela pourra peut-être
intéresser quelqu'un ici...
LA PREMIERE
1) A et B décident d'un protocole spécifique : ils choisissent de
concert un algorithme, ainsi que le "comment on va faire" (ordre d'échange
des clefs, etc. - on y reviendra). Il importe peu que C soit au courant de
tout cela ou non, s'il a peu ou pas de connaissances en crypto.
2) Ils choisissent CHACUN UNE clef personnelle, que l'autre IGNORE.
3) A choisit une clef commune C0.
4) A la code avec l'algo et sa propre clef. Il obtient C1.
5) Il envoie C1 à B.
6) C intercepte C1. Il ne sait pas quoi en faire ! Selon l'algorithme
choisi, il peut casser le code. C'est là qu'est le risque. Mais si C est un
quidam (une mère qui surveille les mails de sa fille !!!!!), il n'en fera
rien.
7) B reçoit C1.
8) B code C1 avec sa propre clef. B obtient C2.
9) B envoie C2 à A.
10) C intercepte C2 et peut pleurer...
11) A déchiffre C2 avec sa propre clef. Il obtient C3.
12) A envoie C3 à B.
13) C a renoncé.
14) B déchiffre C3 avec sa propre clef... et obtient C0 !!
15) A et B disposent à présent d'une clef C0 commune (éventuellement,
même de plusieurs), que C ignore. Ils peuvent à présent échanger des
messages via RSA, ou autre...
Mais ceci n'est possible qu'avec certains algo seulement.
C'est mathématiquement possible avec une clef de César, mais ce n'est
pas sûr du tout, par exemple (je n'ai pas envie d'expliquer pourquoi ;
faîtes le calcul sur une feuille vous verrez : 253+12=265 265-20=245
245-12=233 233+20=253 : opérations +12/-12 et -20/+20. Mais si C sait
qu'il s'agit d'une clef de César, alors il verra que la différence entre 265
et 245 (qu'il a eu entre les mains) est "-20", d'où de 233, il saura
retrouver, via "+20" le 253...).
Comment faire ? Je ne vois, a priori, pas de logiciel "accessible" (un
des éléments de l'énoncé était, je crois, que B ne peut pas installer de
logiciels, ou quoi) qui permette de faire cela...
Mais cela me semble être la meilleure solution possible !
Après, A et B peuvent par exemple se servir de C0 pour mettre un mot de
passe sur une archive ZIP. Par exemple, si B se connecte à partir d'une
bibliothèque, ou d'un cyber-café, en général, les ordinateurs sont récents,
et disposent de WinZip...
LA SECONDE
Cette solution est plus délicate à mettre en oeuvre.
Voici ce que je pense : il faudrait demander l'adresse de A via
internet, et lui envoyer une disquette qui contiendrait un petit programme
exécutable qui affiche la clef, et, éventuellement, quelques infos
(logiciels, instructions, etc.)
Pourquoi un EXE ? Tout simplement parce que le programme contiendra une
instruction de première importance : dès qu'il a été lu (la première fois,
donc), il s'auto-reprogramme, de telle sorte, par exemple, à n'afficher plus
que des * dans la boîte de dialogue... Je pense que c'est faisable en Visual
Basic, assez simplement.
En résumé :
- ouverture (1) du programme ;
- affichage d'une boîte de dialogue (affiche le texte et la clef) ;
(b)
- clic sur "OK" :
- affichage d'une deuxième boîte de dialogue (où il n'y rien marqué
d'important, style "Programme achevé", juste pour laisser un délai au
programme après le clic sur "OK") et modification du programme ;
- clic sur "OK" ;
- fermeture du programme ;
- tentative d'ouverture (2) du programme ;
- affichage des informations modifiées, retour en (b)
Évidemment, un programmeur ou quiconque qui ait quelques connaissances
en info pourra désassembler le programme, et retrouver la clef initiale.
Mais bon, vous avez demandé un truc simple...
Sinon, il reste possible de mettre ce petit programme à disposition sur
Internet, mais là, il ne pourra pas enregistrer la modification (du
programme).
Reste la possibilité de l'échanger via un logiciel comme MSN. Il y a peu
de chances qu'un quidam arrive à accéder aux informations. Mais on n'est pas
sûr de l'identité de la personne avec laquelle on communique...
Si quelqu'un pouvait me donner quelques précisions quant à l'algo dont
on pourrait se servir pour coder C0...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Clement Seveillac
Ce Sat, 27 Sep 2003 14:05:33 +0200, Horace écrivait :
A veut communiquer avec B. Seul moyen de communication : l'e-mail. Or un tiers C intercepte (potentiellement) toutes les communications entre A et B.
LA PREMIERE [...] même de plusieurs), que C ignore. Ils peuvent à présent échanger des messages via RSA, ou autre...
A priori, ta solution est similaire a Diffie-Hellman, en plus tarabiscote et moins sur :)
J'espere que tu lis l'anglais, et t'invite a lire cette FAQ des laboratoires RSA sur ce protocole :
http://www.rsasecurity.com/rsalabs/faq/3-6-1.html
(si tu es vraiment allergique, on trouve plus court et francophone ici : http://www.securite.teamlog.com/publication/9/20/27/26/)
Le probleme majeur avec ces protocoles d'echange de clef secrete sur un canal 'non sur', est que sans authentification (etre sur que C0 ou C1 ou C2 - ou dans le cas de Diffie-Hellman g^a ou g^b viennent du A - ou B - et non C, le vilain intercepteur) C peut s'arranger pour dechiffrer les messages de A et B.
Conclusion : il faudra qu'a un moment A et B se croisent, ou se telephonent, et echange un peu d'information quand meme :) -- clem
A veut communiquer avec B.
Seul moyen de communication : l'e-mail.
Or un tiers C intercepte (potentiellement) toutes les communications
entre A et B.
LA PREMIERE
[...]
même de plusieurs), que C ignore. Ils peuvent à présent échanger des
messages via RSA, ou autre...
A priori, ta solution est similaire a Diffie-Hellman, en plus
tarabiscote et moins sur :)
J'espere que tu lis l'anglais, et t'invite a lire cette FAQ des
laboratoires RSA sur ce protocole :
http://www.rsasecurity.com/rsalabs/faq/3-6-1.html
(si tu es vraiment allergique, on trouve plus court et francophone
ici : http://www.securite.teamlog.com/publication/9/20/27/26/)
Le probleme majeur avec ces protocoles d'echange de clef secrete sur un
canal 'non sur', est que sans authentification (etre sur que C0 ou C1 ou
C2 - ou dans le cas de Diffie-Hellman g^a ou g^b viennent du A - ou B -
et non C, le vilain intercepteur) C peut s'arranger pour dechiffrer les
messages de A et B.
Conclusion : il faudra qu'a un moment A et B se croisent, ou se
telephonent, et echange un peu d'information quand meme :)
--
clem
Ce Sat, 27 Sep 2003 14:05:33 +0200, Horace écrivait :
A veut communiquer avec B. Seul moyen de communication : l'e-mail. Or un tiers C intercepte (potentiellement) toutes les communications entre A et B.
LA PREMIERE [...] même de plusieurs), que C ignore. Ils peuvent à présent échanger des messages via RSA, ou autre...
A priori, ta solution est similaire a Diffie-Hellman, en plus tarabiscote et moins sur :)
J'espere que tu lis l'anglais, et t'invite a lire cette FAQ des laboratoires RSA sur ce protocole :
http://www.rsasecurity.com/rsalabs/faq/3-6-1.html
(si tu es vraiment allergique, on trouve plus court et francophone ici : http://www.securite.teamlog.com/publication/9/20/27/26/)
Le probleme majeur avec ces protocoles d'echange de clef secrete sur un canal 'non sur', est que sans authentification (etre sur que C0 ou C1 ou C2 - ou dans le cas de Diffie-Hellman g^a ou g^b viennent du A - ou B - et non C, le vilain intercepteur) C peut s'arranger pour dechiffrer les messages de A et B.
Conclusion : il faudra qu'a un moment A et B se croisent, ou se telephonent, et echange un peu d'information quand meme :) -- clem
Horace
Clement Seveillac :
LA PREMIERE [...] même de plusieurs), que C ignore. Ils peuvent à présent échanger des messages via RSA, ou autre...
A priori, ta solution est similaire a Diffie-Hellman, en plus tarabiscote et moins sur :)
Oui...
J'espere que tu lis l'anglais, et t'invite a lire cette FAQ des laboratoires RSA sur ce protocole :
http://www.rsasecurity.com/rsalabs/faq/3-6-1.html
(si tu es vraiment allergique, on trouve plus court et francophone ici : http://www.securite.teamlog.com/publication/9/20/27/26/)
Merci.
Le probleme majeur avec ces protocoles d'echange de clef secrete sur un canal 'non sur', est que sans authentification (etre sur que C0 ou C1 ou C2 - ou dans le cas de Diffie-Hellman g^a ou g^b viennent du A - ou B - et non C, le vilain intercepteur) C peut s'arranger pour dechiffrer les messages de A et B.
Conclusion : il faudra qu'a un moment A et B se croisent, ou se telephonent, et echange un peu d'information quand meme :)
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1, C2, etc. sans que le résultat final devienne incohérent ? A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à la source, soit C0... ?
~~ Horace
Clement Seveillac :
LA PREMIERE
[...]
même de plusieurs), que C ignore. Ils peuvent à présent échanger des
messages via RSA, ou autre...
A priori, ta solution est similaire a Diffie-Hellman, en plus
tarabiscote et moins sur :)
Oui...
J'espere que tu lis l'anglais, et t'invite a lire cette FAQ des
laboratoires RSA sur ce protocole :
http://www.rsasecurity.com/rsalabs/faq/3-6-1.html
(si tu es vraiment allergique, on trouve plus court et francophone
ici : http://www.securite.teamlog.com/publication/9/20/27/26/)
Merci.
Le probleme majeur avec ces protocoles d'echange de clef secrete sur un
canal 'non sur', est que sans authentification (etre sur que C0 ou C1 ou
C2 - ou dans le cas de Diffie-Hellman g^a ou g^b viennent du A - ou B -
et non C, le vilain intercepteur) C peut s'arranger pour dechiffrer les
messages de A et B.
Conclusion : il faudra qu'a un moment A et B se croisent, ou se
telephonent, et echange un peu d'information quand meme :)
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1,
C2, etc. sans que le résultat final devienne incohérent ?
A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à
la source, soit C0... ?
LA PREMIERE [...] même de plusieurs), que C ignore. Ils peuvent à présent échanger des messages via RSA, ou autre...
A priori, ta solution est similaire a Diffie-Hellman, en plus tarabiscote et moins sur :)
Oui...
J'espere que tu lis l'anglais, et t'invite a lire cette FAQ des laboratoires RSA sur ce protocole :
http://www.rsasecurity.com/rsalabs/faq/3-6-1.html
(si tu es vraiment allergique, on trouve plus court et francophone ici : http://www.securite.teamlog.com/publication/9/20/27/26/)
Merci.
Le probleme majeur avec ces protocoles d'echange de clef secrete sur un canal 'non sur', est que sans authentification (etre sur que C0 ou C1 ou C2 - ou dans le cas de Diffie-Hellman g^a ou g^b viennent du A - ou B - et non C, le vilain intercepteur) C peut s'arranger pour dechiffrer les messages de A et B.
Conclusion : il faudra qu'a un moment A et B se croisent, ou se telephonent, et echange un peu d'information quand meme :)
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1, C2, etc. sans que le résultat final devienne incohérent ? A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à la source, soit C0... ?
~~ Horace
Eric Razny
"Horace" a écrit dans le message de news:bl489e$7e4$
Clement Seveillac :
Conclusion : il faudra qu'a un moment A et B se croisent, ou se telephonent, et echange un peu d'information quand meme :)
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1,
C2, etc. sans que le résultat final devienne incohérent ? A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à
la source, soit C0... ?
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas échangé *cette* information? :)
Eric.
"Horace" <ERROR@ERROR.fr> a écrit dans le message de
news:bl489e$7e4$1@news-reader4.wanadoo.fr...
Clement Seveillac :
Conclusion : il faudra qu'a un moment A et B se croisent, ou se
telephonent, et echange un peu d'information quand meme :)
Mais si C ignore l'algorithme employé, comment pourrait-il modifier
C1,
C2, etc. sans que le résultat final devienne incohérent ?
A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter
à
la source, soit C0... ?
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas
échangé *cette* information? :)
"Horace" a écrit dans le message de news:bl489e$7e4$
Clement Seveillac :
Conclusion : il faudra qu'a un moment A et B se croisent, ou se telephonent, et echange un peu d'information quand meme :)
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1,
C2, etc. sans que le résultat final devienne incohérent ? A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à
la source, soit C0... ?
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas échangé *cette* information? :)
Eric.
Oleg
J'ai deux solutions à vous proposer (pour le prix de... 0 !). Je ne vous donne la seconde que par jeu, par amusement. Cela pourra peut-être intéresser quelqu'un ici...
LA PREMIERE [...] LA SECONDE [...]
La première est très intéressante. Je vais voir ce que je peux en faire d'un point de vue pratique car je suis en situation réelle ;)
Sinon, toujours sur un plan pratique, j'ai trouvé une démo de RSA via des applets java : http://tunah.net/index.php?section=java-rsa
Si ça marche sur le navigateur de la personne avec qui je souhaite échanger une info secrète, ça résoud mon problème à 100%.
En tous cas je vais quand même m'amuser à mettre en oeuvre la solution 1.
Oleg
J'ai deux solutions à vous proposer (pour le prix de... 0 !). Je ne vous
donne la seconde que par jeu, par amusement. Cela pourra peut-être
intéresser quelqu'un ici...
LA PREMIERE
[...]
LA SECONDE
[...]
La première est très intéressante. Je vais voir ce que je peux en faire
d'un point de vue pratique car je suis en situation réelle ;)
Sinon, toujours sur un plan pratique, j'ai trouvé une démo de RSA via
des applets java :
http://tunah.net/index.php?section=java-rsa
Si ça marche sur le navigateur de la personne avec qui je souhaite
échanger une info secrète, ça résoud mon problème à 100%.
En tous cas je vais quand même m'amuser à mettre en oeuvre la solution 1.
J'ai deux solutions à vous proposer (pour le prix de... 0 !). Je ne vous donne la seconde que par jeu, par amusement. Cela pourra peut-être intéresser quelqu'un ici...
LA PREMIERE [...] LA SECONDE [...]
La première est très intéressante. Je vais voir ce que je peux en faire d'un point de vue pratique car je suis en situation réelle ;)
Sinon, toujours sur un plan pratique, j'ai trouvé une démo de RSA via des applets java : http://tunah.net/index.php?section=java-rsa
Si ça marche sur le navigateur de la personne avec qui je souhaite échanger une info secrète, ça résoud mon problème à 100%.
En tous cas je vais quand même m'amuser à mettre en oeuvre la solution 1.
Oleg
Clement Seveillac
Ce Sat, 27 Sep 2003 16:53:32 +0200, Horace écrivait :
Conclusion : il faudra qu'a un moment A et B se croisent, ou se telephonent, et echange un peu d'information quand meme :)
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1, C2, etc. sans que le résultat final devienne incohérent ?
C peut connaitre l'algo employe : tu viens par exemple de le poster sur Usenet, ou il le devinera s'il est competent et que tu utilises un protocole connu comme DH, ou il lira ton message a A donnant les details de l'algorithme...
Avec de la vraie crypto la connaissance de l'algorithme ne doit heureusement pas etre un secret ; seule la ou les clefs secretes sont a proteger.
A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à la source, soit C0... ?
Si l'algo est bon, comme DH, il ne peut pas deviner la clef secrete "echangee" s'il a seulement acces en lecture aux communications. Il faut qu'il *intercepte* et *modifie* tout ce qu'envoie B a A et vice-versa pour dechiffrer et rechiffrer les messages sans que A ni B s'en apercoivent.
Conclusion : il faudra qu'a un moment A et B se croisent, ou se
telephonent, et echange un peu d'information quand meme :)
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1,
C2, etc. sans que le résultat final devienne incohérent ?
C peut connaitre l'algo employe : tu viens par exemple de le poster
sur Usenet, ou il le devinera s'il est competent et que tu utilises un
protocole connu comme DH, ou il lira ton message a A donnant les details
de l'algorithme...
Avec de la vraie crypto la connaissance de l'algorithme ne doit
heureusement pas etre un secret ; seule la ou les clefs secretes sont a
proteger.
A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à
la source, soit C0... ?
Si l'algo est bon, comme DH, il ne peut pas deviner la clef secrete
"echangee" s'il a seulement acces en lecture aux communications.
Il faut qu'il *intercepte* et *modifie* tout ce qu'envoie B a A et
vice-versa pour dechiffrer et rechiffrer les messages sans que A ni B
s'en apercoivent.
Ce Sat, 27 Sep 2003 16:53:32 +0200, Horace écrivait :
Conclusion : il faudra qu'a un moment A et B se croisent, ou se telephonent, et echange un peu d'information quand meme :)
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1, C2, etc. sans que le résultat final devienne incohérent ?
C peut connaitre l'algo employe : tu viens par exemple de le poster sur Usenet, ou il le devinera s'il est competent et que tu utilises un protocole connu comme DH, ou il lira ton message a A donnant les details de l'algorithme...
Avec de la vraie crypto la connaissance de l'algorithme ne doit heureusement pas etre un secret ; seule la ou les clefs secretes sont a proteger.
A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à la source, soit C0... ?
Si l'algo est bon, comme DH, il ne peut pas deviner la clef secrete "echangee" s'il a seulement acces en lecture aux communications. Il faut qu'il *intercepte* et *modifie* tout ce qu'envoie B a A et vice-versa pour dechiffrer et rechiffrer les messages sans que A ni B s'en apercoivent.
-- clem
Horace
Eric Razny :
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1,
C2, etc. sans que le résultat final devienne incohérent ? A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à
la source, soit C0... ?
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas échangé *cette* information? :)
Non, ce n'est pas à cela que je pensais... S'ils employent un algo simple (comme le chiffre de César, ou autre algo facile à casser si on connaît la *formule*), il importe que C ne soit pas informé de la *formule* exacte (par exemple (C+K)*K)-(K*C), mais je dit n'importe quoi). Dans ce cas, A et B auront *échangé* un logiciel qui contienne cette formule et cet algo. C aura du mal à retrouver la formule. Mais dans le cas des formules simples, on passe assez vite de C1, C2, C3 à C0, même sans connaître les formules/algorithme. S'il s'agit d'un algorithme plus complexe (comme RSA), il importe peu que la formule soit ou non connue de C.
~~ Christophe
Eric Razny :
Mais si C ignore l'algorithme employé, comment pourrait-il modifier
C1,
C2, etc. sans que le résultat final devienne incohérent ?
A moins qu'il ne s'agisse pas de les modifier, mais juste de
remonter à
la source, soit C0... ?
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas
échangé *cette* information? :)
Non, ce n'est pas à cela que je pensais...
S'ils employent un algo simple (comme le chiffre de César, ou autre algo
facile à casser si on connaît la *formule*), il importe que C ne soit pas
informé de la *formule* exacte (par exemple (C+K)*K)-(K*C), mais je dit
n'importe quoi). Dans ce cas, A et B auront *échangé* un logiciel qui
contienne cette formule et cet algo. C aura du mal à retrouver la formule.
Mais dans le cas des formules simples, on passe assez vite de C1, C2, C3
à C0, même sans connaître les formules/algorithme.
S'il s'agit d'un algorithme plus complexe (comme RSA), il importe peu
que la formule soit ou non connue de C.
Mais si C ignore l'algorithme employé, comment pourrait-il modifier C1,
C2, etc. sans que le résultat final devienne incohérent ? A moins qu'il ne s'agisse pas de les modifier, mais juste de remonter à
la source, soit C0... ?
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas échangé *cette* information? :)
Non, ce n'est pas à cela que je pensais... S'ils employent un algo simple (comme le chiffre de César, ou autre algo facile à casser si on connaît la *formule*), il importe que C ne soit pas informé de la *formule* exacte (par exemple (C+K)*K)-(K*C), mais je dit n'importe quoi). Dans ce cas, A et B auront *échangé* un logiciel qui contienne cette formule et cet algo. C aura du mal à retrouver la formule. Mais dans le cas des formules simples, on passe assez vite de C1, C2, C3 à C0, même sans connaître les formules/algorithme. S'il s'agit d'un algorithme plus complexe (comme RSA), il importe peu que la formule soit ou non connue de C.
~~ Christophe
Eric Razny
"Horace" a écrit dans le message de news:bl6eig$f5c$
Eric Razny :
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas échangé *cette* information? :)
Non, ce n'est pas à cela que je pensais... S'ils employent un algo simple (comme le chiffre de César, ou autre algo
facile à casser si on connaît la *formule*), il importe que C ne soit pas informé de la *formule* exacte (par exemple (C+K)*K)-(K*C), mais je dit n'importe quoi). Dans ce cas, A et B auront *échangé* un logiciel qui contienne cette formule et cet algo.
C'est bien là que je voulais venir. A & B doivent échanger une information pour communiquer en relative sécurité. Que ce soit les détails d'un algo secret (protection généralement illusoire), des clefs pour cryptage sysmétrique ou des clefs publiques ils doivent échanger de l'information (au sens large). L'échange le moins risqué en cas d'interception est, amha, la clef publique à condition d'avoir un autre canal pour vérifier lesdites clefs (confirmation de hash au téléphone si les deux personnes se connaissent bien [1] par exemple)
S'il s'agit d'un algorithme plus complexe (comme RSA), il importe peu que la formule soit ou non connue de C.
Dans le cas de RSA tu dois échanger les clefs publiques, donc bel et bien un échange d'info, non?
Eric.
[1] et encore, le parano ajoutera des tests, dès fois qu'un imitateur soit à l'autre bout :)
"Horace" <ERROR@ERROR.fr> a écrit dans le message de
news:bl6eig$f5c$1@news-reader3.wanadoo.fr...
Eric Razny :
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas
échangé *cette* information? :)
Non, ce n'est pas à cela que je pensais...
S'ils employent un algo simple (comme le chiffre de César, ou autre
algo
facile à casser si on connaît la *formule*), il importe que C ne soit pas
informé de la *formule* exacte (par exemple (C+K)*K)-(K*C), mais je dit
n'importe quoi). Dans ce cas, A et B auront *échangé* un logiciel qui
contienne cette formule et cet algo.
C'est bien là que je voulais venir. A & B doivent échanger une information
pour communiquer en relative sécurité. Que ce soit les détails d'un algo
secret (protection généralement illusoire), des clefs pour cryptage
sysmétrique ou des clefs publiques ils doivent échanger de l'information (au
sens large). L'échange le moins risqué en cas d'interception est, amha, la
clef publique à condition d'avoir un autre canal pour vérifier lesdites
clefs (confirmation de hash au téléphone si les deux personnes se
connaissent bien [1] par exemple)
S'il s'agit d'un algorithme plus complexe (comme RSA), il importe peu
que la formule soit ou non connue de C.
Dans le cas de RSA tu dois échanger les clefs publiques, donc bel et bien un
échange d'info, non?
Eric.
[1] et encore, le parano ajoutera des tests, dès fois qu'un imitateur soit à
l'autre bout :)
"Horace" a écrit dans le message de news:bl6eig$f5c$
Eric Razny :
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas échangé *cette* information? :)
Non, ce n'est pas à cela que je pensais... S'ils employent un algo simple (comme le chiffre de César, ou autre algo
facile à casser si on connaît la *formule*), il importe que C ne soit pas informé de la *formule* exacte (par exemple (C+K)*K)-(K*C), mais je dit n'importe quoi). Dans ce cas, A et B auront *échangé* un logiciel qui contienne cette formule et cet algo.
C'est bien là que je voulais venir. A & B doivent échanger une information pour communiquer en relative sécurité. Que ce soit les détails d'un algo secret (protection généralement illusoire), des clefs pour cryptage sysmétrique ou des clefs publiques ils doivent échanger de l'information (au sens large). L'échange le moins risqué en cas d'interception est, amha, la clef publique à condition d'avoir un autre canal pour vérifier lesdites clefs (confirmation de hash au téléphone si les deux personnes se connaissent bien [1] par exemple)
S'il s'agit d'un algorithme plus complexe (comme RSA), il importe peu que la formule soit ou non connue de C.
Dans le cas de RSA tu dois échanger les clefs publiques, donc bel et bien un échange d'info, non?
Eric.
[1] et encore, le parano ajoutera des tests, dès fois qu'un imitateur soit à l'autre bout :)
Horace
Eric Razny :
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas échangé *cette* information? :)
Non, ce n'est pas à cela que je pensais... S'ils employent un algo simple (comme le chiffre de César, ou autre algo
facile à casser si on connaît la *formule*), il importe que C ne soit pas
informé de la *formule* exacte (par exemple (C+K)*K)-(K*C), mais je dit n'importe quoi). Dans ce cas, A et B auront *échangé* un logiciel qui contienne cette formule et cet algo.
C'est bien là que je voulais venir. A & B doivent échanger une information pour communiquer en relative sécurité. Que ce soit les détails d'un algo secret (protection généralement illusoire), des clefs pour cryptage sysmétrique ou des clefs publiques ils doivent échanger de l'information (au
sens large). L'échange le moins risqué en cas d'interception est, amha, la clef publique à condition d'avoir un autre canal pour vérifier lesdites clefs (confirmation de hash au téléphone si les deux personnes se connaissent bien [1] par exemple)
S'il s'agit d'un algorithme plus complexe (comme RSA), il importe peu que la formule soit ou non connue de C.
Dans le cas de RSA tu dois échanger les clefs publiques, donc bel et bien un
échange d'info, non?
[1] et encore, le parano ajoutera des tests, dès fois qu'un imitateur soit à
l'autre bout :)
Il ne faut pas oublier les données du problème qui a été posé. C "ne s'y connaît pas." Il n'a pas de gros moyens, ni une grande connaissance en cryptologie. De plus, au vu du problème, je le suppose, C n'a qu'un accès en lecture seule aux informations. Ainsi, l'échange des clefs, ou de l'algo, etc. n'est pas génant dans ce cas-ci. Ce que je voulais dire, c'est qu'un algo "simple", une formule simple suffit ici, avec le principe des C0 > C1 > C2 > C3 > C0. *Dans ce cas-ci* il suffit que C ne sache pas le détail de la formule pour être complètement arrêté. Même s'il a intercepté une copie du logiciel, il ne saura pas quoi en faire. Il faut désassembler celui-ci pour retrouver la formule, et, par suite, pouvoir retrouver C0 en connaissant C1, C2, C3. Et le désassemblage n'est pas une opération à la portée de tout le monde !
Mais, effectivement, je cherche aussi une généralisation de ce procédé, où C pourrait modifier les infos, etc. En fait, je cherche un algorithme qui fonctionnerait sur le principe de la clef secrète. Et cette clef pourrait, par exemple, évoluer en fonction des messages. C'est-à-dire que A et B partagent au départ une clef K0. Après avoir chiffré/déchiffré chacun un même message, ils ont une clef K1, puis K2 après le message 2, etc. Mais je ne sais pas si c'est une bonne idée. Mais dans ce cas précis, si un message est modifié, alors A et B se retrouvent avec des Kn et des K'n différents. L'intégrité est assurée, de même que l'authenticité. En fait, je dois encore beaucoup réfléchir à tout ça. Et puis je préfèrerais un système qui associerait une clef publique. Idéalement, même, je voudrais que A et B n'aient, au départ, que chacun une clef publique, et que leur K0 du premier message dépende de celles-ci. Mais cela semble absolument impossible ; C pourrait retrouver K0. Je suis sur une fausse piste. Pourquoi ne pas garder le système des C0 > C1 > C2 > C3 > C0 pour coder le K0 initial ? Il suffirait cette fois que l'algo soit beaucoup plus performant, et incassable. Après, les échanges sont sûrs. Mais la clef variable Kn me semble une bonne solution pour assurer intégrité et authentification, mais elle est aussi ennuyeuse. Si C modifie volontairement tout les messages, A et B ne peuvent plus s'entendre.
~~ Christophe
Eric Razny :
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas
échangé *cette* information? :)
Non, ce n'est pas à cela que je pensais...
S'ils employent un algo simple (comme le chiffre de César, ou autre
algo
facile à casser si on connaît la *formule*), il importe que C ne soit
pas
informé de la *formule* exacte (par exemple (C+K)*K)-(K*C), mais je dit
n'importe quoi). Dans ce cas, A et B auront *échangé* un logiciel qui
contienne cette formule et cet algo.
C'est bien là que je voulais venir. A & B doivent échanger une information
pour communiquer en relative sécurité. Que ce soit les détails d'un algo
secret (protection généralement illusoire), des clefs pour cryptage
sysmétrique ou des clefs publiques ils doivent échanger de l'information
(au
sens large). L'échange le moins risqué en cas d'interception est, amha, la
clef publique à condition d'avoir un autre canal pour vérifier lesdites
clefs (confirmation de hash au téléphone si les deux personnes se
connaissent bien [1] par exemple)
S'il s'agit d'un algorithme plus complexe (comme RSA), il importe peu
que la formule soit ou non connue de C.
Dans le cas de RSA tu dois échanger les clefs publiques, donc bel et bien
un
échange d'info, non?
[1] et encore, le parano ajoutera des tests, dès fois qu'un imitateur soit
à
l'autre bout :)
Il ne faut pas oublier les données du problème qui a été posé. C "ne s'y
connaît pas." Il n'a pas de gros moyens, ni une grande connaissance en
cryptologie. De plus, au vu du problème, je le suppose, C n'a qu'un accès en
lecture seule aux informations.
Ainsi, l'échange des clefs, ou de l'algo, etc. n'est pas génant dans ce
cas-ci. Ce que je voulais dire, c'est qu'un algo "simple", une formule
simple suffit ici, avec le principe des C0 > C1 > C2 > C3 > C0. *Dans ce
cas-ci* il suffit que C ne sache pas le détail de la formule pour être
complètement arrêté. Même s'il a intercepté une copie du logiciel, il ne
saura pas quoi en faire. Il faut désassembler celui-ci pour retrouver la
formule, et, par suite, pouvoir retrouver C0 en connaissant C1, C2, C3. Et
le désassemblage n'est pas une opération à la portée de tout le monde !
Mais, effectivement, je cherche aussi une généralisation de ce procédé,
où C pourrait modifier les infos, etc.
En fait, je cherche un algorithme qui fonctionnerait sur le principe de
la clef secrète. Et cette clef pourrait, par exemple, évoluer en fonction
des messages. C'est-à-dire que A et B partagent au départ une clef K0. Après
avoir chiffré/déchiffré chacun un même message, ils ont une clef K1, puis K2
après le message 2, etc.
Mais je ne sais pas si c'est une bonne idée. Mais dans ce cas précis, si
un message est modifié, alors A et B se retrouvent avec des Kn et des K'n
différents. L'intégrité est assurée, de même que l'authenticité. En fait, je
dois encore beaucoup réfléchir à tout ça. Et puis je préfèrerais un système
qui associerait une clef publique. Idéalement, même, je voudrais que A et B
n'aient, au départ, que chacun une clef publique, et que leur K0 du premier
message dépende de celles-ci. Mais cela semble absolument impossible ; C
pourrait retrouver K0. Je suis sur une fausse piste.
Pourquoi ne pas garder le système des C0 > C1 > C2 > C3 > C0 pour coder
le K0 initial ? Il suffirait cette fois que l'algo soit beaucoup plus
performant, et incassable. Après, les échanges sont sûrs.
Mais la clef variable Kn me semble une bonne solution pour assurer
intégrité et authentification, mais elle est aussi ennuyeuse. Si C modifie
volontairement tout les messages, A et B ne peuvent plus s'entendre.
Et comment A et B connaissent l'algorithme employé s'il ne se sont pas échangé *cette* information? :)
Non, ce n'est pas à cela que je pensais... S'ils employent un algo simple (comme le chiffre de César, ou autre algo
facile à casser si on connaît la *formule*), il importe que C ne soit pas
informé de la *formule* exacte (par exemple (C+K)*K)-(K*C), mais je dit n'importe quoi). Dans ce cas, A et B auront *échangé* un logiciel qui contienne cette formule et cet algo.
C'est bien là que je voulais venir. A & B doivent échanger une information pour communiquer en relative sécurité. Que ce soit les détails d'un algo secret (protection généralement illusoire), des clefs pour cryptage sysmétrique ou des clefs publiques ils doivent échanger de l'information (au
sens large). L'échange le moins risqué en cas d'interception est, amha, la clef publique à condition d'avoir un autre canal pour vérifier lesdites clefs (confirmation de hash au téléphone si les deux personnes se connaissent bien [1] par exemple)
S'il s'agit d'un algorithme plus complexe (comme RSA), il importe peu que la formule soit ou non connue de C.
Dans le cas de RSA tu dois échanger les clefs publiques, donc bel et bien un
échange d'info, non?
[1] et encore, le parano ajoutera des tests, dès fois qu'un imitateur soit à
l'autre bout :)
Il ne faut pas oublier les données du problème qui a été posé. C "ne s'y connaît pas." Il n'a pas de gros moyens, ni une grande connaissance en cryptologie. De plus, au vu du problème, je le suppose, C n'a qu'un accès en lecture seule aux informations. Ainsi, l'échange des clefs, ou de l'algo, etc. n'est pas génant dans ce cas-ci. Ce que je voulais dire, c'est qu'un algo "simple", une formule simple suffit ici, avec le principe des C0 > C1 > C2 > C3 > C0. *Dans ce cas-ci* il suffit que C ne sache pas le détail de la formule pour être complètement arrêté. Même s'il a intercepté une copie du logiciel, il ne saura pas quoi en faire. Il faut désassembler celui-ci pour retrouver la formule, et, par suite, pouvoir retrouver C0 en connaissant C1, C2, C3. Et le désassemblage n'est pas une opération à la portée de tout le monde !
Mais, effectivement, je cherche aussi une généralisation de ce procédé, où C pourrait modifier les infos, etc. En fait, je cherche un algorithme qui fonctionnerait sur le principe de la clef secrète. Et cette clef pourrait, par exemple, évoluer en fonction des messages. C'est-à-dire que A et B partagent au départ une clef K0. Après avoir chiffré/déchiffré chacun un même message, ils ont une clef K1, puis K2 après le message 2, etc. Mais je ne sais pas si c'est une bonne idée. Mais dans ce cas précis, si un message est modifié, alors A et B se retrouvent avec des Kn et des K'n différents. L'intégrité est assurée, de même que l'authenticité. En fait, je dois encore beaucoup réfléchir à tout ça. Et puis je préfèrerais un système qui associerait une clef publique. Idéalement, même, je voudrais que A et B n'aient, au départ, que chacun une clef publique, et que leur K0 du premier message dépende de celles-ci. Mais cela semble absolument impossible ; C pourrait retrouver K0. Je suis sur une fausse piste. Pourquoi ne pas garder le système des C0 > C1 > C2 > C3 > C0 pour coder le K0 initial ? Il suffirait cette fois que l'algo soit beaucoup plus performant, et incassable. Après, les échanges sont sûrs. Mais la clef variable Kn me semble une bonne solution pour assurer intégrité et authentification, mais elle est aussi ennuyeuse. Si C modifie volontairement tout les messages, A et B ne peuvent plus s'entendre.
