Challenge CENA

[Philippe Lheureux]

J'ai trouvé un informaticien qui s'est amusé à programmer facilement en PHP
mon idée de crypto par encapsulation dans un nombre aléatoire.

Le résultat est visible en ligne pour test sur la page :

http://dimooz.free.fr/void/cena/index_v2.php

Le challenge de cracking est ouvert ... bonne chance

[Erwan David]

Mais pauvre abruti tu n'as toujours pas compris que c'est à toi
d'aporter la preuve pas aux autres.

Tu es nul, tu ne comprends rien, et ici tu ne fais qu'emmerder le monde.


--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

[Erwan David]

Mais pauvre abruti tu n'as toujours pas compris que c'est à toi

d'apporter la preuve pas aux autres. On te l'as pourtant dit assez
souvent !

Tu es nul, tu ne comprends rien, et ici tu ne fais qu'emmerder le monde

(pas qu'ici d'ailleurs).

[Philippe Lheureux]

"Erwan David" a écrit dans le message de groupe de discussion :
m2398np...@rail.eu.org...

En parlant de preuve , tu viens d'en fournir une belle sur ton comportement
social :-)
http://www.superlutin.net/censure.html pour ce genre de comportement ... tu
vois moi je t'ai cryptanalisé dès le départ :-)
Maintenant pour CENA , tu peux hurler , beugler , ou faire un caca nerveux
cela ne change rien au fait qu'il est opérationnel , testable , et qu'en
plus le code source est fourni.

[Erwann Abalea]

Le dimanche 1 avril 2012 23:36:37 UTC+2, Philippe Lheureux a écrit :

> Maintenant pour CENA , tu peux hurler , beugler , ou faire un caca nerveux
> cela ne change rien au fait qu'il est opérationnel , testable , et qu'en
> plus le code source est fourni.

Et tout ça ne change rien au fait qu'il est nul.

Que ce soit démontré ou pas ne change rien à la valeur de vérité de mon assertion.

[Philippe Lheureux]

> Maintenant pour CENA , tu peux hurler , beugler , ou faire un caca nerveux
> cela ne change rien au fait qu'il est opérationnel , testable , et qu'en
> plus le code source est fourni.

Et tout ça ne change rien au fait qu'il est nul.

Que ce soit démontré ou pas ne change rien à la valeur de vérité de mon
assertion.

Ben vas y , casse le puisqu'il est si nul que ça :-) et même sans le casser
car cela prendrait du temps , qu'est ce qui te fais dire qu'il est nul ? on
t'écoutes attentivement !

[Christophe HENRY]

Je répond à la question, bien qu'elle ne m'était pas adressée ;-)

J'ai cassé ton algorithme. Le code source est ici, il suffit de le lancer
en ligne de commande :

https://sekur.sbgodin.fr/svn/cena/tags/cena10avr2012-cryptanalyse-base/

C'est encore brutal, ça nécessite 125688 demandes de chiffrement, mais ça
marche... Je vais en faire une version ne nécessitant qu'une seule
demande de chiffrement.

Cependant, pour continuer je voudrais te demander deux choses.

A/ Que le code source de la "lib_cena_v03.php" soit publié sous licence
libre (GPLv3, ou GPLv2, etc...). Condition nécessaire. Je libérerai mon
code à la suite, afin de pouvoir publier mes résultats sans contrainte.

B/ Qu'on fasse un test de cryptanalyse en grandeur réelle :

1/ Tu génères une clé avec la "lib_cena_v03.php", strictement la
version que j'ai utilisée. Tu conserveras secrète cette clé dans un
premier temps.

2/ Tu prends un fichier texte, à garder secret dans un premier temps,
en français courant, avec la ponctuation habituelle, que tu chiffres avec
la clé générée. Le français ne facilite pas vraiment le déchiffrement
mais évite d'employer des caractères non-ISO.

3/ Tu chiffres le fichier que je t'enverrai, spécialement conçu pour
l'occasion, avec la même clé générée. Tu publies le chiffré sur ton site
ainsi qu'une archive chiffrée (GnuPg) contenant le clair, la clé et le
chiffré. Tu publies également l'archive, mais tu gardes la clé de
l'archive au secret.

À ce stade, je ne dispose que du clair que j'ai généré, du chiffré que tu
as obtenu à partir de mon clair ainsi que ton texte chiffré.

4/ Si tout va bien de mon côté, je publie la version déchiffrée de ton
texte et tu publies ensuite la clé de chiffrement GnuPg pour que tout un
chacun puisse vérifier en ouvrant l'archive chiffrée qui contient le
clair, la clé et le chiffré.

Si tu as bien suivi, je pense être capable de casser ton algorithme avec
une attaque de type "clair choisi". En te fournissant un fichier à
chiffrer, je peux déduire la clé en confrontant le clair et le chiffré.
La preuve du décryptage sera fournie par le déchiffrement de ton fichier
chiffré que tu as rendu public ainsi que par la vérification du résultat
grâce au contenu de l'archive chiffrée avec Gnupg.

Liens utiles:

* Site contenant l'implémentation de référence
http://dimooz.free.fr/void/cena/index.php

* Site de l'algorithme CENA
http://dimooz.free.fr/void/cena/principe.php

* La preuve de concept de la cryptanalyse (ne changera pas)
https://sekur.sbgodin.fr/svn/cena/tags/cena10avr2012-cryptanalyse-base/

* Mes travaux (en changement constant, en développement)
https://sekur.sbgodin.fr/svn/cena/trunk/

* TortoiseSVN, pour télécharger confortablement mes codes sources
http://tortoisesvn.net/downloads.html

La prochaine étape sera peut-être ensuite le cassage via une attaque
"chiffré seul". Cependant, la faiblesse de l'algorithme est démontrée.

Cordialement à tous,

--
Christophe HENRY
FR EO EN - http://www.sbgodin.fr

[Christophe HENRY]

Le Tue, 10 Apr 2012 20:06:41 +0000, Christophe HENRY a écrit :

> Le Tue, 03 Apr 2012 11:19:19 +0200, Philippe Lheureux a écrit :
>

>> (...)

>> Ben vas y , casse le puisqu'il est si nul que ça :-) et même sans le
>> casser car cela prendrait du temps , qu'est ce qui te fais dire qu'il
>> est nul ? on t'écoutes attentivement !
>
> Je répond à la question, bien qu'elle ne m'était pas adressée ;-)
> J'ai cassé ton algorithme.

> (...)

J'ai documenté la cryptanalyse de l'algorithme CENA sur mon blog. En
voici un passage peut-être intéressant :

""""""""""""""""""""""
Sans connaître l'algorithme, on analyse les rapports clairs/chiffrés. On
constate que la taille des chiffrés est toujours égale à 17 fois celle du
clair. En ne chiffrant qu'un seul caractère de façon répétitive, on
s'aperçoit vite que 2 des dix-sept caractères ne varient pas, certains
variant un peu plus et d'autres sont quasiment aléatoires. En chiffrant
deux caractères identiques, on s'aperçoit que les chiffres non-aléatoires
restent les mêmes mais que leur position à changé. À cette étape, on sait
déjà que (à une clé donnée) la substitution ne dépend que du caractère et
que la transposition ne dépend que de la position du caractère. La
cryptanalyse ici consiste à retrouver une clé en soumettant à volonté des
clairs. En fait, la vraie clé n'est retrouvée mais seulement une clé
inverse. En poussant plus loin l'analyse, il serait possible de créer une
clé et de chiffrer des messages.
""""""""""""""""""""""

Le reste se trouve ici :
http://blog.sbgodin.fr/index.php?2012/04/22/23/46/21-cryptanalyse-de-
lalgorithme-cenav03

Bonne soirée à tous.

[Jean-Marc Desperrier]

Christophe HENRY a écrit :

>> Ben vas y , casse le puisqu'il est si nul que ça:-) et même sans le
>> casser car cela prendrait du temps , qu'est ce qui te fais dire qu'il
>> est nul ? on t'écoutes attentivement !

> [...] je voudrais te demander deux choses.

> B/ Qu'on fasse un test de cryptanalyse en grandeur réelle :

> [...]

> Si tu as bien suivi, je pense être capable de casser ton algorithme avec

> une attaque de type "clair choisi". [...]

Je pense qu'il y aurait de la part de Philippe une certaine démarche
d’honnêteté à accepter de boire la coupe jusqu'à la lie, et se soumettre
à ce test.

Demander à chaque fois à ce qu'on teste ses tentatives d'algorithme, et
de l'autre, faire le mort si quelqu'un s'avère visiblement déterminé à
relever le défi pour démontrer qu'il a su casser facilement l'algorithme
est un peu agaçant.

[Ph. B.]

Jean-Marc Desperrier 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... ;-)
--
Philippe.

[Philippe Lheureux]

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

[Christophe HENRY]

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

[Philippe Lheureux]

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.

C'est quand même étrange que Dimitri ait compris du premier coup au point de
pouvoir le programmer facilement :-)
Et pour le complément d'information , il suffit de demander , c'est gratuit
!

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

Non pas du tout .. la clé sera de la longueur du clair comme pour le masque
jetable. Pour créer le masque , on part d'une clé et la moindre modif de la
clé change complètement le masque. C'est comme du MD5 a l'envers .. au lieu
de comprimer , ça expanse.
Tu verras ça bientôt .. je t'enverrais bien le principe par mail mais comme
tu ne parles pas ma langue , tu ferais mieux d'attendre l'implémentation de
Dimitri :-)

[Jean-Marc Desperrier]

Philippe Lheureux a écrit :

> Pour créer le masque , on part d'une clé et la moindre modif de la clé
> change complètement le masque. C'est comme du MD5 a l'envers .. au lieu
> de comprimer , ça expanse.

C'est bien, tu viens de comprendre le principe des algorithmes de
chiffrement de flux.

Seulement, il en existe déjà beaucoup et ils ne sont pas toujours
évident à maîtriser, exemple les malheurs du RC4 et du WEP en Wifi.

[Philippe Lheureux]

C'est bien, tu viens de comprendre le principe des algorithmes de
chiffrement de flux.

Seulement, il en existe déjà beaucoup et ils ne sont pas toujours
évident à maîtriser, exemple les malheurs du RC4 et du WEP en Wifi.

Sauf que le masque du mien est à base de SHA-256 Salé par la clé puis
substitué par les caractères devant former le masque. Il ne reste plus qu'à
attendre que Dimitri ( le programmeur ) ait le temps de le programmer et
nous vous le proposerons pour test. Le résultat final est très proche de la
sécurité d'un masque jetable et permet d'éviter d'avoir à transmettre le
masque.

[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]

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]

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.