Question sur le fait d'insérer une clef dans le chiffré...
Le
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
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
Poser une question
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
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 ??
Pour faire plus court :
Ne pas utiliser ce logiciel.
Amicalement :
S.
Merci pour votre réponse.
"Steph"
...
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.
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.
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).
a+
Raymond
"Johann.D" news: 43d60c3c$0$21262$
??
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.
Pourriez-vous me faire comprendre votre idée par un petit exemple
détaillé? Ca semble bien intéressant comme proposition.
Raymond