-> Par ailleurs, j'ai suffisamment prouvé que la "science" pouvait
venir
-> à
-> bout des versions du simple algo. Lis mes calculs, et on discute
le
-> concept.
En plus, vous appelez cela une preuve.
Elle est peut-être fausse cette démonstration, mais il s'agit d'une
"preuve" au sens mathématique et non au sens du détective...
Mais je vois que votre conclusion est erronée concernant (votre
théorie) le fait que vos calculs servent à la cryptanalyse du 'Simple
algo'. Aucune preuve n'est donnée pour prouver que le 'Simple algo' de
cette étape-ci est faible.
Je veux bien m'être trompé. De là à dire que "aucune preuve n'est
donnée" :-(
Je souhaite que nous nous mettions d'accord sur les choses dont nous
parlons. Sur ta proposition, il n'est nul part fait mention explicite d'un
chiffrement avec une phrase de passe.
Examine la fonction de chiffrement dans son ensemble, détermine si elle
correspond à ta decription. Si ce n'est pas le cas, ne lit pas plus loin
et corrige ma formulation.
c : chiffré
m : le clair
k : la clé de chiffrement (la "clé initiale")
f : la fonction de chiffrement
c=f(m,k)
f(m,k) = xor( per(inc(m)),ses(inc(m),k) )
per : permutation des lettres
inc : incrémentation
ses : calcul de la clé de session
c = xor( per(inc(m)),ses(inc(m),k) )
ses(inc(m),k) = xor( c, per(inc(m)) )
k = ses_1( xor( c, per(inc(m)) ) , ses(inc(m),k) )
S'il y a maldone ici, inutile de continuer la lecture puisque le reste
repose sur ces postulats. Dans ce cas, corrige et reposte.Donc via '+Var1(x+1)':
Quelle est la syntaxe/sémantique de cette expression ? D'où vient le "x" ?
...
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.Cryptanalyse :
Ce qui suit n'est pas de la cryptanalyse.
"La cryptanalyse est tout simplement l'art de rendre clair un texte
crypté sans avoir connaissance de la clef utilisée.
http://mantis.free.fr/articles/analyse.htm " Or, vos effort sont pour
prouver qu'il est possible de connaître la clef à partir du CLAIR
DÉJÀ CONNU.
C'est rigoureusement exact. La bonne expressions est "attaque avec clair
connu"....
Je veux dire que casser le 'Simple algo' signifie trouver le clair;
mais ici on aurait déjà le clair, donc le reste ne sert plus à rien
et le 'Simple algo' à cette étape-ci reste fort. Hé oui! Jusqu'à
preuve du contraire :-)
Pas au sens que je martèle depuis longtemps déjà : sur une attaque à
clair connu. Ma position n'a jamais changé.Alors, pourquoi tenter de trouver la clef initiale à partir de ce
clair? Cette clef n'est plus utilisable et est jetable. Il serait
préférable de la laisser à la poubelle ;-) Je vous taquine :-)
Les spécifications de l'algorithme telles que je les donne au début de
ce post et, normalement, sont telles que tu me les a décrits. J'ignore
les éventualités futures ou fonctions non-implémentées.
Le point d'attaque reste obligatoirement cette clé, qu'un utilisateur
pourrait rejouer. Maintenant, s'il s'avérait que tu avais
malencontreusement oublié de préciser _concrètement_ le tarabiscotage
de cette clé, complète.Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors,
je suis bêtement la doctrine...
Mais, cette doctrine n'est pas applicable à l'algo de Vernam, le seul
algo indéchiffrable, donc le seul algo qui vaudrait le coup à 100% :-)
En fait, dans ladite doctrine, il est supposé que le mot de passe peut
être rejoué par l'utilisateur. Un algo possédant cette faiblesse se
voit interdit d'utiliser deux fois de suite la même clé.Le 'Simple algo' est inspiré de celui de Varnam et est un crypto
système à clef jetable, donc inutile de ramasser les clefs à la
poubelle ;-)
Soit tu obliges tes utilisateurs à changer de clé à chaque utilisation
et ton produit n'est pas utilisable dans la pratique, soit il y a un truc
supplémentaire qui te fait voir cette clé comme une clé de session mais
il n'y en a pas d'indication concrète dans tes étapes de calcul.Pas d'accord. Vu l'empilement de calculs, ça commence à faire un peu
long pour moi. Le principe d'une attaque à clair connu est que,
justement, on a tout le clair. Pas une partie.
Si vous voulez dire qu'il vous faut tout le clair avant de tenter
une attaque à clair connu, alors ce principe ne s'applique pas au
'Simple algo' de cette étape-ci, et pas plus à l'algo de Vernam.
Puisque ce sont deux systèmes à 'clef jetable' (One time pad). Du
même coup ce principe ne s'appliquera pas à AllCrypter si celui-ci,
dans sa version 3, tire son inspiration de cette étape-ci.
A moins d'obliger tes utilisateurs à changer de clé, il faudra bien
qu'il y ait une clé - information connue des correspondants seuls - qui
ne change pas. Ici, je n'ai que la clé "initiale".Mais, j'avais pensé que vous demanderiez un chiffré et une partie
de son clair (les premier caractères du clair) qui correspond à la
même longueur que la clef de session initiale. Cela aurait été
équitable pour tenter de trouver le clair au complet afin de prouver si
oui ou non c'est possible.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé. Dans cette nouvelle version, soit
je refais mes calculs au détail, soit je choisis le clair en entier
pour faire plus simple histoire de gagner du temps.
Ton exposé était très long. J'ai du mal à te suivre, alors j'avoue en
avoir zappé une partie. Je préfère une formulation bien théorique
qu'une suite longue d'explication en langue française qui est peu
adaptée aux calculs formels.
Cordialement,
--
Christophe HENRY
(sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
-> Par ailleurs, j'ai suffisamment prouvé que la "science" pouvait
venir
-> à
-> bout des versions du simple algo. Lis mes calculs, et on discute
le
-> concept.
En plus, vous appelez cela une preuve.
Elle est peut-être fausse cette démonstration, mais il s'agit d'une
"preuve" au sens mathématique et non au sens du détective...
Mais je vois que votre conclusion est erronée concernant (votre
théorie) le fait que vos calculs servent à la cryptanalyse du 'Simple
algo'. Aucune preuve n'est donnée pour prouver que le 'Simple algo' de
cette étape-ci est faible.
Je veux bien m'être trompé. De là à dire que "aucune preuve n'est
donnée" :-(
Je souhaite que nous nous mettions d'accord sur les choses dont nous
parlons. Sur ta proposition, il n'est nul part fait mention explicite d'un
chiffrement avec une phrase de passe.
Examine la fonction de chiffrement dans son ensemble, détermine si elle
correspond à ta decription. Si ce n'est pas le cas, ne lit pas plus loin
et corrige ma formulation.
c : chiffré
m : le clair
k : la clé de chiffrement (la "clé initiale")
f : la fonction de chiffrement
c=f(m,k)
f(m,k) = xor( per(inc(m)),ses(inc(m),k) )
per : permutation des lettres
inc : incrémentation
ses : calcul de la clé de session
c = xor( per(inc(m)),ses(inc(m),k) )
ses(inc(m),k) = xor( c, per(inc(m)) )
k = ses_1( xor( c, per(inc(m)) ) , ses(inc(m),k) )
S'il y a maldone ici, inutile de continuer la lecture puisque le reste
repose sur ces postulats. Dans ce cas, corrige et reposte.
Donc via '+Var1(x+1)':
Quelle est la syntaxe/sémantique de cette expression ? D'où vient le "x" ?
...
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Cryptanalyse :
Ce qui suit n'est pas de la cryptanalyse.
"La cryptanalyse est tout simplement l'art de rendre clair un texte
crypté sans avoir connaissance de la clef utilisée.
http://mantis.free.fr/articles/analyse.htm " Or, vos effort sont pour
prouver qu'il est possible de connaître la clef à partir du CLAIR
DÉJÀ CONNU.
C'est rigoureusement exact. La bonne expressions est "attaque avec clair
connu".
...
Je veux dire que casser le 'Simple algo' signifie trouver le clair;
mais ici on aurait déjà le clair, donc le reste ne sert plus à rien
et le 'Simple algo' à cette étape-ci reste fort. Hé oui! Jusqu'à
preuve du contraire :-)
Pas au sens que je martèle depuis longtemps déjà : sur une attaque à
clair connu. Ma position n'a jamais changé.
Alors, pourquoi tenter de trouver la clef initiale à partir de ce
clair? Cette clef n'est plus utilisable et est jetable. Il serait
préférable de la laisser à la poubelle ;-) Je vous taquine :-)
Les spécifications de l'algorithme telles que je les donne au début de
ce post et, normalement, sont telles que tu me les a décrits. J'ignore
les éventualités futures ou fonctions non-implémentées.
Le point d'attaque reste obligatoirement cette clé, qu'un utilisateur
pourrait rejouer. Maintenant, s'il s'avérait que tu avais
malencontreusement oublié de préciser _concrètement_ le tarabiscotage
de cette clé, complète.
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors,
je suis bêtement la doctrine...
Mais, cette doctrine n'est pas applicable à l'algo de Vernam, le seul
algo indéchiffrable, donc le seul algo qui vaudrait le coup à 100% :-)
En fait, dans ladite doctrine, il est supposé que le mot de passe peut
être rejoué par l'utilisateur. Un algo possédant cette faiblesse se
voit interdit d'utiliser deux fois de suite la même clé.
Le 'Simple algo' est inspiré de celui de Varnam et est un crypto
système à clef jetable, donc inutile de ramasser les clefs à la
poubelle ;-)
Soit tu obliges tes utilisateurs à changer de clé à chaque utilisation
et ton produit n'est pas utilisable dans la pratique, soit il y a un truc
supplémentaire qui te fait voir cette clé comme une clé de session mais
il n'y en a pas d'indication concrète dans tes étapes de calcul.
Pas d'accord. Vu l'empilement de calculs, ça commence à faire un peu
long pour moi. Le principe d'une attaque à clair connu est que,
justement, on a tout le clair. Pas une partie.
Si vous voulez dire qu'il vous faut tout le clair avant de tenter
une attaque à clair connu, alors ce principe ne s'applique pas au
'Simple algo' de cette étape-ci, et pas plus à l'algo de Vernam.
Puisque ce sont deux systèmes à 'clef jetable' (One time pad). Du
même coup ce principe ne s'appliquera pas à AllCrypter si celui-ci,
dans sa version 3, tire son inspiration de cette étape-ci.
A moins d'obliger tes utilisateurs à changer de clé, il faudra bien
qu'il y ait une clé - information connue des correspondants seuls - qui
ne change pas. Ici, je n'ai que la clé "initiale".
Mais, j'avais pensé que vous demanderiez un chiffré et une partie
de son clair (les premier caractères du clair) qui correspond à la
même longueur que la clef de session initiale. Cela aurait été
équitable pour tenter de trouver le clair au complet afin de prouver si
oui ou non c'est possible.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé. Dans cette nouvelle version, soit
je refais mes calculs au détail, soit je choisis le clair en entier
pour faire plus simple histoire de gagner du temps.
Ton exposé était très long. J'ai du mal à te suivre, alors j'avoue en
avoir zappé une partie. Je préfère une formulation bien théorique
qu'une suite longue d'explication en langue française qui est peu
adaptée aux calculs formels.
Cordialement,
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
-> Par ailleurs, j'ai suffisamment prouvé que la "science" pouvait
venir
-> à
-> bout des versions du simple algo. Lis mes calculs, et on discute
le
-> concept.
En plus, vous appelez cela une preuve.
Elle est peut-être fausse cette démonstration, mais il s'agit d'une
"preuve" au sens mathématique et non au sens du détective...
Mais je vois que votre conclusion est erronée concernant (votre
théorie) le fait que vos calculs servent à la cryptanalyse du 'Simple
algo'. Aucune preuve n'est donnée pour prouver que le 'Simple algo' de
cette étape-ci est faible.
Je veux bien m'être trompé. De là à dire que "aucune preuve n'est
donnée" :-(
Je souhaite que nous nous mettions d'accord sur les choses dont nous
parlons. Sur ta proposition, il n'est nul part fait mention explicite d'un
chiffrement avec une phrase de passe.
Examine la fonction de chiffrement dans son ensemble, détermine si elle
correspond à ta decription. Si ce n'est pas le cas, ne lit pas plus loin
et corrige ma formulation.
c : chiffré
m : le clair
k : la clé de chiffrement (la "clé initiale")
f : la fonction de chiffrement
c=f(m,k)
f(m,k) = xor( per(inc(m)),ses(inc(m),k) )
per : permutation des lettres
inc : incrémentation
ses : calcul de la clé de session
c = xor( per(inc(m)),ses(inc(m),k) )
ses(inc(m),k) = xor( c, per(inc(m)) )
k = ses_1( xor( c, per(inc(m)) ) , ses(inc(m),k) )
S'il y a maldone ici, inutile de continuer la lecture puisque le reste
repose sur ces postulats. Dans ce cas, corrige et reposte.Donc via '+Var1(x+1)':
Quelle est la syntaxe/sémantique de cette expression ? D'où vient le "x" ?
...
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.Cryptanalyse :
Ce qui suit n'est pas de la cryptanalyse.
"La cryptanalyse est tout simplement l'art de rendre clair un texte
crypté sans avoir connaissance de la clef utilisée.
http://mantis.free.fr/articles/analyse.htm " Or, vos effort sont pour
prouver qu'il est possible de connaître la clef à partir du CLAIR
DÉJÀ CONNU.
C'est rigoureusement exact. La bonne expressions est "attaque avec clair
connu"....
Je veux dire que casser le 'Simple algo' signifie trouver le clair;
mais ici on aurait déjà le clair, donc le reste ne sert plus à rien
et le 'Simple algo' à cette étape-ci reste fort. Hé oui! Jusqu'à
preuve du contraire :-)
Pas au sens que je martèle depuis longtemps déjà : sur une attaque à
clair connu. Ma position n'a jamais changé.Alors, pourquoi tenter de trouver la clef initiale à partir de ce
clair? Cette clef n'est plus utilisable et est jetable. Il serait
préférable de la laisser à la poubelle ;-) Je vous taquine :-)
Les spécifications de l'algorithme telles que je les donne au début de
ce post et, normalement, sont telles que tu me les a décrits. J'ignore
les éventualités futures ou fonctions non-implémentées.
Le point d'attaque reste obligatoirement cette clé, qu'un utilisateur
pourrait rejouer. Maintenant, s'il s'avérait que tu avais
malencontreusement oublié de préciser _concrètement_ le tarabiscotage
de cette clé, complète.Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors,
je suis bêtement la doctrine...
Mais, cette doctrine n'est pas applicable à l'algo de Vernam, le seul
algo indéchiffrable, donc le seul algo qui vaudrait le coup à 100% :-)
En fait, dans ladite doctrine, il est supposé que le mot de passe peut
être rejoué par l'utilisateur. Un algo possédant cette faiblesse se
voit interdit d'utiliser deux fois de suite la même clé.Le 'Simple algo' est inspiré de celui de Varnam et est un crypto
système à clef jetable, donc inutile de ramasser les clefs à la
poubelle ;-)
Soit tu obliges tes utilisateurs à changer de clé à chaque utilisation
et ton produit n'est pas utilisable dans la pratique, soit il y a un truc
supplémentaire qui te fait voir cette clé comme une clé de session mais
il n'y en a pas d'indication concrète dans tes étapes de calcul.Pas d'accord. Vu l'empilement de calculs, ça commence à faire un peu
long pour moi. Le principe d'une attaque à clair connu est que,
justement, on a tout le clair. Pas une partie.
Si vous voulez dire qu'il vous faut tout le clair avant de tenter
une attaque à clair connu, alors ce principe ne s'applique pas au
'Simple algo' de cette étape-ci, et pas plus à l'algo de Vernam.
Puisque ce sont deux systèmes à 'clef jetable' (One time pad). Du
même coup ce principe ne s'appliquera pas à AllCrypter si celui-ci,
dans sa version 3, tire son inspiration de cette étape-ci.
A moins d'obliger tes utilisateurs à changer de clé, il faudra bien
qu'il y ait une clé - information connue des correspondants seuls - qui
ne change pas. Ici, je n'ai que la clé "initiale".Mais, j'avais pensé que vous demanderiez un chiffré et une partie
de son clair (les premier caractères du clair) qui correspond à la
même longueur que la clef de session initiale. Cela aurait été
équitable pour tenter de trouver le clair au complet afin de prouver si
oui ou non c'est possible.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé. Dans cette nouvelle version, soit
je refais mes calculs au détail, soit je choisis le clair en entier
pour faire plus simple histoire de gagner du temps.
Ton exposé était très long. J'ai du mal à te suivre, alors j'avoue en
avoir zappé une partie. Je préfère une formulation bien théorique
qu'une suite longue d'explication en langue française qui est peu
adaptée aux calculs formels.
Cordialement,
--
Christophe HENRY
(sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Je souhaite que nous nous mettions d'accord sur les choses dont nous
parlons. Sur ta proposition, il n'est nul part fait mention explicite d'un
chiffrement avec une phrase de passe.
Exact. La phrase de passe est sous-entendue depuis plusieurs semaines.
La phrase de passe et le code d'identification ne font pas encore partie
intégrante de l'algo à cette étape-ci, pour éviter des confusions dans la
compréhension vu qu'on est pas encore à cette étape-là. Je voudrais traiter
du sujet de la phrase de passe et du code d'indentification après la
conclusion de cette étape-ci.
k : la clé de chiffrement (la "clé initiale")
k = clef de chiffrement, donc la clef de session complète. Elle inclue
donc aussi la clef de session initiale (ki) et la clef de session finale
(kf).
ki = clef de session initiale.
kf = clef de session finale.
c=f(m,k)
c=f(Clair3,k) car 'm = m1 = Clair1'. Donc, 'c=f(per(inc(m1)),k)' ou
'c=f(m3,k)'
Donc, f chiffre Clair3 en l'xorisant avec k pour donner c.
f(m,k) = xor( per(inc(m)),ses(inc(m),k) )
f(m3,k) = xor(per(inc(m1)), ses(inc(m1),ki))
k = ses_1( xor( c, per(inc(m)) ) , ses(inc(m),k) )
Erreur.
Quelle est la syntaxe/sémantique de cette expression ? D'où vient le "x" ?
Disons que je vais simplifier à la manière du langage C: Var1++ (ou
de VB: Var1 = Var1 + 1).
D'accord. J'arrête ici et je reposte pour correction.Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
...
Je souhaite que nous nous mettions d'accord sur les choses dont nous
parlons. Sur ta proposition, il n'est nul part fait mention explicite d'un
chiffrement avec une phrase de passe.
Exact. La phrase de passe est sous-entendue depuis plusieurs semaines.
La phrase de passe et le code d'identification ne font pas encore partie
intégrante de l'algo à cette étape-ci, pour éviter des confusions dans la
compréhension vu qu'on est pas encore à cette étape-là. Je voudrais traiter
du sujet de la phrase de passe et du code d'indentification après la
conclusion de cette étape-ci.
k : la clé de chiffrement (la "clé initiale")
k = clef de chiffrement, donc la clef de session complète. Elle inclue
donc aussi la clef de session initiale (ki) et la clef de session finale
(kf).
ki = clef de session initiale.
kf = clef de session finale.
c=f(m,k)
c=f(Clair3,k) car 'm = m1 = Clair1'. Donc, 'c=f(per(inc(m1)),k)' ou
'c=f(m3,k)'
Donc, f chiffre Clair3 en l'xorisant avec k pour donner c.
f(m,k) = xor( per(inc(m)),ses(inc(m),k) )
f(m3,k) = xor(per(inc(m1)), ses(inc(m1),ki))
k = ses_1( xor( c, per(inc(m)) ) , ses(inc(m),k) )
Erreur.
Quelle est la syntaxe/sémantique de cette expression ? D'où vient le "x" ?
Disons que je vais simplifier à la manière du langage C: Var1++ (ou
de VB: Var1 = Var1 + 1).
D'accord. J'arrête ici et je reposte pour correction.
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
...
Je souhaite que nous nous mettions d'accord sur les choses dont nous
parlons. Sur ta proposition, il n'est nul part fait mention explicite d'un
chiffrement avec une phrase de passe.
Exact. La phrase de passe est sous-entendue depuis plusieurs semaines.
La phrase de passe et le code d'identification ne font pas encore partie
intégrante de l'algo à cette étape-ci, pour éviter des confusions dans la
compréhension vu qu'on est pas encore à cette étape-là. Je voudrais traiter
du sujet de la phrase de passe et du code d'indentification après la
conclusion de cette étape-ci.
k : la clé de chiffrement (la "clé initiale")
k = clef de chiffrement, donc la clef de session complète. Elle inclue
donc aussi la clef de session initiale (ki) et la clef de session finale
(kf).
ki = clef de session initiale.
kf = clef de session finale.
c=f(m,k)
c=f(Clair3,k) car 'm = m1 = Clair1'. Donc, 'c=f(per(inc(m1)),k)' ou
'c=f(m3,k)'
Donc, f chiffre Clair3 en l'xorisant avec k pour donner c.
f(m,k) = xor( per(inc(m)),ses(inc(m),k) )
f(m3,k) = xor(per(inc(m1)), ses(inc(m1),ki))
k = ses_1( xor( c, per(inc(m)) ) , ses(inc(m),k) )
Erreur.
Quelle est la syntaxe/sémantique de cette expression ? D'où vient le "x" ?
Disons que je vais simplifier à la manière du langage C: Var1++ (ou
de VB: Var1 = Var1 + 1).
D'accord. J'arrête ici et je reposte pour correction.Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
...
...
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Le point d'attaque reste obligatoirement cette clé, qu'un utilisateur
pourrait rejouer.
Maintenant, s'il s'avérait que tu avais
malencontreusement oublié de préciser _concrètement_ le tarabiscotage
de cette clé, complète.
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors,
je suis bêtement la doctrine...
Mais, cette doctrine n'est pas applicable à l'algo de Vernam, le seul
algo indéchiffrable, donc le seul algo qui vaudrait le coup à 100% :-)
En fait, dans ladite doctrine, il est supposé que le mot de passe peut
être rejoué par l'utilisateur.
Soit tu obliges tes utilisateurs à changer de clé à chaque utilisation
et ton produit n'est pas utilisable dans la pratique, soit il y a un truc
supplémentaire qui te fait voir cette clé comme une clé de session mais
il n'y en a pas d'indication concrète dans tes étapes de calcul.
A moins d'obliger tes utilisateurs à changer de clé, il faudra bien
qu'il y ait une clé - information connue des correspondants seuls - qui
ne change pas. Ici, je n'ai que la clé "initiale".
Mais, j'avais pensé que vous demanderiez un chiffré et une partie
de son clair (les premier caractères du clair) qui correspond à la
même longueur que la clef de session initiale. Cela aurait été
équitable pour tenter de trouver le clair au complet afin de prouver si
oui ou non c'est possible.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé.
...
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Le point d'attaque reste obligatoirement cette clé, qu'un utilisateur
pourrait rejouer.
Maintenant, s'il s'avérait que tu avais
malencontreusement oublié de préciser _concrètement_ le tarabiscotage
de cette clé, complète.
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors,
je suis bêtement la doctrine...
Mais, cette doctrine n'est pas applicable à l'algo de Vernam, le seul
algo indéchiffrable, donc le seul algo qui vaudrait le coup à 100% :-)
En fait, dans ladite doctrine, il est supposé que le mot de passe peut
être rejoué par l'utilisateur.
Soit tu obliges tes utilisateurs à changer de clé à chaque utilisation
et ton produit n'est pas utilisable dans la pratique, soit il y a un truc
supplémentaire qui te fait voir cette clé comme une clé de session mais
il n'y en a pas d'indication concrète dans tes étapes de calcul.
A moins d'obliger tes utilisateurs à changer de clé, il faudra bien
qu'il y ait une clé - information connue des correspondants seuls - qui
ne change pas. Ici, je n'ai que la clé "initiale".
Mais, j'avais pensé que vous demanderiez un chiffré et une partie
de son clair (les premier caractères du clair) qui correspond à la
même longueur que la clef de session initiale. Cela aurait été
équitable pour tenter de trouver le clair au complet afin de prouver si
oui ou non c'est possible.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé.
...
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Le point d'attaque reste obligatoirement cette clé, qu'un utilisateur
pourrait rejouer.
Maintenant, s'il s'avérait que tu avais
malencontreusement oublié de préciser _concrètement_ le tarabiscotage
de cette clé, complète.
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors,
je suis bêtement la doctrine...
Mais, cette doctrine n'est pas applicable à l'algo de Vernam, le seul
algo indéchiffrable, donc le seul algo qui vaudrait le coup à 100% :-)
En fait, dans ladite doctrine, il est supposé que le mot de passe peut
être rejoué par l'utilisateur.
Soit tu obliges tes utilisateurs à changer de clé à chaque utilisation
et ton produit n'est pas utilisable dans la pratique, soit il y a un truc
supplémentaire qui te fait voir cette clé comme une clé de session mais
il n'y en a pas d'indication concrète dans tes étapes de calcul.
A moins d'obliger tes utilisateurs à changer de clé, il faudra bien
qu'il y ait une clé - information connue des correspondants seuls - qui
ne change pas. Ici, je n'ai que la clé "initiale".
Mais, j'avais pensé que vous demanderiez un chiffré et une partie
de son clair (les premier caractères du clair) qui correspond à la
même longueur que la clef de session initiale. Cela aurait été
équitable pour tenter de trouver le clair au complet afin de prouver si
oui ou non c'est possible.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé.
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Oui, et la clef qu'un utilisateur pourrait rejouer, ou réutiliser est la
phrase de passe qui est sa clef personnelle et non la clef de session
(initiale) que l'algo génère à chaque chiffrage. Mais cette phrase de passe
ferait l'objet d'une étape future (après cette étape-ci).
Le but de la phrase de passe est de générer un code d'identification qui
servirait à identifier si c'est la bonne phrase de passe que l'utilisateur a
tapé au début d'une chiffrement, et si cette phrase de passe correspond bien
au code identification alors le processus de déchiffrement est accepté.
...
Mais la phrase de passe ne fait pas l'objet de cette étape-ci.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé.
Je pense qu'à cette étape-ci, serait de trouver la clef initiale
à partir des premiers octets connus du clair.
...
C'est pour cela que je fais une incrémentation du clair (pour donner
Clair2) et une permutation du Clair2 (pour donner Clair3); c'est pour
cela que je crée la clef de session complète à partir de Clair2 et
non à partir de Clair3 qui lui, est xorisé avec la clef de session
complète pour donner le chiffré. Je crée donc une confusion en
créant des inconnus.
...
sinon je pense qu'à cette étape-ci il n'y a plus rien à faire.
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Oui, et la clef qu'un utilisateur pourrait rejouer, ou réutiliser est la
phrase de passe qui est sa clef personnelle et non la clef de session
(initiale) que l'algo génère à chaque chiffrage. Mais cette phrase de passe
ferait l'objet d'une étape future (après cette étape-ci).
Le but de la phrase de passe est de générer un code d'identification qui
servirait à identifier si c'est la bonne phrase de passe que l'utilisateur a
tapé au début d'une chiffrement, et si cette phrase de passe correspond bien
au code identification alors le processus de déchiffrement est accepté.
...
Mais la phrase de passe ne fait pas l'objet de cette étape-ci.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé.
Je pense qu'à cette étape-ci, serait de trouver la clef initiale
à partir des premiers octets connus du clair.
...
C'est pour cela que je fais une incrémentation du clair (pour donner
Clair2) et une permutation du Clair2 (pour donner Clair3); c'est pour
cela que je crée la clef de session complète à partir de Clair2 et
non à partir de Clair3 qui lui, est xorisé avec la clef de session
complète pour donner le chiffré. Je crée donc une confusion en
créant des inconnus.
...
sinon je pense qu'à cette étape-ci il n'y a plus rien à faire.
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Oui, et la clef qu'un utilisateur pourrait rejouer, ou réutiliser est la
phrase de passe qui est sa clef personnelle et non la clef de session
(initiale) que l'algo génère à chaque chiffrage. Mais cette phrase de passe
ferait l'objet d'une étape future (après cette étape-ci).
Le but de la phrase de passe est de générer un code d'identification qui
servirait à identifier si c'est la bonne phrase de passe que l'utilisateur a
tapé au début d'une chiffrement, et si cette phrase de passe correspond bien
au code identification alors le processus de déchiffrement est accepté.
...
Mais la phrase de passe ne fait pas l'objet de cette étape-ci.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé.
Je pense qu'à cette étape-ci, serait de trouver la clef initiale
à partir des premiers octets connus du clair.
...
C'est pour cela que je fais une incrémentation du clair (pour donner
Clair2) et une permutation du Clair2 (pour donner Clair3); c'est pour
cela que je crée la clef de session complète à partir de Clair2 et
non à partir de Clair3 qui lui, est xorisé avec la clef de session
complète pour donner le chiffré. Je crée donc une confusion en
créant des inconnus.
...
sinon je pense qu'à cette étape-ci il n'y a plus rien à faire.
Je souhaite que nous nous mettions d'accord sur les choses dont nous
parlons. Sur ta proposition, il n'est nul part fait mention explicite
d'un
chiffrement avec une phrase de passe.
Exact. La phrase de passe est sous-entendue depuis plusieurs
semaines.
La phrase de passe et le code d'identification ne font pas encore partie
intégrante de l'algo à cette étape-ci, pour éviter des confusions dans la
compréhension vu qu'on est pas encore à cette étape-là. Je voudrais
traiter
du sujet de la phrase de passe et du code d'indentification après la
conclusion de cette étape-ci.
Non. Ou alors, je vais sous-entendre que cette phrase de passe est
devinable et que j'aurais accès aux données qu'ils protègent. Mais tu
répondras peut-être que ce chiffrement de clé de session par cette
phrase de passe est inviolable.
Du concret ! Considère que je ne suis pas beaucoup plus intelligent que
la machine que j'utilise. Je ne sais traiter que les choses tangibles.
k : la clé de chiffrement (la "clé initiale")
k = clef de chiffrement, donc la clef de session complète. Elle
inclue
donc aussi la clef de session initiale (ki) et la clef de session finale
(kf).
ki = clef de session initiale.
kf = clef de session finale.
Etant donné que tu réserves 'k' (la clé fournie par l'utilisateur) pour
la phrase de passe de l'utilisateur et que le 'k' que j'ai défini n'est
qu'une clé de _s_ession, je te propose de renommer tout cela en 's', 'si'
et 'sf'.
c=f(m,k)
c=f(Clair3,k) car 'm = m1 = Clair1'. Donc, 'c=f(per(inc(m1)),k)' ou
'c=f(m3,k)'
Donc, f chiffre Clair3 en l'xorisant avec k pour donner c.
Pas du tout. 'f' est une fonction qui - pour le moment - prends en
paramètres les données externes du chiffrement : le clair et la clé. En
reformulant, cela donne :
c = f(m , k) = xor( per(inc( m)) , ses(inc( m), k) )
où
c = f(m1,ki) = xor( per(inc(m1)) , ses(inc(m1),ki) )
Ceci dit, je n'aime pas vraiment compliquer l'écriture du clair qui est
traditionnelement désigné par 'm'. 'Clair1', 'Clair2', 'm1', 'm2', etc.
Ne sont plus des clairs puisque ce sont des sous-calculs du chiffrement.
Pourquoi pas 'r1', 'r2', etc. en tant que _r_ésultats ?
f(m,k) = xor( per(inc(m)),ses(inc(m),k) )
f(m3,k) = xor(per(inc(m1)), ses(inc(m1),ki))
Ca ne va pas, là. La fonctionn est sensée donner un résultat qui est
fonction des paramètres 'm3' et 'k'. Or non-seulement on ne retrouve pas
'm3' mais il y a en plus un 'm1' qui n'est pas défini.
k = ses_1( xor( c, per(inc(m)) ) , ses(inc(m),k) )
Erreur.
Effectivement. Ecrit un peu vite :-/
ki = ses_1( xor(c,per(inc(m))) )
En rappelant qu'obtenir la clé initiale à partir de la clé de session
est simple puisqu'il suffit de ne garder que les premiers octets. La
fonction 'ses_1()' (réciproque de 'ses()') n'utilise donc qu'un seul
paramètre.
Si tu es d'accord avec cette dernière équation, tu comprendra
Règle ton horloge ! Tu réponds vers 19:04 à un message que j'ai posté
à 22:50.
Si je prends un peu d'avance, je vais désigner par 's' la clé de session
(actuellement 'k') et par 'k' la phrase de passe. 'm' est toujours le
clair, et le chiffré.
c = f(m,k) = xor( per(inc( m)) , s ) || p(s,k)
avec s = ses(inc(m),k)
Le chiffré est le résultat de la fonction f() utilisant le clair 'm' et
la phrase de passe (la _k_lé). Le résultat est la délivrance de deux
données (unies avec || ), la première étant familière et la deuxième
consistant en le chiffrement de la clé de session 's' au moyen d'un
algorithme désigné par la fonction p() prenant également la phrase de
passe 'k' de l'utilisateur.
Je souhaite que nous nous mettions d'accord sur les choses dont nous
parlons. Sur ta proposition, il n'est nul part fait mention explicite
d'un
chiffrement avec une phrase de passe.
Exact. La phrase de passe est sous-entendue depuis plusieurs
semaines.
La phrase de passe et le code d'identification ne font pas encore partie
intégrante de l'algo à cette étape-ci, pour éviter des confusions dans la
compréhension vu qu'on est pas encore à cette étape-là. Je voudrais
traiter
du sujet de la phrase de passe et du code d'indentification après la
conclusion de cette étape-ci.
Non. Ou alors, je vais sous-entendre que cette phrase de passe est
devinable et que j'aurais accès aux données qu'ils protègent. Mais tu
répondras peut-être que ce chiffrement de clé de session par cette
phrase de passe est inviolable.
Du concret ! Considère que je ne suis pas beaucoup plus intelligent que
la machine que j'utilise. Je ne sais traiter que les choses tangibles.
k : la clé de chiffrement (la "clé initiale")
k = clef de chiffrement, donc la clef de session complète. Elle
inclue
donc aussi la clef de session initiale (ki) et la clef de session finale
(kf).
ki = clef de session initiale.
kf = clef de session finale.
Etant donné que tu réserves 'k' (la clé fournie par l'utilisateur) pour
la phrase de passe de l'utilisateur et que le 'k' que j'ai défini n'est
qu'une clé de _s_ession, je te propose de renommer tout cela en 's', 'si'
et 'sf'.
c=f(m,k)
c=f(Clair3,k) car 'm = m1 = Clair1'. Donc, 'c=f(per(inc(m1)),k)' ou
'c=f(m3,k)'
Donc, f chiffre Clair3 en l'xorisant avec k pour donner c.
Pas du tout. 'f' est une fonction qui - pour le moment - prends en
paramètres les données externes du chiffrement : le clair et la clé. En
reformulant, cela donne :
c = f(m , k) = xor( per(inc( m)) , ses(inc( m), k) )
où
c = f(m1,ki) = xor( per(inc(m1)) , ses(inc(m1),ki) )
Ceci dit, je n'aime pas vraiment compliquer l'écriture du clair qui est
traditionnelement désigné par 'm'. 'Clair1', 'Clair2', 'm1', 'm2', etc.
Ne sont plus des clairs puisque ce sont des sous-calculs du chiffrement.
Pourquoi pas 'r1', 'r2', etc. en tant que _r_ésultats ?
f(m,k) = xor( per(inc(m)),ses(inc(m),k) )
f(m3,k) = xor(per(inc(m1)), ses(inc(m1),ki))
Ca ne va pas, là. La fonctionn est sensée donner un résultat qui est
fonction des paramètres 'm3' et 'k'. Or non-seulement on ne retrouve pas
'm3' mais il y a en plus un 'm1' qui n'est pas défini.
k = ses_1( xor( c, per(inc(m)) ) , ses(inc(m),k) )
Erreur.
Effectivement. Ecrit un peu vite :-/
ki = ses_1( xor(c,per(inc(m))) )
En rappelant qu'obtenir la clé initiale à partir de la clé de session
est simple puisqu'il suffit de ne garder que les premiers octets. La
fonction 'ses_1()' (réciproque de 'ses()') n'utilise donc qu'un seul
paramètre.
Si tu es d'accord avec cette dernière équation, tu comprendra
Règle ton horloge ! Tu réponds vers 19:04 à un message que j'ai posté
à 22:50.
Si je prends un peu d'avance, je vais désigner par 's' la clé de session
(actuellement 'k') et par 'k' la phrase de passe. 'm' est toujours le
clair, et le chiffré.
c = f(m,k) = xor( per(inc( m)) , s ) || p(s,k)
avec s = ses(inc(m),k)
Le chiffré est le résultat de la fonction f() utilisant le clair 'm' et
la phrase de passe (la _k_lé). Le résultat est la délivrance de deux
données (unies avec || ), la première étant familière et la deuxième
consistant en le chiffrement de la clé de session 's' au moyen d'un
algorithme désigné par la fonction p() prenant également la phrase de
passe 'k' de l'utilisateur.
Je souhaite que nous nous mettions d'accord sur les choses dont nous
parlons. Sur ta proposition, il n'est nul part fait mention explicite
d'un
chiffrement avec une phrase de passe.
Exact. La phrase de passe est sous-entendue depuis plusieurs
semaines.
La phrase de passe et le code d'identification ne font pas encore partie
intégrante de l'algo à cette étape-ci, pour éviter des confusions dans la
compréhension vu qu'on est pas encore à cette étape-là. Je voudrais
traiter
du sujet de la phrase de passe et du code d'indentification après la
conclusion de cette étape-ci.
Non. Ou alors, je vais sous-entendre que cette phrase de passe est
devinable et que j'aurais accès aux données qu'ils protègent. Mais tu
répondras peut-être que ce chiffrement de clé de session par cette
phrase de passe est inviolable.
Du concret ! Considère que je ne suis pas beaucoup plus intelligent que
la machine que j'utilise. Je ne sais traiter que les choses tangibles.
k : la clé de chiffrement (la "clé initiale")
k = clef de chiffrement, donc la clef de session complète. Elle
inclue
donc aussi la clef de session initiale (ki) et la clef de session finale
(kf).
ki = clef de session initiale.
kf = clef de session finale.
Etant donné que tu réserves 'k' (la clé fournie par l'utilisateur) pour
la phrase de passe de l'utilisateur et que le 'k' que j'ai défini n'est
qu'une clé de _s_ession, je te propose de renommer tout cela en 's', 'si'
et 'sf'.
c=f(m,k)
c=f(Clair3,k) car 'm = m1 = Clair1'. Donc, 'c=f(per(inc(m1)),k)' ou
'c=f(m3,k)'
Donc, f chiffre Clair3 en l'xorisant avec k pour donner c.
Pas du tout. 'f' est une fonction qui - pour le moment - prends en
paramètres les données externes du chiffrement : le clair et la clé. En
reformulant, cela donne :
c = f(m , k) = xor( per(inc( m)) , ses(inc( m), k) )
où
c = f(m1,ki) = xor( per(inc(m1)) , ses(inc(m1),ki) )
Ceci dit, je n'aime pas vraiment compliquer l'écriture du clair qui est
traditionnelement désigné par 'm'. 'Clair1', 'Clair2', 'm1', 'm2', etc.
Ne sont plus des clairs puisque ce sont des sous-calculs du chiffrement.
Pourquoi pas 'r1', 'r2', etc. en tant que _r_ésultats ?
f(m,k) = xor( per(inc(m)),ses(inc(m),k) )
f(m3,k) = xor(per(inc(m1)), ses(inc(m1),ki))
Ca ne va pas, là. La fonctionn est sensée donner un résultat qui est
fonction des paramètres 'm3' et 'k'. Or non-seulement on ne retrouve pas
'm3' mais il y a en plus un 'm1' qui n'est pas défini.
k = ses_1( xor( c, per(inc(m)) ) , ses(inc(m),k) )
Erreur.
Effectivement. Ecrit un peu vite :-/
ki = ses_1( xor(c,per(inc(m))) )
En rappelant qu'obtenir la clé initiale à partir de la clé de session
est simple puisqu'il suffit de ne garder que les premiers octets. La
fonction 'ses_1()' (réciproque de 'ses()') n'utilise donc qu'un seul
paramètre.
Si tu es d'accord avec cette dernière équation, tu comprendra
Règle ton horloge ! Tu réponds vers 19:04 à un message que j'ai posté
à 22:50.
Si je prends un peu d'avance, je vais désigner par 's' la clé de session
(actuellement 'k') et par 'k' la phrase de passe. 'm' est toujours le
clair, et le chiffré.
c = f(m,k) = xor( per(inc( m)) , s ) || p(s,k)
avec s = ses(inc(m),k)
Le chiffré est le résultat de la fonction f() utilisant le clair 'm' et
la phrase de passe (la _k_lé). Le résultat est la délivrance de deux
données (unies avec || ), la première étant familière et la deuxième
consistant en le chiffrement de la clé de session 's' au moyen d'un
algorithme désigné par la fonction p() prenant également la phrase de
passe 'k' de l'utilisateur.
J'aimerais mieux qu'on ne traite pas de la phrase de passe maintenant,
ni du code d'identification de la phrase de passe.
...
Car avant de sauter à
cette étape-là il faudrait conclure cette étape-ci afin que cette étape-ci
du simple algo soit sûre.
D'accord à la manière d'une fonction de la programmation. Mais vue les
récentes modifications d'interprétations je débuterais toutes les fonctions
par f et ajoutant la terminaison pour identifier la fonction en tant que
telle.
Donc: 'f1' pour la fonction du chiffrage fait à partir de la clef de
session (maintenant nommé 's') et du clair 'm' ou 'm1'.
La fonction chiffrant la clef de session finale et le code
d'identification serait indiquée par 'f2'. Donc, 'c = f1(m,si) ||
f2(sf,ci)'. 'ci' pour le code d'identification.
Ca ne va pas, là. La fonctionn est sensée donner un résultat qui est
fonction des paramètres 'm3' et 'k'. Or non-seulement on ne retrouve pas
'm3' mais il y a en plus un 'm1' qui n'est pas défini.
Bien qu'en programmation il ne soit pas obligatoire de fournir une
donnée source aux fonctions mais qu'on peut fournir une donnée intermédiaire
(modifiée), si vous le désirez on peut toutefois toujours donner une valeur
source à f(). Donc, m au lieu de m2 ou m3 et k au lieu de ki ou kf. Ainsi,
on saurait à partir de quelles valeurs d'origine la fonction est traitée;
donc globalement.
Quelque chose ne semble pas aller dans 'ki = ses_1(
xor(c,per(inc(m))) )', car 'ki = ses_1(k)' ne dit pas à partir de quoi
k est réduit pour trouver ki, puisqu'il faut la bonne taille de ki
sinon ki n'est pas trouvé. Donc, si pour trouver k (clef de session
complète) il faut faire 'k = ses(mr1,ki)' [mr1= résultat de m
incrémenté], alors pour trouver ki il faudrait faire l'inverse à
partir de la clef de session finale, donc 'ki = ses_1(mr1,kf)'.
Règle ton horloge ! Tu réponds vers 19:04 à un message que j'ai
posté à 22:50.
L'heure 22:50 que vous mentionnez affiche 16:50 dans mon logiciel.
Donc, un décalage de 6 heures. Si vous demeurez en France alors il y a
...
Disons qu'on remplace p() par f2(). Mais en réalité ce serait un
peu plus compliqué puisque j'intégrerais aussi le dernier groupe
d'octets
...
J'aimerais mieux qu'on ne traite pas de la phrase de passe maintenant,
ni du code d'identification de la phrase de passe.
...
Car avant de sauter à
cette étape-là il faudrait conclure cette étape-ci afin que cette étape-ci
du simple algo soit sûre.
D'accord à la manière d'une fonction de la programmation. Mais vue les
récentes modifications d'interprétations je débuterais toutes les fonctions
par f et ajoutant la terminaison pour identifier la fonction en tant que
telle.
Donc: 'f1' pour la fonction du chiffrage fait à partir de la clef de
session (maintenant nommé 's') et du clair 'm' ou 'm1'.
La fonction chiffrant la clef de session finale et le code
d'identification serait indiquée par 'f2'. Donc, 'c = f1(m,si) ||
f2(sf,ci)'. 'ci' pour le code d'identification.
Ca ne va pas, là. La fonctionn est sensée donner un résultat qui est
fonction des paramètres 'm3' et 'k'. Or non-seulement on ne retrouve pas
'm3' mais il y a en plus un 'm1' qui n'est pas défini.
Bien qu'en programmation il ne soit pas obligatoire de fournir une
donnée source aux fonctions mais qu'on peut fournir une donnée intermédiaire
(modifiée), si vous le désirez on peut toutefois toujours donner une valeur
source à f(). Donc, m au lieu de m2 ou m3 et k au lieu de ki ou kf. Ainsi,
on saurait à partir de quelles valeurs d'origine la fonction est traitée;
donc globalement.
Quelque chose ne semble pas aller dans 'ki = ses_1(
xor(c,per(inc(m))) )', car 'ki = ses_1(k)' ne dit pas à partir de quoi
k est réduit pour trouver ki, puisqu'il faut la bonne taille de ki
sinon ki n'est pas trouvé. Donc, si pour trouver k (clef de session
complète) il faut faire 'k = ses(mr1,ki)' [mr1= résultat de m
incrémenté], alors pour trouver ki il faudrait faire l'inverse à
partir de la clef de session finale, donc 'ki = ses_1(mr1,kf)'.
Règle ton horloge ! Tu réponds vers 19:04 à un message que j'ai
posté à 22:50.
L'heure 22:50 que vous mentionnez affiche 16:50 dans mon logiciel.
Donc, un décalage de 6 heures. Si vous demeurez en France alors il y a
...
Disons qu'on remplace p() par f2(). Mais en réalité ce serait un
peu plus compliqué puisque j'intégrerais aussi le dernier groupe
d'octets
...
J'aimerais mieux qu'on ne traite pas de la phrase de passe maintenant,
ni du code d'identification de la phrase de passe.
...
Car avant de sauter à
cette étape-là il faudrait conclure cette étape-ci afin que cette étape-ci
du simple algo soit sûre.
D'accord à la manière d'une fonction de la programmation. Mais vue les
récentes modifications d'interprétations je débuterais toutes les fonctions
par f et ajoutant la terminaison pour identifier la fonction en tant que
telle.
Donc: 'f1' pour la fonction du chiffrage fait à partir de la clef de
session (maintenant nommé 's') et du clair 'm' ou 'm1'.
La fonction chiffrant la clef de session finale et le code
d'identification serait indiquée par 'f2'. Donc, 'c = f1(m,si) ||
f2(sf,ci)'. 'ci' pour le code d'identification.
Ca ne va pas, là. La fonctionn est sensée donner un résultat qui est
fonction des paramètres 'm3' et 'k'. Or non-seulement on ne retrouve pas
'm3' mais il y a en plus un 'm1' qui n'est pas défini.
Bien qu'en programmation il ne soit pas obligatoire de fournir une
donnée source aux fonctions mais qu'on peut fournir une donnée intermédiaire
(modifiée), si vous le désirez on peut toutefois toujours donner une valeur
source à f(). Donc, m au lieu de m2 ou m3 et k au lieu de ki ou kf. Ainsi,
on saurait à partir de quelles valeurs d'origine la fonction est traitée;
donc globalement.
Quelque chose ne semble pas aller dans 'ki = ses_1(
xor(c,per(inc(m))) )', car 'ki = ses_1(k)' ne dit pas à partir de quoi
k est réduit pour trouver ki, puisqu'il faut la bonne taille de ki
sinon ki n'est pas trouvé. Donc, si pour trouver k (clef de session
complète) il faut faire 'k = ses(mr1,ki)' [mr1= résultat de m
incrémenté], alors pour trouver ki il faudrait faire l'inverse à
partir de la clef de session finale, donc 'ki = ses_1(mr1,kf)'.
Règle ton horloge ! Tu réponds vers 19:04 à un message que j'ai
posté à 22:50.
L'heure 22:50 que vous mentionnez affiche 16:50 dans mon logiciel.
Donc, un décalage de 6 heures. Si vous demeurez en France alors il y a
...
Disons qu'on remplace p() par f2(). Mais en réalité ce serait un
peu plus compliqué puisque j'intégrerais aussi le dernier groupe
d'octets
...
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Oui, et la clef qu'un utilisateur pourrait rejouer, ou réutiliser est
la
phrase de passe qui est sa clef personnelle et non la clef de session
(initiale) que l'algo génère à chaque chiffrage. Mais cette phrase de
passe
ferait l'objet d'une étape future (après cette étape-ci).
Non.
Pour le moment, la clé est ce que tu appeles "clé de session".
Si
cette clé de session change (on va supposer vraiment aléatoirement)
alors ton procédé a peut-être (on va supposer que c'est vrai) la
robustesse du Vigenère, faiblesses y comprises.
Le but de la phrase de passe est de générer un code d'identification
qui
servirait à identifier si c'est la bonne phrase de passe que
l'utilisateur a
tapé au début d'une chiffrement, et si cette phrase de passe correspond
bien
au code identification alors le processus de déchiffrement est accepté.
C'est du _logiciel_. L'aspect logiciel est complétement hors-sujet
là-dedans. Il s'agit d'un confort d'interface, graphique en l'occurence.
Cela n'ajoute strictement rien à la robustesse de ton procédé. Afin de
clarifier l'étude, retire (s'il te plait) cet aspect de ton exposé.
...
Mais la phrase de passe ne fait pas l'objet de cette étape-ci.
C'est bien dommage car je ne livrerai pas mes résultats tant que je
n'aurai pas à disposition le cryptosystème complet comprenant, entre
autres, le cheminement du clair vers le chiffré en passant par la clé.
Le clair : les données à chiffrer.
Le chiffré : TOUT ce que l'utilisateur obtient.
La clé : ce que l'utilisateur connaît de lui-seul.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé.
Je pense qu'à cette étape-ci, serait de trouver la clef initiale
à partir des premiers octets connus du clair.
En fait, lors de mes calculs précédents il était pertinent de faire
cela car la clé était réutilisée par l'utilisateur. Ici, cela ne sert
à rien puisque la clé de session (on va supposer) est aléatoire. Il
faut donc découvrir cette fameuse clé.
sinon je pense qu'à cette étape-ci il n'y a plus rien à faire.
Je confirme. En fait, il te suffit de chiffer la clé de session avec
l'algorithme CAST5 de gnupg et je serai très gêné ! La clé de
ton utilisateur serait alors la clé passée à gnupg pour chiffrer ta clé
de session...
Maintenant, tu peux peut-être te demander pourquoi j'attends que tu
complètes le cryptosystème au lieu de déchiqueter l'existant ?
- c'est devenu compliqué (mais pas plus sûr) donc long à tester.
- ton procédé a déjà des fautes de principes, à voir plus tard :-]
- j'attends que tu introduises la faiblesse supplémentaire qui va faire
s'écrouler l'existant.
Ton dilemne est le suivant :
1/ Soit tu imposes à tes utilisateurs une clé
aussi longue que le clair et à changer tout le temps. Ca marche, mais
autant faire du Vigenère.
2/ Soit tu imposes à tes utilisateurs une clé bien moins longue et
facile à retenir qu'ils pourront réutiliser.
J'attends patiemment que tu pourrisses ton système en l'achevant, dans
les deux sens courants de ce terme :-p
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Oui, et la clef qu'un utilisateur pourrait rejouer, ou réutiliser est
la
phrase de passe qui est sa clef personnelle et non la clef de session
(initiale) que l'algo génère à chaque chiffrage. Mais cette phrase de
passe
ferait l'objet d'une étape future (après cette étape-ci).
Non.
Pour le moment, la clé est ce que tu appeles "clé de session".
Si
cette clé de session change (on va supposer vraiment aléatoirement)
alors ton procédé a peut-être (on va supposer que c'est vrai) la
robustesse du Vigenère, faiblesses y comprises.
Le but de la phrase de passe est de générer un code d'identification
qui
servirait à identifier si c'est la bonne phrase de passe que
l'utilisateur a
tapé au début d'une chiffrement, et si cette phrase de passe correspond
bien
au code identification alors le processus de déchiffrement est accepté.
C'est du _logiciel_. L'aspect logiciel est complétement hors-sujet
là-dedans. Il s'agit d'un confort d'interface, graphique en l'occurence.
Cela n'ajoute strictement rien à la robustesse de ton procédé. Afin de
clarifier l'étude, retire (s'il te plait) cet aspect de ton exposé.
...
Mais la phrase de passe ne fait pas l'objet de cette étape-ci.
C'est bien dommage car je ne livrerai pas mes résultats tant que je
n'aurai pas à disposition le cryptosystème complet comprenant, entre
autres, le cheminement du clair vers le chiffré en passant par la clé.
Le clair : les données à chiffrer.
Le chiffré : TOUT ce que l'utilisateur obtient.
La clé : ce que l'utilisateur connaît de lui-seul.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé.
Je pense qu'à cette étape-ci, serait de trouver la clef initiale
à partir des premiers octets connus du clair.
En fait, lors de mes calculs précédents il était pertinent de faire
cela car la clé était réutilisée par l'utilisateur. Ici, cela ne sert
à rien puisque la clé de session (on va supposer) est aléatoire. Il
faut donc découvrir cette fameuse clé.
sinon je pense qu'à cette étape-ci il n'y a plus rien à faire.
Je confirme. En fait, il te suffit de chiffer la clé de session avec
l'algorithme CAST5 de gnupg et je serai très gêné ! La clé de
ton utilisateur serait alors la clé passée à gnupg pour chiffrer ta clé
de session...
Maintenant, tu peux peut-être te demander pourquoi j'attends que tu
complètes le cryptosystème au lieu de déchiqueter l'existant ?
- c'est devenu compliqué (mais pas plus sûr) donc long à tester.
- ton procédé a déjà des fautes de principes, à voir plus tard :-]
- j'attends que tu introduises la faiblesse supplémentaire qui va faire
s'écrouler l'existant.
Ton dilemne est le suivant :
1/ Soit tu imposes à tes utilisateurs une clé
aussi longue que le clair et à changer tout le temps. Ca marche, mais
autant faire du Vigenère.
2/ Soit tu imposes à tes utilisateurs une clé bien moins longue et
facile à retenir qu'ils pourront réutiliser.
J'attends patiemment que tu pourrisses ton système en l'achevant, dans
les deux sens courants de ce terme :-p
Sans description précise, je considère uniquement les caractéristiques
concrètes fournies.
Oui, et la clef qu'un utilisateur pourrait rejouer, ou réutiliser est
la
phrase de passe qui est sa clef personnelle et non la clef de session
(initiale) que l'algo génère à chaque chiffrage. Mais cette phrase de
passe
ferait l'objet d'une étape future (après cette étape-ci).
Non.
Pour le moment, la clé est ce que tu appeles "clé de session".
Si
cette clé de session change (on va supposer vraiment aléatoirement)
alors ton procédé a peut-être (on va supposer que c'est vrai) la
robustesse du Vigenère, faiblesses y comprises.
Le but de la phrase de passe est de générer un code d'identification
qui
servirait à identifier si c'est la bonne phrase de passe que
l'utilisateur a
tapé au début d'une chiffrement, et si cette phrase de passe correspond
bien
au code identification alors le processus de déchiffrement est accepté.
C'est du _logiciel_. L'aspect logiciel est complétement hors-sujet
là-dedans. Il s'agit d'un confort d'interface, graphique en l'occurence.
Cela n'ajoute strictement rien à la robustesse de ton procédé. Afin de
clarifier l'étude, retire (s'il te plait) cet aspect de ton exposé.
...
Mais la phrase de passe ne fait pas l'objet de cette étape-ci.
C'est bien dommage car je ne livrerai pas mes résultats tant que je
n'aurai pas à disposition le cryptosystème complet comprenant, entre
autres, le cheminement du clair vers le chiffré en passant par la clé.
Le clair : les données à chiffrer.
Le chiffré : TOUT ce que l'utilisateur obtient.
La clé : ce que l'utilisateur connaît de lui-seul.
Mes calculs précédents ne nécessitaient qu'une longueur de clair
équivalente à la longueur de la clé.
Je pense qu'à cette étape-ci, serait de trouver la clef initiale
à partir des premiers octets connus du clair.
En fait, lors de mes calculs précédents il était pertinent de faire
cela car la clé était réutilisée par l'utilisateur. Ici, cela ne sert
à rien puisque la clé de session (on va supposer) est aléatoire. Il
faut donc découvrir cette fameuse clé.
sinon je pense qu'à cette étape-ci il n'y a plus rien à faire.
Je confirme. En fait, il te suffit de chiffer la clé de session avec
l'algorithme CAST5 de gnupg et je serai très gêné ! La clé de
ton utilisateur serait alors la clé passée à gnupg pour chiffrer ta clé
de session...
Maintenant, tu peux peut-être te demander pourquoi j'attends que tu
complètes le cryptosystème au lieu de déchiqueter l'existant ?
- c'est devenu compliqué (mais pas plus sûr) donc long à tester.
- ton procédé a déjà des fautes de principes, à voir plus tard :-]
- j'attends que tu introduises la faiblesse supplémentaire qui va faire
s'écrouler l'existant.
Ton dilemne est le suivant :
1/ Soit tu imposes à tes utilisateurs une clé
aussi longue que le clair et à changer tout le temps. Ca marche, mais
autant faire du Vigenère.
2/ Soit tu imposes à tes utilisateurs une clé bien moins longue et
facile à retenir qu'ils pourront réutiliser.
J'attends patiemment que tu pourrisses ton système en l'achevant, dans
les deux sens courants de ce terme :-p
Car avant de sauter à
cette étape-là il faudrait conclure cette étape-ci afin que cette
étape-ci
du simple algo soit sûre.
Elle est (on va dire) aussi sûre qu'un vigenère sur lequel on n'utilise
pas le même mot de passe deux fois. La question est donc réglée.
Donc: 'f1' pour la fonction du chiffrage fait à partir de la clef de
session (maintenant nommé 's') et du clair 'm' ou 'm1'.
C'était trop simple d'utiliser des noms de fonctions qui rappellent le
traitement fait au code ?!
La fonction chiffrant la clef de session finale et le code
d'identification serait indiquée par 'f2'. Donc, 'c = f1(m,si) ||
f2(sf,ci)'. 'ci' pour le code d'identification.
Laisse tomber ce "code d'identification", il n'apporte aucune robustesse
supplémentaire au procédé. Ca complique inutilement l'ensemble.
Ce n'est pas de la programmation ici. Ce sont des mathématiques. Elles
ont la particularité d'empêcher tout brouillage des pistes.
Des données subissent des traitements à travers une fonction. En
entrée, on a _toutes_ les composantes impliquées et en sortie on a un
résultat.
sinon ki n'est pas trouvé. Donc, si pour trouver k (clef de session
complète) il faut faire 'k = ses(mr1,ki)' [mr1= résultat de m
incrémenté], alors pour trouver ki il faudrait faire l'inverse à
partir de la clef de session finale, donc 'ki = ses_1(mr1,kf)'.
En fait, une faiblesse devrait être ajoutée lorsque tu auras complété
ton procédé.
Cela me permettra de trouver la bonne taille. Mais
j'attends toujours...
Car avant de sauter à
cette étape-là il faudrait conclure cette étape-ci afin que cette
étape-ci
du simple algo soit sûre.
Elle est (on va dire) aussi sûre qu'un vigenère sur lequel on n'utilise
pas le même mot de passe deux fois. La question est donc réglée.
Donc: 'f1' pour la fonction du chiffrage fait à partir de la clef de
session (maintenant nommé 's') et du clair 'm' ou 'm1'.
C'était trop simple d'utiliser des noms de fonctions qui rappellent le
traitement fait au code ?!
La fonction chiffrant la clef de session finale et le code
d'identification serait indiquée par 'f2'. Donc, 'c = f1(m,si) ||
f2(sf,ci)'. 'ci' pour le code d'identification.
Laisse tomber ce "code d'identification", il n'apporte aucune robustesse
supplémentaire au procédé. Ca complique inutilement l'ensemble.
Ce n'est pas de la programmation ici. Ce sont des mathématiques. Elles
ont la particularité d'empêcher tout brouillage des pistes.
Des données subissent des traitements à travers une fonction. En
entrée, on a _toutes_ les composantes impliquées et en sortie on a un
résultat.
sinon ki n'est pas trouvé. Donc, si pour trouver k (clef de session
complète) il faut faire 'k = ses(mr1,ki)' [mr1= résultat de m
incrémenté], alors pour trouver ki il faudrait faire l'inverse à
partir de la clef de session finale, donc 'ki = ses_1(mr1,kf)'.
En fait, une faiblesse devrait être ajoutée lorsque tu auras complété
ton procédé.
Cela me permettra de trouver la bonne taille. Mais
j'attends toujours...
Car avant de sauter à
cette étape-là il faudrait conclure cette étape-ci afin que cette
étape-ci
du simple algo soit sûre.
Elle est (on va dire) aussi sûre qu'un vigenère sur lequel on n'utilise
pas le même mot de passe deux fois. La question est donc réglée.
Donc: 'f1' pour la fonction du chiffrage fait à partir de la clef de
session (maintenant nommé 's') et du clair 'm' ou 'm1'.
C'était trop simple d'utiliser des noms de fonctions qui rappellent le
traitement fait au code ?!
La fonction chiffrant la clef de session finale et le code
d'identification serait indiquée par 'f2'. Donc, 'c = f1(m,si) ||
f2(sf,ci)'. 'ci' pour le code d'identification.
Laisse tomber ce "code d'identification", il n'apporte aucune robustesse
supplémentaire au procédé. Ca complique inutilement l'ensemble.
Ce n'est pas de la programmation ici. Ce sont des mathématiques. Elles
ont la particularité d'empêcher tout brouillage des pistes.
Des données subissent des traitements à travers une fonction. En
entrée, on a _toutes_ les composantes impliquées et en sortie on a un
résultat.
sinon ki n'est pas trouvé. Donc, si pour trouver k (clef de session
complète) il faut faire 'k = ses(mr1,ki)' [mr1= résultat de m
incrémenté], alors pour trouver ki il faudrait faire l'inverse à
partir de la clef de session finale, donc 'ki = ses_1(mr1,kf)'.
En fait, une faiblesse devrait être ajoutée lorsque tu auras complété
ton procédé.
Cela me permettra de trouver la bonne taille. Mais
j'attends toujours...
Non.
Pour le moment, la clé est ce que tu appeles "clé de session".
Pourtant on a décidé de nommer 'k' la phrase de passe. On a donc
accepté que la phrase de passe soit une clef, et je la nomme 'clef
personnelle'.
C'est du _logiciel_. L'aspect logiciel est complétement hors-sujet
là-dedans. Il s'agit d'un confort d'interface, graphique en l'occurence.
Cela n'ajoute strictement rien à la robustesse de ton procédé. Afin de
clarifier l'étude, retire (s'il te plait) cet aspect de ton exposé.
Désolé! Je ne peux pas, car c'est nécessaire même. Ce n'est pas une
question d'interface.
Je m'explique. Pour déchiffrer, si l'algo ne reconnaît pas lorsque
l'utilisateur se trompe en tapant la mauvaise clef personnelle (phrase de
passe) alors l'algo va chiffrer le chiffré d'une autre façon, au lieu de le
déchiffrer; et l'utilisateur pourrait être dans la confusion en ayant un
chiffré qui est chiffré deux fois.
...
il s'arrête là donnant un message disant que la clef
personnelle est fausse.
Ce que l'utilisateur connaît de lui seul est donc la 'clef
personnelle' (phrase de passe). Je pense à ça tout d'un coup:
'personnelle' signifie 'privé', et justement ce terme existe: 'clef
privée'. J'utiliserais donc ce terme pour désigner la phrase de passe
au lieu de 'clef personnelle'. Qu'en dites-vous?
En fait, il te suffit de chiffer la clé de session avec l'algorithme
CAST5 de gnupg et je serai très gêné ! La clé de ton utilisateur
serait alors la clé passée à gnupg pour chiffrer ta clé de
session...
Vous voulez dire que ce serait une bonne chose d'utiliser GAST5 pour
le
chiffré2 ? Cela demande plein de question.
-Est-ce un algo très sûr?
- Existe-t-il une dll pour être utilisé en VB?
- Aie-je le droit de l'utiliser dans mon logiciel commercial?
- Est-il compliqué à utiliser?
- Quelle est la taille de la DLL ou du code source?
- Crypte-t-il un maximum d'octets à la fois?
"GnuPG se compile et fonctionne sur beaucoup de systèmes, mais à cause
du manque d'une bonne source d'entropie testée, il doit être utilisé
avec précaution."
Cette phrase ne donne pas une grande confiance dans GnuPG. J'imagine que
ce sont des codes sources qui se compile en C.
Je trouve que 3 Mo pour chiffrer la finale du simple algo est exagéré.
- c'est devenu compliqué (mais pas plus sûr) donc long à tester. -
ton procédé a déjà des fautes de principes, à voir plus tard :-]
Ne serait-il pas préférable de parler de ces fautes de principes
tout de suite afin d'éviter une perte de temps plus tard dans la
correction?
Non.
Pour le moment, la clé est ce que tu appeles "clé de session".
Pourtant on a décidé de nommer 'k' la phrase de passe. On a donc
accepté que la phrase de passe soit une clef, et je la nomme 'clef
personnelle'.
C'est du _logiciel_. L'aspect logiciel est complétement hors-sujet
là-dedans. Il s'agit d'un confort d'interface, graphique en l'occurence.
Cela n'ajoute strictement rien à la robustesse de ton procédé. Afin de
clarifier l'étude, retire (s'il te plait) cet aspect de ton exposé.
Désolé! Je ne peux pas, car c'est nécessaire même. Ce n'est pas une
question d'interface.
Je m'explique. Pour déchiffrer, si l'algo ne reconnaît pas lorsque
l'utilisateur se trompe en tapant la mauvaise clef personnelle (phrase de
passe) alors l'algo va chiffrer le chiffré d'une autre façon, au lieu de le
déchiffrer; et l'utilisateur pourrait être dans la confusion en ayant un
chiffré qui est chiffré deux fois.
...
il s'arrête là donnant un message disant que la clef
personnelle est fausse.
Ce que l'utilisateur connaît de lui seul est donc la 'clef
personnelle' (phrase de passe). Je pense à ça tout d'un coup:
'personnelle' signifie 'privé', et justement ce terme existe: 'clef
privée'. J'utiliserais donc ce terme pour désigner la phrase de passe
au lieu de 'clef personnelle'. Qu'en dites-vous?
En fait, il te suffit de chiffer la clé de session avec l'algorithme
CAST5 de gnupg et je serai très gêné ! La clé de ton utilisateur
serait alors la clé passée à gnupg pour chiffrer ta clé de
session...
Vous voulez dire que ce serait une bonne chose d'utiliser GAST5 pour
le
chiffré2 ? Cela demande plein de question.
-Est-ce un algo très sûr?
- Existe-t-il une dll pour être utilisé en VB?
- Aie-je le droit de l'utiliser dans mon logiciel commercial?
- Est-il compliqué à utiliser?
- Quelle est la taille de la DLL ou du code source?
- Crypte-t-il un maximum d'octets à la fois?
"GnuPG se compile et fonctionne sur beaucoup de systèmes, mais à cause
du manque d'une bonne source d'entropie testée, il doit être utilisé
avec précaution."
Cette phrase ne donne pas une grande confiance dans GnuPG. J'imagine que
ce sont des codes sources qui se compile en C.
Je trouve que 3 Mo pour chiffrer la finale du simple algo est exagéré.
- c'est devenu compliqué (mais pas plus sûr) donc long à tester. -
ton procédé a déjà des fautes de principes, à voir plus tard :-]
Ne serait-il pas préférable de parler de ces fautes de principes
tout de suite afin d'éviter une perte de temps plus tard dans la
correction?
Non.
Pour le moment, la clé est ce que tu appeles "clé de session".
Pourtant on a décidé de nommer 'k' la phrase de passe. On a donc
accepté que la phrase de passe soit une clef, et je la nomme 'clef
personnelle'.
C'est du _logiciel_. L'aspect logiciel est complétement hors-sujet
là-dedans. Il s'agit d'un confort d'interface, graphique en l'occurence.
Cela n'ajoute strictement rien à la robustesse de ton procédé. Afin de
clarifier l'étude, retire (s'il te plait) cet aspect de ton exposé.
Désolé! Je ne peux pas, car c'est nécessaire même. Ce n'est pas une
question d'interface.
Je m'explique. Pour déchiffrer, si l'algo ne reconnaît pas lorsque
l'utilisateur se trompe en tapant la mauvaise clef personnelle (phrase de
passe) alors l'algo va chiffrer le chiffré d'une autre façon, au lieu de le
déchiffrer; et l'utilisateur pourrait être dans la confusion en ayant un
chiffré qui est chiffré deux fois.
...
il s'arrête là donnant un message disant que la clef
personnelle est fausse.
Ce que l'utilisateur connaît de lui seul est donc la 'clef
personnelle' (phrase de passe). Je pense à ça tout d'un coup:
'personnelle' signifie 'privé', et justement ce terme existe: 'clef
privée'. J'utiliserais donc ce terme pour désigner la phrase de passe
au lieu de 'clef personnelle'. Qu'en dites-vous?
En fait, il te suffit de chiffer la clé de session avec l'algorithme
CAST5 de gnupg et je serai très gêné ! La clé de ton utilisateur
serait alors la clé passée à gnupg pour chiffrer ta clé de
session...
Vous voulez dire que ce serait une bonne chose d'utiliser GAST5 pour
le
chiffré2 ? Cela demande plein de question.
-Est-ce un algo très sûr?
- Existe-t-il une dll pour être utilisé en VB?
- Aie-je le droit de l'utiliser dans mon logiciel commercial?
- Est-il compliqué à utiliser?
- Quelle est la taille de la DLL ou du code source?
- Crypte-t-il un maximum d'octets à la fois?
"GnuPG se compile et fonctionne sur beaucoup de systèmes, mais à cause
du manque d'une bonne source d'entropie testée, il doit être utilisé
avec précaution."
Cette phrase ne donne pas une grande confiance dans GnuPG. J'imagine que
ce sont des codes sources qui se compile en C.
Je trouve que 3 Mo pour chiffrer la finale du simple algo est exagéré.
- c'est devenu compliqué (mais pas plus sûr) donc long à tester. -
ton procédé a déjà des fautes de principes, à voir plus tard :-]
Ne serait-il pas préférable de parler de ces fautes de principes
tout de suite afin d'éviter une perte de temps plus tard dans la
correction?