Quel nom donner à la clef de retour après avoir reçu l'accusé de réception ?

Le
Raymond H.
Bonjour,
1- A envoie un chiffré à B. B débute le déchiffrement d'un chiffré via un
clef personnelle.
2- Si c'est la bonne clef alors un code (accusé de réception venant du
chiffré) s'affiche. B envoie ce code à A.
3- A envoie une clef de retour pour que B puisse continuer le
déchiffrement du chiffré.

Je voudrais savoir quel nom (ou noms composés, court) donner à cette
clef de retour, un nom qui dit bien ce que c'est. Quelqu'un aurait une
idée?
r.h.
Vos réponses Page 1 / 2
Trier par : date / pertinence
lgr_joly
Le #527969
Je propose : la clé Menceau.
remy
Le #527968
Bonjour,
1- A envoie un chiffré à B. B débute le déchiffrement d'un chiffré via un
clef personnelle.
2- Si c'est la bonne clef alors un code (accusé de réception venant du
chiffré) s'affiche. B envoie ce code à A.
3- A envoie une clef de retour pour que B puisse continuer le
déchiffrement du chiffré.

Je voudrais savoir quel nom (ou noms composés, court) donner à cette
clef de retour, un nom qui dit bien ce que c'est. Quelqu'un aurait une
idée?
r.h.


pas tout compris


en gros tu fais "une petite cuisine" pour faire une authentification
de B

A envoie {un fichier+coucou(xor)geneAlea(init b)}

B initialise son geneAlea decode coucou
et envoie coucou a A
ou coucou (xor)geneAlea(int b+"6 tours lies au coucou")


A fait une verif sur coucou et le chifre de B
code la cle(xor)geneAlea(int b+"12 tours lies au 2 coucou")

B decode la cle et decode le fichier avec la cle envoyee par A


j'ai bon ?

sinon
je propose cle d'acquittement



--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy

Raymond H.
Le #527672
Bonsoir,
"remy" 44479731$0$19676$
Bonjour,
1- A envoie un chiffré à B. B débute le déchiffrement d'un chiffré via
un clef personnelle.
2- Si c'est la bonne clef alors un code (accusé de réception venant du
chiffré) s'affiche. B envoie ce code à A.
3- A envoie une clef de retour pour que B puisse continuer le
déchiffrement du chiffré.

Je voudrais savoir quel nom (ou noms composés, court) donner à cette
clef de retour, un nom qui dit bien ce que c'est. Quelqu'un aurait une
idée?
r.h.
pas tout compris


en gros tu fais "une petite cuisine" pour faire une authentification
de B

A envoie {un fichier+coucou(xor)geneAlea(init b)}

B initialise son geneAlea decode coucou
et envoie coucou a A
ou coucou (xor)geneAlea(int b+"6 tours lies au coucou")


A fait une verif sur coucou et le chifre de B
code la cle(xor)geneAlea(int b+"12 tours lies au 2 coucou")

B decode la cle et decode le fichier avec la cle envoyee par A


j'ai bon ?

Disons que c'est assez simple et compliqué en même temps. Mais je

simplifie en disant que A insère un code crypté dans M (les donnés). A
envoie M à B, et B débute le déchiffrement de M via sa clef habituelle, et
si le Hash des 2 clefs de sessions (intégré dans M) corresponds au 2 clefs
de session servant à déchiffrer M alors le code décrypté s'affiche et B
l'envoie à B. B recoit ce code et c'est la certitude pour B que c'est bien
A qui a reçu ce M. Alors, B envoie à A une clef qui décrypte les 2 clefs de
sessions cryptées (auparavant intégré dans M). C'est via ces 2 clefs de
sessions décryptées par A (par la clef de l'accusé de réception que B vient
d'envoyer à A) que le déchiffrement de M se poursuit avec exactitude.

sinon
je propose cle d'acquittement

Merci :-)

J'avais pensé aussi à:
- clef de confirmation
- clef d'accusé de réception
- clef terminale
- clef secondaire
- clef de déblocage
- clef complémentaire
- etc.
Reste à penser au terme qui définirait le mieux pour les simples
d'esprit.
Bonne soirée.
Raymond H.


Raymond H.
Le #527671
Petite correction...
...
de session servant à déchiffrer M alors le code décrypté s'affiche et B
l'envoie à B. B recoit ce code et c'est la certitude pour B que c'est
bien


...de session servant à déchiffrer M alors le code décrypté s'affiche et A
l'envoie à B. B reçoit ce code et c'est la certitude pour B que c'est
bien...

r.h.

David JOURAND
Le #527670
Bonjour,


Disons que c'est assez simple et compliqué en même temps. Mais je
simplifie en disant que A insère un code crypté dans M (les donnés).
A envoie M à B, et B débute le déchiffrement de M via sa clef
habituelle, et si le Hash des 2 clefs de sessions (intégré dans M)
corresponds au 2 clefs de session servant à déchiffrer M alors le code
décrypté s'affiche et B l'envoie à B. B recoit ce code et c'est la
certitude pour B que c'est bien A qui a reçu ce M. Alors, B envoie à
A une clef qui décrypte les 2 clefs de sessions cryptées (auparavant
intégré dans M). C'est via ces 2 clefs de sessions décryptées par A
(par la clef de l'accusé de réception que B vient d'envoyer à A) que
le déchiffrement de M se poursuit avec exactitude.


Ne serait-ce pas un remake de l'algorithme de Diffie-Hellman ?

--
David Jourand

Raymond H.
Le #527666
Bonsoir,
Ne serait-ce pas un remake de l'algorithme de Diffie-Hellman ?
Ce n'est pas la même chose, c'est différent :)

Bonne soirée
r.h.

Patrick 'Zener' Brunet
Le #527665
Bonjour.

Je réponds à David JOURAND qui dans a écrit
:
Disons que c'est assez simple et compliqué en même temps. Mais
je simplifie en disant que A insère un code crypté dans M (les
donnés). A envoie M à B, et B débute le déchiffrement de M via sa
clef habituelle, et si le Hash des 2 clefs de sessions (intégré dans
M) corresponds au 2 clefs de session servant à déchiffrer M alors le
code décrypté s'affiche et B l'envoie à B. B recoit ce code et
c'est la certitude pour B que c'est bien A qui a reçu ce M. Alors,
B envoie à A une clef qui décrypte les 2 clefs de sessions cryptées
(auparavant intégré dans M). C'est via ces 2 clefs de sessions
décryptées par A (par la clef de l'accusé de réception que B vient
d'envoyer à A) que le déchiffrement de M se poursuit avec exactitude.


Ne serait-ce pas un remake de l'algorithme de Diffie-Hellman ?


C'est différent car visiblement il veut faire quelque chose de
dissymétrique, à l'initiative de A.

Idéalement, une telle stratégie peut permettre de s'affranchir du risque de
double usurpation caractéristique du DH, sans faire appel à un tiers de
confiance...

Mais idéalement seulement, car réussir à faire l'acquittement sans révéler
la clé est en soi un défi. Du moins en toute modestie, je n'en suis pas venu
à bout malgré des mois de recherches (dans le contexte qui m'intéresse et
qui est peut-être plus contraignant).

J'aurais d'ailleurs envie de répondre à Raymond H. ceci:
- Blindez correctement votre algorithme, prouvez-le en dehors de la théorie
sur brouillon, et quand ça marchera vous vous attacherez à nommer les
éléments.
Jusque-là il faut vous attendre à de sérieux remaniements, donc c'est du
temps perdu.

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/


Raymond H.
Le #527362
Bonjour,
Ne serait-ce pas un remake de l'algorithme de Diffie-Hellman ?


C'est différent car visiblement il veut faire quelque chose de
dissymétrique, à l'initiative de A.

Idéalement, une telle stratégie peut permettre de s'affranchir du risque
de
double usurpation caractéristique du DH, sans faire appel à un tiers de
confiance...
En effet, c'est ce que je cherche à faire.


Mais idéalement seulement, car réussir à faire l'acquittement sans révéler
la clé est en soi un défi.
Du moins en toute modestie, je n'en suis pas venu
à bout malgré des mois de recherches (dans le contexte qui m'intéresse et
qui est peut-être plus contraignant).


Dans mon cas, que la clef d'acquittement soit révélé publiquement n'a
aucun problème puisqu'il faut avoir auparavant débuter le déchiffrement des
données principales via la bonne clef personnelle du destinataire, clef
personnelle qui doit cependant être connu seulement par l'envoyeur et le
destinataire, et qui peut être utilisée plusieurs fois. Mais la clef
d'acquittement doit être différente à chaque fois pour que le destinataire
ne puisse déchiffrer plus d'un cryptogramme ayant un même code donné
d'accusé de réception puique le destinaire demande confirmation à chaque
fois qu'il lui envoie un cryptogramme.
Quant au code de l'accusé de réception que B doit transmettre à A, il
doit être le bon à sa première transmission à A sinon A va suppecter que ce
n'est pas B qui lui communique ce code pour recevoir en retour la bonne clef
d'acquittement; dans ce cas A pourrait annulé le cryptogramme qu'il a envoyé
à A et en envoyer un autre avec un code d'accusé de réception différent du
premier et cela en utilisant la même clef personnelle pour le début du
déchiffrement; ainsi personne ne pourrait décrypter le premier cryptogramme
puisque B a décidé d'annuler l'envoie de la clef d'acquittement à qui que ce
soit; et de toute façon, même si la clef d'acquittement serait connu de
tous, ce premier cryptogramme ne pourrait pas être déchiffrer sans la bonne
clef personnelle connue de A et B pour le début du déchiffrement. Ces 2
clefs doivent donc être exactes pour que le déchiffrement soit complété.

J'aurais d'ailleurs envie de répondre à Raymond H. ceci:
- Blindez correctement votre algorithme, prouvez-le en dehors de la
théorie
sur brouillon, et quand ça marchera vous vous attacherez à nommer les
éléments.
Jusque-là il faut vous attendre à de sérieux remaniements, donc c'est du
temps perdu.


Je suis à l'aboutissement de mon algorithme. Mon premier exposé de
l'algo pour le chiffrement de M est complété, et il me reste le second
exposé pour le chiffrement des infos ajoutés à M (clefs de session, Hash
pour clefs de session non crypté, Hash pour clef de session crypté via la
clef d'acquittement, date, taille du fichier, taille de la fiche d'info,
etc.). J'aurais voulu avoir présenté ces exposés en janvier 2006 mais j'ai
du retard (à cause de certaines logiques à redéfinir, etc.) et je compte
dans peu de temps le partager sur ce groupe en donnant les liens des pages
Web en question.
Bonne journée
Raymond H.


remy
Le #527361
Bonsoir,
"remy" 44479731$0$19676$
Bonjour,
1- A envoie un chiffré à B. B débute le déchiffrement d'un chiffré via
un clef personnelle.
2- Si c'est la bonne clef alors un code (accusé de réception venant du
chiffré) s'affiche. B envoie ce code à A.
3- A envoie une clef de retour pour que B puisse continuer le
déchiffrement du chiffré.

Je voudrais savoir quel nom (ou noms composés, court) donner à cette
clef de retour, un nom qui dit bien ce que c'est. Quelqu'un aurait une
idée?
r.h.
pas tout compris


en gros tu fais "une petite cuisine" pour faire une authentification
de B

A envoie {un fichier+coucou(xor)geneAlea(init b)}

B initialise son geneAlea decode coucou
et envoie coucou a A
ou coucou (xor)geneAlea(int b+"6 tours lies au coucou")


A fait une verif sur coucou et le chifre de B
code la cle(xor)geneAlea(int b+"12 tours lies au 2 coucou")

B decode la cle et decode le fichier avec la cle envoyee par A


j'ai bon ?

Disons que c'est assez simple et compliqué en même temps. Mais je

simplifie en disant que A insère un code crypté dans M (les donnés). A
envoie M à B, et B débute le déchiffrement de M via sa clef habituelle, et
si le Hash des 2 clefs de sessions (intégré dans M) corresponds au 2 clefs
de session servant à déchiffrer M alors le code décrypté s'affiche et B
l'envoie à B. B recoit ce code et c'est la certitude pour B que c'est bien
A qui a reçu ce M. Alors, B envoie à A une clef qui décrypte les 2 clefs de
sessions cryptées (auparavant intégré dans M). C'est via ces 2 clefs de
sessions décryptées par A (par la clef de l'accusé de réception que B vient
d'envoyer à A) que le déchiffrement de M se poursuit avec exactitude.



pas tout compris
je te propose quelque chose de plus simple :-)

fichier+bruit+cle de decryptage crypte=fichier

a envoie le fichier a B

b crypte le bruit avec sa cle privee et le resultat sert a
decrypter la cle de decryptage

donc "dissymétrique, à l'initiative de A."
fan de chi choune




sinon
je propose cle d'acquittement

Merci :-)

J'avais pensé aussi à:
- clef de confirmation
- clef d'accusé de réception
- clef terminale
- clef secondaire
- clef de déblocage
- clef complémentaire
- etc.
Reste à penser au terme qui définirait le mieux pour les simples
d'esprit.
Bonne soirée.
Raymond H.





--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy



Raymond H.
Le #527358
Milles excuses pour mes erreurs d'inattention dans ce que j'ai écris. Je
rectifie...

Disons que c'est assez simple et compliqué en même temps. Mais je
simplifie en disant que A insère un code crypté dans M (les donnés). A
envoie M à B, et B débute le déchiffrement de M via sa clef habituelle, et
si le Hash des 2 clefs de sessions (intégré dans M) corresponds au 2 clefs
de session servant à déchiffrer M alors le code décrypté s'affiche et B
l'envoie à B. B recoit ce code et c'est la certitude pour B que c'est
bien A qui a reçu ce M. Alors, B envoie à A une clef qui décrypte les 2
clefs de sessions cryptées (auparavant intégré dans M). C'est via ces 2
clefs de sessions décryptées par A (par la clef de l'accusé de réception
que B vient d'envoyer à A) que le déchiffrement de M se poursuit avec
exactitude.


...Mais je simplifie en disant que A insère un code crypté dans M (M = les
donnés). A
envoie M crypté à B, et B débute le déchiffrement de M via sa clef
habituelle (connu de A et B), et
si, lors du déchiffrement, le Hash des 2 clefs de sessions (intégrés dans
M) correspond au 2 clefs
de session servant à déchiffrer M au complet alors le code décrypté
s'affiche et B
l'envoie à A. A reçoit ce code et c'est la certitude pour A que c'est bien
B qui a reçu ce M. Alors, A envoie à B une clef unique (clef
d'acquittement) qui décrypte les 2 clefs de
sessions cryptées (déjà intégré dans M). C'est via ces 2 clefs de
sessions décryptées par B (décryptées par la clef d'acquittement que A
vient
d'envoyer à B) que le déchiffrement complet de M se poursuit avec
exactitude.
Raymond H.

Publicité
Poster une réponse
Anonyme