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

Bonjour.

Je réponds à Raymond H. <divers_rh@hotmail.com>

Milles excuses pour mes erreurs d'inattention dans ce que j'ai écris.

Attention aux termes: déchiffrer, décrypter, etc. bref les classiques.

Je vous suggère aussi de faire un scénario ou pseudo-algorithme point par
point en numérotant les points (les numéros peuvent alors servir de
références plus loin), c'est bien plus clair que du texte dans ce domaine.

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.

Vous avez deux points essentiels à clarifier pour l'ensemble de votre
procédure:

1) Quels sont les éléments secrets du protocole, et donc Où, Quand et
Comment ils sont établis,

2) Quel est le domaine d'action du 3ème larron, le fameux E (pour Eve,
eye-dropper, espion ou emmerdeur selon l'inspiration),
... et Comment vous **prouvez** qu'à la fin du cycle il n'en sait pas autant
que A et/ou B sur le message à transmettre et/ou sur la clé qui sert à le
chiffrer (ce qui serait équivalent).
... ceci y compris avec enregistrement et rejeu de la séquence complète a
posteriori, ou une recherche exhaustive si elle reste possible.

C'est un peu là qu'on attend de voir...

Cordialement,

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

Bonjour,
J'en prends note. Merci pour les suggestions :)
r.h.

Salut Raymond !

J'attends avec impatience le petit schéma des familles qui me fera
comprendre d'un seul coup d'oeil le procédé ;-)

Mais j'ai quand même des questions :

...
...Mais je simplifie en disant que A insère un code crypté dans M (M
= les
donnés).

"A insère un code crypté" : ce *chiffré*, il est chiffré avec quoi ?

A envoie M crypté à B, et B débute le déchiffrement de M
via sa clef habituelle (connu de A et B),

Dans l'algorithme, il y a une partie symétrique ? Comment se passe
l'échange de cette clé "habituelle" ? ~ Diffie-Hellman ?

et si, lors du déchiffrement, le Hash des 2 clefs de sessions
(intégrés dans M) correspond au 2 clefs

Plutôt que d'utiliser un condensat (hash) dans un chiffré, pourquoi ne
pas mettre en place l'équivalent d'une signature numérique ?

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 là qu'intervient le dessin dont j'ai parlé plus haut...

--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A

Bonjour Christophe,
Content de vous écrire pour la suite d'il y a plus d'un an déjà :)

"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: 9jv4i3-m9l.ln1@serveur.sbgodin.net...

Salut Raymond !

J'attends avec impatience le petit schéma des familles qui me fera
comprendre d'un seul coup d'oeil le procédé ;-)
:-)

Mais j'ai quand même des questions :

...
...Mais je simplifie en disant que A insère un code crypté dans M (M
= les
donnés).

"A insère un code crypté" : ce *chiffré*, il est chiffré avec quoi ?
J'aurais dû écrire "A insère un code dans M qui sera crypté, donc dans

C". Le code en question est un ensemble de 4 caractères en base 256, donc
avec au-dessus de 4 milliards de possibilités. Mais dans 'C' ces caractères
seraient au total de 8 et en base 16 pour avoir la compatibilité des
caractères dans la fenêtre de texte. J'ai trouvé que 4 caractères étaient
suffisant puisque si B envoie ce code (cette série de caractères) à A et que
ce code n'est pas le bon au premier envoie alors A soupsonnerait que ce
n'est peut-être pas B qui lui écrit; A pourrait rechiffrer M de nouveau et
le renvoyer à B s'il le désire.
Ces 4 caractères ne sont donc pas cryptés en tant que tel mais il sont
cryptés avec les 2 clefs de sessions au chiffrement de M; ce code est donc
avec les données spéciales cryptées et ajoutées à la fin de M crypté.

A envoie M crypté à B, et B débute le déchiffrement de M
via sa clef habituelle (connu de A et B),

Dans l'algorithme, il y a une partie symétrique ? Comment se passe
l'échange de cette clé "habituelle" ? ~ Diffie-Hellman ?

Ici, il est question de la 'phrase de passe' qui est transmisse une
fois pour toutes. Cette clef est choisie soit par A ou par B mais utilisée
(si désiré) à toutes les fois pour les correspondances des C entre A et B ou
entre B et A.

et si, lors du déchiffrement, le Hash des 2 clefs de sessions
(intégrés dans M) correspond au 2 clefs

Plutôt que d'utiliser un condensat (hash) dans un chiffré, pourquoi ne
pas mettre en place l'équivalent d'une signature numérique ?

Serait-ce vraiment plus simple?

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 là qu'intervient le dessin dont j'ai parlé plus haut...

Bonne idée, un dessin serait bien. Ici, lorsque B débute le
déchiffrement de la 2e partie de C (celle qui contient les 2 clefs de
session, les Hashs, etc.), le code de 4 caractères est déchiffré et connue
pour que B le communique à A afin que A envoie en retour à B la clef
d'acquittement qui sert au déchiffrement des 2 clefs de session contenues
dans cette 2e partie de C, cela dans le but d'utiliser ces 2 clefs de
session pour le déchiffrement total de C.

Je suis maintenant prêt à commencer l'exposé de mon algorithme de la 2e
partie de C (celle qui crypte les 2 clefs de session, les Hash, etc. via K).
Dans quelques jours je devrais le mettre sur page web et donner le lien dans
ce groupe.

Bonne soirée :)
Raymond H.

Bonjour Christophe,
Content de vous écrire pour la suite d'il y a plus d'un an déjà :)

Je lis toujours ce forum, et ses auteurs avec, avec intérêt.

"A insère un code crypté" : ce *chiffré*, il est chiffré avec quoi ?
J'aurais dû écrire "A insère un code dans M qui sera crypté, donc dans

C".

Dans ce cas, on pourrait parler d'un condensat calculé à partir de A et
incorporé dans le chiffré. L'algorithme du condensat (MD5,SHA1...)
étant public, la vérification du condensat serait aisé pour le
destinataire et le code n'aurait pas à transiter.

Le code en question est un ensemble de 4 caractères en base 256, donc
avec au-dessus de 4 milliards de possibilités. Mais dans 'C' ces
caractères seraient au total de 8 et en base 16 pour avoir la
compatibilité des caractères dans la fenêtre de texte.

L'entropie reste donc la même. Ne serait-il pas plus simple de tout faire
en binaire puis, à la fin seulement, de transformer le tout en BASE64 ou
en hexadécimal si besoin est ?

...
Ces 4 caractères ne sont donc pas cryptés en tant que tel mais il
sont cryptés avec les 2 clefs de sessions au chiffrement de M; ce code
est donc avec les données spéciales cryptées et ajoutées à la fin
de M crypté.

A mon humble avis, cela est un peu complexe pour une simple somme de
contrôle. Cela risquerait de diminuer la force du chiffrement puisque cet
élément de confort pour les deux protagoniste en deviendrait un aussi
pour un attaquant.

...
Dans l'algorithme, il y a une partie symétrique ? Comment se passe

l'échange de cette clé "habituelle" ? ~ Diffie-Hellman ?

Ici, il est question de la 'phrase de passe' qui est transmisse une
fois pour toutes. Cette clef est choisie soit par A ou par B mais
utilisée (si désiré) à toutes les fois pour les correspondances des
C entre A et B ou entre B et A.

D'accord. On est bien dans un contexte de chiffrement symétrique.

...
Plutôt que d'utiliser un condensat (hash) dans un chiffré, pourquoi
ne pas mettre en place l'équivalent d'une signature numérique ?

Serait-ce vraiment plus simple?

C'est surtout une autre façon de faire. Ce condensat est calculé à
partir d'un algorithme public. Le condensat et le message seraient
ensuite chiffrés ensemble.
Il faudrait que je comprenne plus l'ensemble du crypto-système pour me
faire une idée...

...
C'est là qu'intervient le dessin dont j'ai parlé plus haut...

Bonne idée, un dessin serait bien. Ici, lorsque B débute le
déchiffrement de la 2e partie de C (celle qui contient les 2 clefs de
session, les Hashs, etc.), le code de 4 caractères est déchiffré et
connue pour que B le communique à A afin que A envoie en retour à B la
clef d'acquittement qui sert au déchiffrement des 2 clefs de session
contenues dans cette 2e partie de C, cela dans le but d'utiliser ces 2
clefs de session pour le déchiffrement total de C.

Ca fait, si je ne m'abuse, quelques aller-retour :
A --> B : envoyé du chiffré
A <-- B : déchiffrement partiel puis envoi du "code"
A --> B : envoi de la "clé d'acquittement"

En plus, il y a déchiffrement de deux clés de session servant à
déchiffrer le message lui-même.
Pourquoi deux clefs de session ?

Je suis maintenant prêt à commencer l'exposé de mon algorithme de la
2e partie de C (celle qui crypte les 2 clefs de session, les Hash, etc.
via K). Dans quelques jours je devrais le mettre sur page web et donner
le lien dans ce groupe.

Excellente idée :-) Avec des flèches pour bien comprendre les flux de
données, ce qu'ils contiennent, les traitements faits à chaque étape,
l'ordre des traitements, les besoins et les résultats des processus...

Au plaisir de te relire,

--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A