Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

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

13 réponses
Avatar
Raymond H.
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

10 réponses

1 2
Avatar
Raymond H.
Bonjour,
Quelqu'un pourrait-il me dire s'il existe au moins un bon algorithme
connue qui inclue la clef dans le chiffré?
Raymond
Avatar
Johann.D
"Raymond H." a écrit dans le message de
news:K2nBf.8051$
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,
2) si c'est un algorithme par bloc, ça donne une trop belle condition
d'arrêt.

Pourquoi pas insérer un hash du clair pour vérifier qu'on l'a bien restitué
_seulement après avoir traité l'ensemble_ et non pas juste le ou les blocs
contenant la clé ?

Mes 2 centimes.

--
Johann.D

Avatar
Steph
On Sun, 22 Jan 2006 23:28:30 -0500, "Raymond H."
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é ...

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 :
- 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 ...

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 ( il faudra au passage déchiffrer, cela sous entend que la
methode de chiffrement de ta clef repose sur un algorithme restreint
qui ne supportera pas bien longtemps l'examen du source ou le
desassemblage de l'exe par une personne compétente) ? C'est
l'utilisateur qui la choisiera lui même la nouvelle clef ??


qu'elle serait la meilleure solution pour les utilisateurs d'un tel logiciel et pourquoi?


Pour faire plus court :
Ne pas utiliser ce logiciel.

Amicalement :
S.

Avatar
Raymond H.
Bonjour,
Merci pour votre réponse.
"Steph" a écrit dans le message de news:

...
Bonjour,

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

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 :
- 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.


Par exemple, si on chiffre un fichier bmp, la signature du bmp
n'équivaut-elle pas un peu au fait de laisser la clef dans le chiffré?
Puisque la signature du bmp qui serait toujours la même (comme la clef)
pourrait être un point faible pour tenter de casser l'algo.

chiffré et le(pseudo) logiciel ne te demandait même plus la clef ...


Dans ce cas la clef semble avoir été un genre de mot de passe pour
ouvrir une porte pour donner accès au cryptogramme de l'autre côté de cette
porte; cette clef n'influencerait donc pas le chiffré en tant que tel en
sorte de passer par dessus. C'est ce qui me semble.

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 ( il faudra au passage déchiffrer, cela sous entend que la
methode de chiffrement de ta clef repose sur un algorithme restreint
qui ne supportera pas bien longtemps l'examen du source ou le
desassemblage de l'exe par une personne compétente) ? C'est
l'utilisateur qui la choisiera lui même la nouvelle clef ??


Par exemple, si on crypte un chiffré avec la clef 'Bonjour' mais en
faisant une faute de frappe sans s'en rendre compte et qu'on tappe la clef
'Bonpour'. Au lieu de déchiffrer le fichier on le rechiffrerait
différemment et ainsi on perdrait le fichier à toujours si on ne sait pas
qu'elle faute de frappe on a fait quand on a écrit la clef.
Le fait donc de ne pas avoir de clef (clef chiffré) dans le chiffré
cela constituerait un gros désavantage dans le cas de notre exemple d'une
faute de frappe dont on ne connait pas. Mais d'un autre côté, si on inclue
la clef dans le chiffré (à la fin) cela constitue un point d'arrêt qui
ferait sauver du temps pour celui qui fait des testes via une force brute en
C; si c'est la mauvaise clef alors 'stop' et on recommence une autre clef;
celui qui fait cela en language C, en laissant tourner continuellement sa
machine, pourrait en quelques temps, voir même quelques années ouvrir ce
point d'arrêt (disons que c'est ma plus grand hésitation même si on sait que
cela pourrait prendre des sciècles). Sinon, sans clef d'intégrée dans le
chiffré, faudrait procéder par comparaison du dictionnaire si on utilise la
force brute, et cela est beaucoup plus long, un temps très très long
puisqu'en plus d'essayer toutes sortes de clefs il faudrait comparer au
dictionnaire chaque bloc 'déchiffré' pour indiquer que ce sont des mots qui
existent bien.

Présentement, mon algo utilise 2 clefs de session initialement créé
aléatoirement sous l'influence de la clef personnelle, de valeurs générées à
partir de clics de souris et de touches pressées du clavier, et de valeurs
générer par le hasard venant du logiciel, etc.. Cette ensemble de
combinaisons constitue un vrai hasard, puisqu'à eux seuls, les clics de
souris et des touches du claviers pressées constitue des imprévisions dans
le choix des valeurs du Timer (centième de secondes) lui-même (temps du
système: secondes et centième de seconde écoulés depuis minuit; mais seule
la fraction est retenue 'les centièmes de seconde').
Pour faire plus simple à l'avenir, je nomme l'ensemble de ces 2 algos:
'Algo RH'.
Après l'accomplissement du chiffrement des données, un 2e algo chiffre
la clef personnelle (transformée auparavant) et les 2 clefs de sessions
finales: ceci constitue la 2e partie. Ainsi, les 2 clefs de sessions ne
sont jamais les mêmes d'un chiffrement à l'autre même si le clair est le
même; mais la clef personnelle pourrait toujours être la même. Lors du
déchiffrement, on écrit la clef personnelle et alors la 2e partie de l'algo
RH s'exécute pour déchiffrer les 2 clefs de session finales qui à leur tour
sont utilisées par la 1re partie de l'algo RH pour le déchiffrement des
données du fichier à partir de la fin. On a donc 2 clefs de session de la
même longueur que le chiffré mais on en retient que la partie finale pour
faire plus court puisqu'à partir de ces 2 finales on obtient graduellement
la totalité de ces 2 clefs; elle est créée par l'influence du chiffré via un
calcul que j'ai déjà mentionné en partie dans ce groupe il y a près d'un an
déjà.
Présentement, je n'ai pas mis de point d'arrêt dans cette 2e partie
(donc, rien qui dise si on a tappé la bonne clef pour le déchiffrement).

qu'elle serait la meilleure solution pour les utilisateurs d'un tel
logiciel et pourquoi?


Pour faire plus court :
Ne pas utiliser ce logiciel.
Solution assez simple :-)

a+
Raymond


Avatar
Raymond H.
Bonjour,
"Johann.D" a écrit dans le message de
news: 43d60c3c$0$21262$

"Raymond H." a écrit dans le message de
news:K2nBf.8051$
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,


??

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.

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


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

_seulement après avoir traité l'ensemble_ et non pas juste le ou les blocs
contenant la clé ?
a+

Raymond


Avatar
Alain


Par exemple, si on crypte un chiffré avec la clef 'Bonjour' mais en
faisant une faute de frappe sans s'en rendre compte et qu'on tappe la clef
'Bonpour'. Au lieu de déchiffrer le fichier on le rechiffrerait
différemment et ainsi on perdrait le fichier à toujours si on ne sait pas
qu'elle faute de frappe on a fait quand on a écrit la clef.


ce que tu veut c'est vérifier que tu a bien déchiffré le document avec
la bonne clé. la solution habituelle c'est d'ajouter au message clair un
"hash" (une somme de contrôle, de parité, un CRC, un hash MD5,
SHA1...)... mais déjà un simple mot magique en tête suffit, et comme les
format image en ont un il n'y a qu'a vérifier que le document est bien
une image.

Avatar
Sylvain
Raymond H. wrote on 24/01/2006 21:08:

[plein de truc, comme d'hab., ... dont]

Par exemple, si on crypte un chiffré avec la clef 'Bonjour'
mais [] on tape la clef 'Bonpour' [] on le rechiffrerait
différemment et ainsi on perdrait le fichier []


et si, par exemple, tu commençais à lire les normes, par exemple PKCS.7,
tu poserais pas des questions débiles pour que d'autres personnes
réfléchissent à ta place à des basiques, non ?

Sylvain.

Avatar
Arnold McDonald \(AMcD\)
Sylvain wrote:

et si, par exemple, tu commençais à lire les normes, par exemple
PKCS.7, tu poserais pas des questions débiles pour que d'autres
personnes réfléchissent à ta place à des basiques, non ?


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

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/

Avatar
Johann.D
"Steph" a écrit dans le message de
news:
On Sun, 22 Jan 2006 23:28:30 -0500, "Raymond H."
wrote:


<couic />

Rien compris.

Tu veux pas faire une belle page Web avec des schémas et tout et tout,
plutôt que de lancer dans des explications dignes d'un jeu du pays de
Galles, dont seul Perceval connaît les règles (oui, je me doute qu'au Canada
on est loin de connaître Alexandre Astier, mais bon, le rapprochement est
trop tentant). Sans blague, un beau dessin vaut toujours mieux qu'un bon
discours, alors quand en plus le discours est mauvais...

--
Johann.D

Avatar
Johann.D
"Raymond H." a écrit dans le message de
news:d4wBf.6569$
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 ?

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 ?

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


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, 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...

Tu suis toujours ?

--
Johann.D



1 2