Le Wed, 25 Apr 2012 23:15:04 +0200, Philippe Lheureux a écrit :
C'est pourtant un coutumier du fait ! :-( Soit il fait le mort, soit il rajoute une verrue supplémentaire à son algorithme, ce qui ne rend pas ce dernier plus sur ou efficace pour autant... ;-)
Je ne fais pas le mort , je ne passe pas ma vie dans ce forum c'est tout , j'y passe de temps en temps. Christophe Henry a bien cassé la première version de CENA .. malgré qu'on lui ait dit que cela ne servait pas a grand chose vu qu'on avait une version plus aboutie. voir : www.superlutin.net/cena.html Est ce qu'il trouve un point faible maintenant ?
J'ai révisé mes fondamentaux en cryptographie, et j'ai poutré ton algo gracieusement. Ça a été du gagnant-gagnant, et distrayant. Cependant, j'avoue ne trouver aucun point faible à l'algorithme présenté sur ta page. Mais, je ne lui trouve aucun point fort. En fait, je n'arrive pas à décrypter les explications :-o Quand j'avais vu l'implémentation de Dimitri, j'avais sauté sur l'occasion.
Ceci dit , mon programmeur a laissé tombé cette version du fait que le résultat final était trop lourd par rapport au clair .... on a donc réfléchi sur un nouveau concept qui s'apelle CEC , Chiffrage par Expansion de Clé et que nous vous proposerons bientôt. Avec ce nouveau concept , la taille du chiffré fait exactement celle du clair.
Il sera équivalent à un Vigenère brouillé, soit pire qu'un Vigenère correctement implémenté.
-- Christophe HENRY FR EO EN - http://www.sbgodin.fr
Le Wed, 25 Apr 2012 23:15:04 +0200, Philippe Lheureux a écrit :
C'est pourtant un coutumier du fait ! :-(
Soit il fait le mort, soit il rajoute une verrue supplémentaire à son
algorithme, ce qui ne rend pas ce dernier plus sur ou efficace pour
autant... ;-)
Je ne fais pas le mort , je ne passe pas ma vie dans ce forum c'est tout
,
j'y passe de temps en temps. Christophe Henry a bien cassé la première
version de CENA .. malgré qu'on lui ait dit que cela ne servait pas a
grand chose vu qu'on avait une version plus aboutie.
voir : www.superlutin.net/cena.html Est ce qu'il trouve un point faible
maintenant ?
J'ai révisé mes fondamentaux en cryptographie, et j'ai poutré ton algo
gracieusement. Ça a été du gagnant-gagnant, et distrayant. Cependant,
j'avoue ne trouver aucun point faible à l'algorithme présenté sur ta
page. Mais, je ne lui trouve aucun point fort. En fait, je n'arrive pas à
décrypter les explications :-o Quand j'avais vu l'implémentation de
Dimitri, j'avais sauté sur l'occasion.
Ceci dit , mon programmeur a laissé tombé cette version du fait que le
résultat final était trop lourd par rapport au clair .... on a donc
réfléchi sur un nouveau concept qui s'apelle CEC , Chiffrage par
Expansion de Clé et que nous vous proposerons bientôt. Avec ce nouveau
concept , la taille du chiffré fait exactement celle du clair.
Il sera équivalent à un Vigenère brouillé, soit pire qu'un Vigenère
correctement implémenté.
--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr
Le Wed, 25 Apr 2012 23:15:04 +0200, Philippe Lheureux a écrit :
C'est pourtant un coutumier du fait ! :-( Soit il fait le mort, soit il rajoute une verrue supplémentaire à son algorithme, ce qui ne rend pas ce dernier plus sur ou efficace pour autant... ;-)
Je ne fais pas le mort , je ne passe pas ma vie dans ce forum c'est tout , j'y passe de temps en temps. Christophe Henry a bien cassé la première version de CENA .. malgré qu'on lui ait dit que cela ne servait pas a grand chose vu qu'on avait une version plus aboutie. voir : www.superlutin.net/cena.html Est ce qu'il trouve un point faible maintenant ?
J'ai révisé mes fondamentaux en cryptographie, et j'ai poutré ton algo gracieusement. Ça a été du gagnant-gagnant, et distrayant. Cependant, j'avoue ne trouver aucun point faible à l'algorithme présenté sur ta page. Mais, je ne lui trouve aucun point fort. En fait, je n'arrive pas à décrypter les explications :-o Quand j'avais vu l'implémentation de Dimitri, j'avais sauté sur l'occasion.
Ceci dit , mon programmeur a laissé tombé cette version du fait que le résultat final était trop lourd par rapport au clair .... on a donc réfléchi sur un nouveau concept qui s'apelle CEC , Chiffrage par Expansion de Clé et que nous vous proposerons bientôt. Avec ce nouveau concept , la taille du chiffré fait exactement celle du clair.
Il sera équivalent à un Vigenère brouillé, soit pire qu'un Vigenère correctement implémenté.
-- Christophe HENRY FR EO EN - http://www.sbgodin.fr
Stephane CARPENTIER
Philippe Lheureux wrote:
Je ne fais pas le mort , je ne passe pas ma vie dans ce forum c'est tout , j'y passe de temps en temps. Christophe Henry a bien cassé la première version de CENA .. malgré qu'on lui ait dit que cela ne servait pas a grand chose vu qu'on avait une version plus aboutie. voir : www.superlutin.net/cena.html Est ce qu'il trouve un point faible maintenant ?
Ce n'est pas utile qu'il cherche, tu vas bientôt avoir une version plus aboutie.
Ceci dit , mon programmeur a laissé tombé cette version du fait que le résultat final était trop lourd par rapport au clair ....
Ta version précédente multipliait la taille du message par 17 sans que ça ne rebute ton programmeur. Là, ça laisse songeur.
Philippe Lheureux wrote:
Je ne fais pas le mort , je ne passe pas ma vie dans ce forum c'est tout ,
j'y passe de temps en temps. Christophe Henry a bien cassé la première
version de CENA .. malgré qu'on lui ait dit que cela ne servait pas a
grand chose vu qu'on avait une version plus aboutie.
voir : www.superlutin.net/cena.html
Est ce qu'il trouve un point faible maintenant ?
Ce n'est pas utile qu'il cherche, tu vas bientôt avoir une version plus
aboutie.
Ceci dit , mon programmeur a laissé tombé cette version du fait que le
résultat final était trop lourd par rapport au clair ....
Ta version précédente multipliait la taille du message par 17 sans que ça ne
rebute ton programmeur. Là, ça laisse songeur.
Je ne fais pas le mort , je ne passe pas ma vie dans ce forum c'est tout , j'y passe de temps en temps. Christophe Henry a bien cassé la première version de CENA .. malgré qu'on lui ait dit que cela ne servait pas a grand chose vu qu'on avait une version plus aboutie. voir : www.superlutin.net/cena.html Est ce qu'il trouve un point faible maintenant ?
Ce n'est pas utile qu'il cherche, tu vas bientôt avoir une version plus aboutie.
Ceci dit , mon programmeur a laissé tombé cette version du fait que le résultat final était trop lourd par rapport au clair ....
Ta version précédente multipliait la taille du message par 17 sans que ça ne rebute ton programmeur. Là, ça laisse songeur.
Philippe Lheureux
Ta version précédente multipliait la taille du message par 17 sans que ça ne rebute ton programmeur. Là, ça laisse songeur.
Faux puisqu'il a abandonné au profit de CEC. C'est parce qu'il m'a dit qu'il préférais une méthode qui ne fasse pas gonfler la taille du chiffré que j'ai pensé à CEC.
Ta version précédente multipliait la taille du message par 17 sans que ça ne
rebute ton programmeur. Là, ça laisse songeur.
Faux puisqu'il a abandonné au profit de CEC. C'est parce qu'il m'a dit qu'il
préférais une méthode qui ne fasse pas gonfler la taille du chiffré que j'ai
pensé à CEC.
Ta version précédente multipliait la taille du message par 17 sans que ça ne rebute ton programmeur. Là, ça laisse songeur.
Faux puisqu'il a abandonné au profit de CEC. C'est parce qu'il m'a dit qu'il préférais une méthode qui ne fasse pas gonfler la taille du chiffré que j'ai pensé à CEC.
Stephane CARPENTIER
Philippe Lheureux wrote:
Ta version précédente multipliait la taille du message par 17 sans que ça ne rebute ton programmeur. Là, ça laisse songeur.
Faux puisqu'il a abandonné au profit de CEC. C'est parce qu'il m'a dit qu'il préférais une méthode qui ne fasse pas gonfler la taille du chiffré que j'ai pensé à CEC.
C'est bien là le problème de ta façon de faire de la sécurité.
Certains ici t'ont répété que si ton chiffré est plus long que ton clair, c'est qu'il y a de la redondance d'information et donc des failles sans que ça ne te fasse dévier le moins du monde de ta vision. C'est seulement pour des raisons préférentielles de ton programmeur que tu as changé ton approche.
Un algo doit être le plus fort possible. Il ne doit pas évoluer en fonction des goûts de ses implémenteurs, mais en fonction de sa sécurité intrinsèque.
Philippe Lheureux wrote:
Ta version précédente multipliait la taille du message par 17 sans que ça
ne rebute ton programmeur. Là, ça laisse songeur.
Faux puisqu'il a abandonné au profit de CEC. C'est parce qu'il m'a dit
qu'il préférais une méthode qui ne fasse pas gonfler la taille du chiffré
que j'ai pensé à CEC.
C'est bien là le problème de ta façon de faire de la sécurité.
Certains ici t'ont répété que si ton chiffré est plus long que ton clair,
c'est qu'il y a de la redondance d'information et donc des failles sans que
ça ne te fasse dévier le moins du monde de ta vision. C'est seulement pour
des raisons préférentielles de ton programmeur que tu as changé ton
approche.
Un algo doit être le plus fort possible. Il ne doit pas évoluer en fonction
des goûts de ses implémenteurs, mais en fonction de sa sécurité intrinsèque.
Ta version précédente multipliait la taille du message par 17 sans que ça ne rebute ton programmeur. Là, ça laisse songeur.
Faux puisqu'il a abandonné au profit de CEC. C'est parce qu'il m'a dit qu'il préférais une méthode qui ne fasse pas gonfler la taille du chiffré que j'ai pensé à CEC.
C'est bien là le problème de ta façon de faire de la sécurité.
Certains ici t'ont répété que si ton chiffré est plus long que ton clair, c'est qu'il y a de la redondance d'information et donc des failles sans que ça ne te fasse dévier le moins du monde de ta vision. C'est seulement pour des raisons préférentielles de ton programmeur que tu as changé ton approche.
Un algo doit être le plus fort possible. Il ne doit pas évoluer en fonction des goûts de ses implémenteurs, mais en fonction de sa sécurité intrinsèque.
Philippe Lheureux
C'est bien là le problème de ta façon de faire de la sécurité.
Certains ici t'ont répété que si ton chiffré est plus long que ton clair, c'est qu'il y a de la redondance d'information et donc des failles sans que ça ne te fasse dévier le moins du monde de ta vision. C'est seulement pour des raisons préférentielles de ton programmeur que tu as changé ton approche.
Un algo doit être le plus fort possible. Il ne doit pas évoluer en fonction des goûts de ses implémenteurs, mais en fonction de sa sécurité intrinsèque.
LP : Avec CENA tel que décrit sur www.superlutin.net/cena.html , il ne doit pas y avoir beaucoup de redondance d'informations. La part de l'aléatoire est trop importante pour pouvoir distinguer ce qui est aléatoire de ce qui ne l'est pas en utilisation normale. l'avantage c'est que les deux utilisateurs n'ont pas besoin de changer constamment de clé , l'inconvénient c'est qu'un caractère clair = huit caractères chiffrés.
C'est bien là le problème de ta façon de faire de la sécurité.
Certains ici t'ont répété que si ton chiffré est plus long que ton clair,
c'est qu'il y a de la redondance d'information et donc des failles sans que
ça ne te fasse dévier le moins du monde de ta vision. C'est seulement pour
des raisons préférentielles de ton programmeur que tu as changé ton
approche.
Un algo doit être le plus fort possible. Il ne doit pas évoluer en fonction
des goûts de ses implémenteurs, mais en fonction de sa sécurité intrinsèque.
LP : Avec CENA tel que décrit sur www.superlutin.net/cena.html , il ne doit
pas y avoir beaucoup de redondance d'informations.
La part de l'aléatoire est trop importante pour pouvoir distinguer ce qui
est aléatoire de ce qui ne l'est pas en utilisation normale.
l'avantage c'est que les deux utilisateurs n'ont pas besoin de changer
constamment de clé , l'inconvénient c'est qu'un caractère clair = huit
caractères chiffrés.
C'est bien là le problème de ta façon de faire de la sécurité.
Certains ici t'ont répété que si ton chiffré est plus long que ton clair, c'est qu'il y a de la redondance d'information et donc des failles sans que ça ne te fasse dévier le moins du monde de ta vision. C'est seulement pour des raisons préférentielles de ton programmeur que tu as changé ton approche.
Un algo doit être le plus fort possible. Il ne doit pas évoluer en fonction des goûts de ses implémenteurs, mais en fonction de sa sécurité intrinsèque.
LP : Avec CENA tel que décrit sur www.superlutin.net/cena.html , il ne doit pas y avoir beaucoup de redondance d'informations. La part de l'aléatoire est trop importante pour pouvoir distinguer ce qui est aléatoire de ce qui ne l'est pas en utilisation normale. l'avantage c'est que les deux utilisateurs n'ont pas besoin de changer constamment de clé , l'inconvénient c'est qu'un caractère clair = huit caractères chiffrés.
