Question sur le fait d'insérer une clef dans le chiffré...

Arnold McDonald (AMcD) wrote on 24/01/2006 23:35:

Et dire que je croyais être une des plus grandes gueules de Usenet... Vous
êtes en forme les gars :-).

grandes gueules, tu trouves ?

quand un crétin de première nous balance la top application basée sur:
1) je saisis ma clé au clavier - histoire d'avoir une entropie assez
proche de la température anale d'un rat mort.
2) je nique le chiffré à peine j'ai pondu un peut-être-clair a) sans
conserver la peut-être-clé en RAM, b) sans avoir vérifié le moindre
check digit sur la clé, ni le moindre hash sur le clair et c) sans rien
demander à l'utilisateur
...

on devrait juste avoir envie de le renvoyer d'où il vient (et où il
n'est pas resté assez longtemps) tout en ayant également envie de "Ne
pas utiliser ce logiciel".

Sylvain.

Bonjour,
"Johann.D" <swen-jd-05@cldj.ten.INVALID> a écrit dans le message de news:
43d6bb39$0$18315$8fcfb975@news.wanadoo.fr...

"Raymond H." <divers_rh@hotmail.com> a écrit dans le message de
news:d4wBf.6569$ft2.124014@news20.bellglobal.com...

Bonjour,

Quelqu'un pourrait-il me dire s'il existe au moins un bon
algorithme

connue qui inclue la clef dans le chiffré?
Raymond

AMHA c'est pas une bonne idée pour au moins 2 raisons :
1) c'est inutile pour faire ce que tu souhaites,

??

Ben oui. Si le seul but c'est de vérifier que le fichier est bien
déchiffré,
pas besoin de stocker la clé, il suffit de vérifier que le fichier est
bien
déchiffré. Logique, non ?

Tout à fait.

2) si c'est un algorithme par bloc, ça donne une trop belle condition
d'arrêt.

L'exécution de l'algo se fait par bloc, mais le calcul est
continuel:
autrement dit, on pourrait aussi bien chiffrer par bloc de 512Ko et
déchiffrer ces mêmes données par bloc de 1024Ko ou d'un Mo à la fois.
C'est

COMME si on chiffrerait un fichier d'un Giga octets d'un seul coup, et
pourtant il se chiffre/déchiffre en bloc plus petit pour gagner de la
vitesse et ne pas prendre toute la RAM.

Oui là je suis certain de ne pas comprendre. Faudrait peut-être qu'on
s'accorde sur les bases de vocabulaire, sais-tu ce qu'est un chiffrement
par
bloc ?

Je vais mettre cette explication également sur page Web, car au sein de
chaque bloc qui dépends des autres blocs un minimum de 8 caractètes sont
traités à la fois au minimum à cause des permutations; chaque bloc sont
reliés entre eux. Ceci sera plus clair lorsqu'éventuellement j'aurai donné
les explications détaillées d'ici quelques jours.

Pourquoi pas insérer un hash du clair pour vérifier qu'on l'a bien
restitué

Bonne idée. Je pourrais aussi ne prendre que quelques caractères d'une
des 2 clefs de session initiale qui devraient concorder à la fin du
déchiffrement. Plusieurs questions se posent à mon esprit:
Le nombre de caractères à prendre pour le hash, etc. J'ai pensé 16
caractères du début du clair plus 16 de la fin du clair et insérer cela soit
dans la 1re partie du chiffré ou dans la 2e partie qui indiquerait au début
du déchiffrement si c'est la bonne clef ou non (au lieu de laisser
déchiffrer 500Mo pour se rendre compte qu'à la fin qu'une mauvaise clef a
été utilisée. Donc, ces derniers caractères indiqueraient si on a la bon
clef, et les 1er caractères si le chiffré est intacte du début à la fin.
Ici, je suppose que vous avez lu ce que j'ai écris là dessus ailleurs, mais
je conviens qu'il serait mieux, pour une question de clarté, de mettre mes
explications sur ce groupe ou sur page Web comme vous l'avez suggéré
ailleur; je vais commencer à y travailler dans ces jours-ci; on pourra ainsi
mieux comprendre le procédé de chiffrement.

Pourriez-vous me faire comprendre votre idée par un petit exemple
détaillé? Ca semble bien intéressant comme proposition.

Soit ta fonction de chiffrement y = f(x, z) où z est la clé.
Toi tu proposes de transmettre y' = f(x || z, z) pour retrouver au
déchiffrement x || z = f-1 (y', z) et vérifier ainsi z. Encore faudrait-il
démontrer qu'il n'existe aucun z' tel que x' || z' = f-1 (y', z'), avec x'
!= x, sinon ça n'apporte rien au schmilblick.
Moi je dis, si je transmet y'' = f(x || g(x), z), avec g bien choisie (pas
injective mais presque...), je retrouve au déchiffrement x || g(x) = f-1
(y'', z), et à moins que g ne soit très mal choisit, le schmilblick ne se
porte pas plus mal, voire mieux,

Je suis bien d'accord.

sauf qu'en plus j'ai évité de véhiculer la
clé (même chiffrée) dans le message, ce qui évite déjà à AMcD et tous les
autres attaquants qui frétillent d'impatience devant ton algorithme de
connaître la longueur de la clé à la première seconde. C'est déjà ça, mais
on est encore loin du compte...

Bien pensé. Je pensais aussi à un exemple de développement d'un
hachage dans ce cas particulier, mais votre explication est intéressante,
puisqu'il se pourrait que j'intègre dans la fiche (fic) l'éventuel hash en
question (la fiche serait jointe à 'm' (au clair) pour y être chiffré
ensemble. Mon algo n'utilise pas de clef public et le chiffrement se
résumerait grosso modo à ceci: c = f(m || fic,k) = xor(per(incbro(m ||
fic)), (ses1+ses2) mod 256) ) || f2( k, ses1, ses2) Je vais tenter, d'ici
peu, de donner des explications sur ce groupe ou sur page Web et de voir
quelle formule lui correspondra.
Passez une bonne journée
Raymond

Bonjour,
"Steph" <stephuser@free.fr> a écrit dans le message de news:
9a3ct19tctr0i1bi0kmej94saomeo0nusk@4ax.com...

On Sun, 22 Jan 2006 23:28:30 -0500, "Raymond H."
<divers_rh@hotmail.com> wrote:

Bonjour à tous,
J'aimerais avoir quelques avis concernant le fait d'insérer une clef
dans le chiffré en sorte que si l'on tape la mauvaise clef pour le
déchiffrement cela fait un arrêt donnant un message nous indiquant
d'entrer
la bonne clef. Est-ce une bonne chose d'après vous?
Si le chiffré est de très haute confiance alors pourquoi ne pas
insérer
la clef dans ce chiffré pour la raison cité plus haut?
Existe-t-il un logiciel quelconque utilisant un algo de chiffrage
très
connu comme étant très bien et qui intègre la clef dans le chiffré pour la
raison mentionné plus haut? Si oui, lequel? Si non, cela signifierait
qu'à
chaque fois qu'une mauvaise clef soit entrée alors le chiffré se
chiffrerait
différemment pouvant ainsi perdre définitivement le fichier chiffré
lui-même
si l'utilisateur ne connaît pas l'erreur de frappe qu'il a fait en tapant
la
fausse clef.
Qu'en pensez-vous? Selon vous, qu'elle serait la meilleure solution
pour les utilisateurs d'un tel logiciel et pourquoi?

Raymond

Bonjour,

Tout cela ne semble pas très sain. Ni très clair en réalité ...

Je vais y travailler pour détailler minutieusement l'algorithme d'ici
quelques jours.

L'inclusion de la clef dans ton C c' est super affaiblissant en
espérant qu'elle soit chiffré elle même. D'autres pb sont d'ailleurs
soulevés :

Il est vrai que c'est différent d'un hash venant du clair ou d'une
partie de la clef de session qui n'est jamais utilisé plus d'une fois même
pour le même clair plusieurs fois chiffré.

- Emplacement dans le chiffré
- Clef utilisé pour le chiffrement.

Le plus important c'est la sécurité ! Tu peux utiliser le meilleur
algo immaginable sur ce type d'implémentation les résultats seront
vraissemblablement catastrophiques.

Pour infos, certains programmes shareware étaient protégés par un
système de ce genre "PC info" proposait il y'a dix ans des progs de ce
type, on obtenait par minitel la clef de déchiffrement (J'ose à peine
utiliser ce terme). La clef était bien fondue dans le chiffré (je ne
me souviens plus si CT un H ou réellement la clef mais CT vraiment pas
BO de toutes façons). Ca a été cassé immédiatement. dans les premières
versions il suffisait de déplacer quelques caractères du (pseudo)
chiffré et le(pseudo) logiciel ne te demandait même plus la clef ...

Cela me fait pensé, il y a bien des années, à une personne qui avait
réussie à déjouer les données de passe pour les cartes à puces. Il sautait
par dessus ce genre de clef ou mot de passe et avait accès au données de la
carte en faisant croire à la carte que le mot de passe (ou clef) avait été
accepté.

Tu parles d'un rechiffrement automatique en cas d'une erreur sur la
clef entrée par un utilisateur ... Quelle clef vas tu utiliser pour
rechiffrer

La même clef personnelle est utilisée pour le chiffrement et le
déchiffrement, mais en réalité ce sont 2 clefs de session qui sont créés à
chaque fois pour le chiffrement du message, et ses 2 mêmes clefs de session
sont utilisées pour le déchiffrement; ainsi donc, je dois transformer et
chiffrer ces 2 clefs de session dans un 2e chiffré joint au premier chiffré.
Lors du déchiffrement, on donne la clef personnelle qui à son tour elle
crée, à partir du 2e chiffré, les 2 clefs de session finales qui seront
utilisées pour le déchiffrement du premier chiffré; un calcul inverse se
fait donc sous l'influence du premier chiffré en sorte que les 2 clefs de
session finale sont prolongées inversement jusqu'à ce qu'on atteingne le
début du premier chiffré lors de ce dit déchiffrement.

Bonne journée :)
Raymond