Cryptographie par encapsculage hasardeux

xtof pernod

18/08/2010 à 00:08

Le 17/08/2010 22:40, Stephane CARPENTIER a fait rien qu'à écrire::

xtof pernod a écrit:
Le 17/08/2010 19:56, Stephane CARPENTIER a fait rien qu'à écrire::
J'ai du mal à voir une différence statistique entre trouver une lettre et
trouver un intervalle.

Simple: vu sous l'angle d'un codage arithmétique, il n'y a (pratiquement)
aucune statistique qui remonte, dans le flux chiffré.

Je suppose, trivialement, que la taille d'un interval représente la
fréquence d'un symbole.

D'après ce qu'il a écrit, ta supposition est fausse.

Je reformule: je supposerai, afin d'implémenter quelque chose (fortement)
inspiré du petit 1), que la taille d'un interval représente la fréquence d'un
symbole.

Ceci afin de permettre un codage arithmétique qui, potentiellement, ne
laissera pas apparaitre de fréquences exploitables (à prouver); de plus,
utlisant un nombre non entier de bits par symbole, l'attaque risque d'
être assez lourde à mettre en oeuvre (?)

Pour mémoire, il a écrit ça :
(...)
Ses intervalles font donc tous plus ou moins la même taille.

Certes.

De plus, le 1er interval démarre à 10000, ce qui laisse supposer qu'il y
a de la substitution (potentiellement naïve) après coup.

Tu connais à peu près les limites de chaque intervalle, en faisant une
divcision rapide, ensuite, tu afines. Si les féquences de veux valeurs
collées sont très différentes, ça veut dire qu'il y a un changement
d'intervalle.

Le décodage ne peut s'effectuer si & ssi le
décodeur a *exactement* la même table de fréquence.

Que tu remplaces une lettre par un chiffre, par une couleur, par un dessin
ou par un intervalle, le principe est toujours le même. C'est du 1 pour 1.

Ca laisse un nombre de possibilités exponentiel, et potentiellement
intractable. (A moins d'autre attaque sur la clef générant la table, bien
sûr)

Pas d'après sa façon de présenter les choses.

C'est pour ça que je tente d'améliorer -modestement- le basard

Lui, il ne compresse pas, il décompresse. Et plutôt dix fois qu'une.

Oui, ça se voit assez vite, mais apparament ça lui pose pas de soucis.
Bon: rajouter dans les 'specs': "Cet algo est impropre à la transmission."

Au 'règlage' minimum, il rajoutera 1 bit par symbole en moyenne.

(...)
D'un autre côté, c'est pas tous les jours qu'on tombe sur un algo dont la
sécurité est démontrable.

Maintenant, si. Pour les trucs sérieux bien sûr.

Hein/Quoi ?

D'où mon interêt pour la phase 1) -- je pense
pas que l'OP s'embêtera à formaliser le reste, malgré la demande.

Je ne commenterai pas cette phrase.

Bon, je vois bien un truc genre:
. générer pseudo-aléatoirement une table d'intervalles/fréquences
Comme ce n'est pas ça qui est discuté, un algo. naïf conviendra;
. compresser le message par codage arithmétique statique
Sans perte de généralité, on le supposera constitué de 27 symboles,
c'est juste pour monter le concept.

Le flux chiffré aura les qualités statistiques d'un flux compressé
par AC, ce qui le rend assez dur à attaquer.

Pour le reste, je ne parlerai qu'en présence de mon programmeur.

--
christophe.

Le 17/08/2010 22:40, Stephane CARPENTIER a fait rien qu'à écrire::

xtof pernod a écrit:

Le 17/08/2010 19:56, Stephane CARPENTIER a fait rien qu'à écrire::

J'ai du mal à voir une différence statistique entre trouver une lettre et
trouver un intervalle.

Simple: vu sous l'angle d'un codage arithmétique, il n'y a (pratiquement)
aucune statistique qui remonte, dans le flux chiffré.

Je suppose, trivialement, que la taille d'un interval représente la
fréquence d'un symbole.

D'après ce qu'il a écrit, ta supposition est fausse.

Je reformule: je supposerai, afin d'implémenter quelque chose (fortement)
inspiré du petit 1), que la taille d'un interval représente la fréquence d'un
symbole.

Ceci afin de permettre un codage arithmétique qui, potentiellement, ne
laissera pas apparaitre de fréquences exploitables (à prouver); de plus,
utlisant un nombre non entier de bits par symbole, l'attaque risque d'
être assez lourde à mettre en oeuvre (?)

Pour mémoire, il a écrit ça :
(...)
Ses intervalles font donc tous plus ou moins la même taille.

Certes.

De plus, le 1er interval démarre à 10000, ce qui laisse supposer qu'il y
a de la substitution (potentiellement naïve) après coup.

Tu connais à peu près les limites de chaque intervalle, en faisant une
divcision rapide, ensuite, tu afines. Si les féquences de veux valeurs
collées sont très différentes, ça veut dire qu'il y a un changement
d'intervalle.

Le décodage ne peut s'effectuer si & ssi le
décodeur a *exactement* la même table de fréquence.

Que tu remplaces une lettre par un chiffre, par une couleur, par un dessin
ou par un intervalle, le principe est toujours le même. C'est du 1 pour 1.

Ca laisse un nombre de possibilités exponentiel, et potentiellement
intractable. (A moins d'autre attaque sur la clef générant la table, bien
sûr)

Pas d'après sa façon de présenter les choses.

C'est pour ça que je tente d'améliorer -modestement- le basard

Lui, il ne compresse pas, il décompresse. Et plutôt dix fois qu'une.

Oui, ça se voit assez vite, mais apparament ça lui pose pas de soucis.
Bon: rajouter dans les 'specs': "Cet algo est impropre à la transmission."

Au 'règlage' minimum, il rajoutera 1 bit par symbole en moyenne.

(...)

D'un autre côté, c'est pas tous les jours qu'on tombe sur un algo dont la
sécurité est démontrable.

Maintenant, si. Pour les trucs sérieux bien sûr.

Hein/Quoi ?

D'où mon interêt pour la phase 1) -- je pense
pas que l'OP s'embêtera à formaliser le reste, malgré la demande.

Je ne commenterai pas cette phrase.

Bon, je vois bien un truc genre:
. générer pseudo-aléatoirement une table d'intervalles/fréquences
Comme ce n'est pas ça qui est discuté, un algo. naïf conviendra;
. compresser le message par codage arithmétique statique
Sans perte de généralité, on le supposera constitué de 27 symboles,
c'est juste pour monter le concept.

Le flux chiffré aura les qualités statistiques d'un flux compressé
par AC, ce qui le rend assez dur à attaquer.

Pour le reste, je ne parlerai qu'en présence de mon programmeur.

--
christophe.

Vous avez filtré cet utilisateur ! Consultez son message

Le 17/08/2010 22:40, Stephane CARPENTIER a fait rien qu'à écrire::

xtof pernod a écrit:
Le 17/08/2010 19:56, Stephane CARPENTIER a fait rien qu'à écrire::
J'ai du mal à voir une différence statistique entre trouver une lettre et
trouver un intervalle.

Simple: vu sous l'angle d'un codage arithmétique, il n'y a (pratiquement)
aucune statistique qui remonte, dans le flux chiffré.

Je suppose, trivialement, que la taille d'un interval représente la
fréquence d'un symbole.

D'après ce qu'il a écrit, ta supposition est fausse.

Je reformule: je supposerai, afin d'implémenter quelque chose (fortement)
inspiré du petit 1), que la taille d'un interval représente la fréquence d'un
symbole.

Ceci afin de permettre un codage arithmétique qui, potentiellement, ne
laissera pas apparaitre de fréquences exploitables (à prouver); de plus,
utlisant un nombre non entier de bits par symbole, l'attaque risque d'
être assez lourde à mettre en oeuvre (?)

Pour mémoire, il a écrit ça :
(...)
Ses intervalles font donc tous plus ou moins la même taille.

Certes.

De plus, le 1er interval démarre à 10000, ce qui laisse supposer qu'il y
a de la substitution (potentiellement naïve) après coup.

Tu connais à peu près les limites de chaque intervalle, en faisant une
divcision rapide, ensuite, tu afines. Si les féquences de veux valeurs
collées sont très différentes, ça veut dire qu'il y a un changement
d'intervalle.

Le décodage ne peut s'effectuer si & ssi le
décodeur a *exactement* la même table de fréquence.

Que tu remplaces une lettre par un chiffre, par une couleur, par un dessin
ou par un intervalle, le principe est toujours le même. C'est du 1 pour 1.

Ca laisse un nombre de possibilités exponentiel, et potentiellement
intractable. (A moins d'autre attaque sur la clef générant la table, bien
sûr)

Pas d'après sa façon de présenter les choses.

C'est pour ça que je tente d'améliorer -modestement- le basard

Lui, il ne compresse pas, il décompresse. Et plutôt dix fois qu'une.

Oui, ça se voit assez vite, mais apparament ça lui pose pas de soucis.
Bon: rajouter dans les 'specs': "Cet algo est impropre à la transmission."

Au 'règlage' minimum, il rajoutera 1 bit par symbole en moyenne.

(...)
D'un autre côté, c'est pas tous les jours qu'on tombe sur un algo dont la
sécurité est démontrable.

Maintenant, si. Pour les trucs sérieux bien sûr.

Hein/Quoi ?

D'où mon interêt pour la phase 1) -- je pense
pas que l'OP s'embêtera à formaliser le reste, malgré la demande.

Je ne commenterai pas cette phrase.

Bon, je vois bien un truc genre:
. générer pseudo-aléatoirement une table d'intervalles/fréquences
Comme ce n'est pas ça qui est discuté, un algo. naïf conviendra;
. compresser le message par codage arithmétique statique
Sans perte de généralité, on le supposera constitué de 27 symboles,
c'est juste pour monter le concept.

Le flux chiffré aura les qualités statistiques d'un flux compressé
par AC, ce qui le rend assez dur à attaquer.

Pour le reste, je ne parlerai qu'en présence de mon programmeur.

--
christophe.

Guy Ratajczak

18/08/2010 à 08:57

Salut !

Le 17/08/2010 21:33, xtof pernod a écrit :

Le 17/08/2010 20:56, Guy Ratajczak a fait rien qu'à écrire::

Moi j'dis qu'c'est un peu facile de foutre les jetons à tout l'monde, en

Bon, il a une excuse, en ce moment il est occupé expliquer des subtilités
sur les disks durs à un autre neuneu, dans un autre groupe bien sûr..

Bon OK, respect.

réveillant, finalement, le SEUL gars de fr.misc.cryptologie qui ne peut

Le /seul/ ? je tiens le pari.. dans les derniers mois, il me semble avoir
vu un gars persuadé détenir un algo universel, un autre qui passe ici quand
il n'est pas en maths ou en info, et qui, dans le genre étanche, se pose
là..

Ouais, j'ai été léger là. Mais bon, c'était marrant de faire coller ma
prose à celle de Bigard et sa chauve-souris ;-)

(Merci) Je me demande si je vais pas faire une petite implémentation, si je
trouve des candidats pour jouer avec moi -- tant il est vrai que si ça
passe
pas en pratique, c'est que le théorique n'est peut-être pas bon..

Houla ! Attention, terrain dangereux. Pour avoir implémenté et cassé
(avec l'aide de Christophe Henry) l'algo de Raymond H, je te confirme
que ce n'est pas une bonne idée.
Le seul résultat a été qu'il a complexifié le processus à outrance sans
en améliorer la sécurité. Processus tellement complexifié que personne
n'a plus voulu prendre le temps de le recasser.

J'te soutiens quand même.
--
Guy
Vous ne pouvez faire confiance à un algorithme de cryptage créé par
quelqu'un qui n'a pas "fait ses classes" en cassant des codes.
-+- Brian Snow, cryptographe à la NSA -+-

Philippe Lheureux

18/08/2010 à 11:40

Je reformule: je supposerai, afin d'implémenter quelque chose (fortement)
inspiré du petit 1), que la taille d'un interval représente la fréquence
d'un symbole.

Faisable mais comment tu fais pour les 1 et les 0 d'une image ? il n'y a
pas que des lettres a chiffrer et a positionner dans l'intervalle.
L'intérêt de l'intervalle est de produire au moins 351 possibilités de
produire un nombre a 5 chiffres pour chiffrer chaque caractères. On peut
effectivement augmenter ou diminuer certains intervalles pour tenir compte
du tableau des fréquences mais cela n'a pas grand intérêt du fait de la
suite de l'algo qui va camoufler le résultat obtenu.

Admettons que la lettre B se chiffre par 25789 situé dans l'intervalle 25500
a 25800. la clé suivante mélange l'ordre des 5 chiffres obtenus avant de
les incorporer dans un numéro aléatoire a 16 chiffres et c'est la que cela
se complique pour celui qui veut déchiffrer car l'ordre et le mélange sont
différents 16 fois de suite. La deuxième clé est une clé qui contient aussi
256 chiffres montrant la position et l'ordre du mélange.

xtof pernod

18/08/2010 à 11:57

Le 18/08/2010 08:57, mais Guy Ratajczak a fait rien qu'à écrire::

Salut !

Jour',

Le 17/08/2010 21:33, xtof pernod a écrit :
Le 17/08/2010 20:56, Guy Ratajczak a fait rien qu'à écrire::
(...) le SEUL gars de fr.misc.cryptologie qui ne peut

Le /seul/ ? je tiens le pari..(...)

Ouais, j'ai été léger là. Mais bon, c'était marrant de faire coller ma
prose à celle de Bigard et sa chauve-souris ;-)

WaH/Pinaise, elle m'est passé au dessus, celle-là, sorry =)

(Merci) Je me demande si je vais pas faire une petite implémentation, si je
trouve des candidats pour jouer avec moi -- tant il est vrai que si ça
passe pas en pratique, c'est que le théorique n'est peut-être pas bon..

Houla ! Attention, terrain dangereux. Pour avoir implémenté et cassé
(avec l'aide de Christophe Henry) l'algo de Raymond H, je te confirme
que ce n'est pas une bonne idée.

Hein ?! Mais pourquoi cela ? Que peut-il y avoir de mal à casser un algo
lâché un jour de pluie sur usenet ? (Raymond: not found, qu'est-ce qu'il
fait dans la vie: pêcheur de fond, expert en Champolionique aigüe ?...)

Le seul résultat a été qu'il a complexifié le processus à outrance sans
en améliorer la sécurité. Processus tellement complexifié que personne
n'a plus voulu prendre le temps de le recasser.

aoké. je reprécise parce que ça n'a pas du apparaitre clairement:
je prends le point 1) uniquement, qui est le seul que j'ai capté:
. Affecter à chaque symbole un interval de taille imprédictible,
sauf à avoir la clé privée
. Se servir de ces intervalles en codage arithmétique, qui masquera
(peut-être ?!) toute propriété statistique

2 défauts:
. le chiffré sera plus grand que le clair, en fonction directe
de la 'sécurité' désirée
. Si le texte est trop petit: possibilité d'attaque exhaustive
sur le chiffré; si le texte est suffisament grand: attaque
statistique, les symboles les plus courants finiront par
exhiber les mêmes motifs ('patterns') binaires..

J'te soutiens quand même.

Ah bah c'est ben jôntyl -- affute ton compilateur préféré, je finis de
me battre avec quelque drives non libres et je m'y mets ; je sens
confusément qu'il va falloir une phase préalable de substitution,
sinon le 'A' sera toujours le 1er. Quand on commence à rajouter
des complications..

--
christophe. [en même temps, Bigard, suis plus tellement client..]

Le 18/08/2010 08:57, mais Guy Ratajczak a fait rien qu'à écrire::

Salut !

Jour',

Le 17/08/2010 21:33, xtof pernod a écrit :

Le 17/08/2010 20:56, Guy Ratajczak a fait rien qu'à écrire::

(...) le SEUL gars de fr.misc.cryptologie qui ne peut

Le /seul/ ? je tiens le pari..(...)

Ouais, j'ai été léger là. Mais bon, c'était marrant de faire coller ma
prose à celle de Bigard et sa chauve-souris ;-)

WaH/Pinaise, elle m'est passé au dessus, celle-là, sorry =)

(Merci) Je me demande si je vais pas faire une petite implémentation, si je
trouve des candidats pour jouer avec moi -- tant il est vrai que si ça
passe pas en pratique, c'est que le théorique n'est peut-être pas bon..

Houla ! Attention, terrain dangereux. Pour avoir implémenté et cassé
(avec l'aide de Christophe Henry) l'algo de Raymond H, je te confirme
que ce n'est pas une bonne idée.

Hein ?! Mais pourquoi cela ? Que peut-il y avoir de mal à casser un algo
lâché un jour de pluie sur usenet ? (Raymond: not found, qu'est-ce qu'il
fait dans la vie: pêcheur de fond, expert en Champolionique aigüe ?...)

Le seul résultat a été qu'il a complexifié le processus à outrance sans
en améliorer la sécurité. Processus tellement complexifié que personne
n'a plus voulu prendre le temps de le recasser.

aoké. je reprécise parce que ça n'a pas du apparaitre clairement:
je prends le point 1) uniquement, qui est le seul que j'ai capté:
. Affecter à chaque symbole un interval de taille imprédictible,
sauf à avoir la clé privée
. Se servir de ces intervalles en codage arithmétique, qui masquera
(peut-être ?!) toute propriété statistique

2 défauts:
. le chiffré sera plus grand que le clair, en fonction directe
de la 'sécurité' désirée
. Si le texte est trop petit: possibilité d'attaque exhaustive
sur le chiffré; si le texte est suffisament grand: attaque
statistique, les symboles les plus courants finiront par
exhiber les mêmes motifs ('patterns') binaires..

J'te soutiens quand même.

Ah bah c'est ben jôntyl -- affute ton compilateur préféré, je finis de
me battre avec quelque drives non libres et je m'y mets ; je sens
confusément qu'il va falloir une phase préalable de substitution,
sinon le 'A' sera toujours le 1er. Quand on commence à rajouter
des complications..

--
christophe. [en même temps, Bigard, suis plus tellement client..]

Vous avez filtré cet utilisateur ! Consultez son message

Le 18/08/2010 08:57, mais Guy Ratajczak a fait rien qu'à écrire::

Salut !

Jour',

Le 17/08/2010 21:33, xtof pernod a écrit :
Le 17/08/2010 20:56, Guy Ratajczak a fait rien qu'à écrire::
(...) le SEUL gars de fr.misc.cryptologie qui ne peut

Le /seul/ ? je tiens le pari..(...)

Ouais, j'ai été léger là. Mais bon, c'était marrant de faire coller ma
prose à celle de Bigard et sa chauve-souris ;-)

WaH/Pinaise, elle m'est passé au dessus, celle-là, sorry =)

(Merci) Je me demande si je vais pas faire une petite implémentation, si je
trouve des candidats pour jouer avec moi -- tant il est vrai que si ça
passe pas en pratique, c'est que le théorique n'est peut-être pas bon..

Houla ! Attention, terrain dangereux. Pour avoir implémenté et cassé
(avec l'aide de Christophe Henry) l'algo de Raymond H, je te confirme
que ce n'est pas une bonne idée.

Hein ?! Mais pourquoi cela ? Que peut-il y avoir de mal à casser un algo
lâché un jour de pluie sur usenet ? (Raymond: not found, qu'est-ce qu'il
fait dans la vie: pêcheur de fond, expert en Champolionique aigüe ?...)

Le seul résultat a été qu'il a complexifié le processus à outrance sans
en améliorer la sécurité. Processus tellement complexifié que personne
n'a plus voulu prendre le temps de le recasser.

aoké. je reprécise parce que ça n'a pas du apparaitre clairement:
je prends le point 1) uniquement, qui est le seul que j'ai capté:
. Affecter à chaque symbole un interval de taille imprédictible,
sauf à avoir la clé privée
. Se servir de ces intervalles en codage arithmétique, qui masquera
(peut-être ?!) toute propriété statistique

2 défauts:
. le chiffré sera plus grand que le clair, en fonction directe
de la 'sécurité' désirée
. Si le texte est trop petit: possibilité d'attaque exhaustive
sur le chiffré; si le texte est suffisament grand: attaque
statistique, les symboles les plus courants finiront par
exhiber les mêmes motifs ('patterns') binaires..

J'te soutiens quand même.

Ah bah c'est ben jôntyl -- affute ton compilateur préféré, je finis de
me battre avec quelque drives non libres et je m'y mets ; je sens
confusément qu'il va falloir une phase préalable de substitution,
sinon le 'A' sera toujours le 1er. Quand on commence à rajouter
des complications..

--
christophe. [en même temps, Bigard, suis plus tellement client..]

xtof pernod

18/08/2010 à 12:41

Le 18/08/2010 11:40, Philippe Lheureux a fait rien qu'à écrire::

Je reformule: je supposerai, afin d'implémenter quelque chose (fortement)
inspiré du petit 1), que la taille d'un interval représente la
fréquence d'un symbole.

Faisable mais comment tu fais pour les 1 et les 0 d'une image ?

Ca me parait gonflé de ne travailler qu'avec 2 symboles; bien qu'en
théorie, on peut, ça facilite grandement l'attaque sur texte chiffré..

il n'y a
pas que des lettres a chiffrer et a positionner dans l'intervalle.

ok.. je vois.
Si je te dis que l'alphabet peut être de taille arbitraire,
tu vas me regarder de travers ?!..

L'intérêt de l'intervalle est de produire au moins 351 possibilités de

Je sais pas d'où tu sors cette constante, et je ne vois pas "l'intérêt".
Pour ma part, je propose une taille maximale d'interval, en fonction de
la "sécurité" désirée: plus l'interval max. est grand, plus le nombre
d'essais de déchiffrement devra être grand.

produire un nombre a 5 chiffres pour chiffrer chaque caractères. On peut

Au bat mot, +15 bits par symbole codé. Ca fait beaucoup. Mais, admettons.

effectivement augmenter ou diminuer certains intervalles pour tenir
compte du tableau des fréquences mais cela n'a pas grand intérêt du fait
de la suite de l'algo qui va camoufler le résultat obtenu.

C'est ici au plus que les points de vue divergent; mais ne sois pas inquiet,
si jamais il en sort qq chose, ça comportera la mention: "Cet algo. est basé
sur le point 1) du message <4c69a889$0$5402$
de P. Lheureux" -- ou toute mention à ta convenance.

Admettons que la lettre B se chiffre par 25789 situé dans l'intervalle
25500 a 25800. la clé suivante mélange l'ordre des 5 chiffres obtenus
avant de les incorporer dans un numéro aléatoire a 16 chiffres et c'est
la que cela se complique pour celui qui veut déchiffrer car l'ordre et
le mélange sont différents 16 fois de suite. La deuxième clé est une clé
qui contient aussi 256 chiffres montrant la position et l'ordre du mélange.

+ Grosse taille de clé, donc.. Mais je n'ai pas suivi cette partie.

--
christophe.

Le 18/08/2010 11:40, Philippe Lheureux a fait rien qu'à écrire::

Je reformule: je supposerai, afin d'implémenter quelque chose (fortement)
inspiré du petit 1), que la taille d'un interval représente la
fréquence d'un symbole.

Faisable mais comment tu fais pour les 1 et les 0 d'une image ?

Ca me parait gonflé de ne travailler qu'avec 2 symboles; bien qu'en
théorie, on peut, ça facilite grandement l'attaque sur texte chiffré..

il n'y a
pas que des lettres a chiffrer et a positionner dans l'intervalle.

ok.. je vois.
Si je te dis que l'alphabet peut être de taille arbitraire,
tu vas me regarder de travers ?!..

L'intérêt de l'intervalle est de produire au moins 351 possibilités de

Je sais pas d'où tu sors cette constante, et je ne vois pas "l'intérêt".
Pour ma part, je propose une taille maximale d'interval, en fonction de
la "sécurité" désirée: plus l'interval max. est grand, plus le nombre
d'essais de déchiffrement devra être grand.

produire un nombre a 5 chiffres pour chiffrer chaque caractères. On peut

Au bat mot, +15 bits par symbole codé. Ca fait beaucoup. Mais, admettons.

effectivement augmenter ou diminuer certains intervalles pour tenir
compte du tableau des fréquences mais cela n'a pas grand intérêt du fait
de la suite de l'algo qui va camoufler le résultat obtenu.

C'est ici au plus que les points de vue divergent; mais ne sois pas inquiet,
si jamais il en sort qq chose, ça comportera la mention: "Cet algo. est basé
sur le point 1) du message <4c69a889$0$5402$ba4acef3@reader.news.orange.fr>
de P. Lheureux" -- ou toute mention à ta convenance.

Admettons que la lettre B se chiffre par 25789 situé dans l'intervalle
25500 a 25800. la clé suivante mélange l'ordre des 5 chiffres obtenus
avant de les incorporer dans un numéro aléatoire a 16 chiffres et c'est
la que cela se complique pour celui qui veut déchiffrer car l'ordre et
le mélange sont différents 16 fois de suite. La deuxième clé est une clé
qui contient aussi 256 chiffres montrant la position et l'ordre du mélange.

+ Grosse taille de clé, donc.. Mais je n'ai pas suivi cette partie.

--
christophe.

Vous avez filtré cet utilisateur ! Consultez son message

Le 18/08/2010 11:40, Philippe Lheureux a fait rien qu'à écrire::

Je reformule: je supposerai, afin d'implémenter quelque chose (fortement)
inspiré du petit 1), que la taille d'un interval représente la
fréquence d'un symbole.

Faisable mais comment tu fais pour les 1 et les 0 d'une image ?

Ca me parait gonflé de ne travailler qu'avec 2 symboles; bien qu'en
théorie, on peut, ça facilite grandement l'attaque sur texte chiffré..

il n'y a
pas que des lettres a chiffrer et a positionner dans l'intervalle.

ok.. je vois.
Si je te dis que l'alphabet peut être de taille arbitraire,
tu vas me regarder de travers ?!..

L'intérêt de l'intervalle est de produire au moins 351 possibilités de

Je sais pas d'où tu sors cette constante, et je ne vois pas "l'intérêt".
Pour ma part, je propose une taille maximale d'interval, en fonction de
la "sécurité" désirée: plus l'interval max. est grand, plus le nombre
d'essais de déchiffrement devra être grand.

produire un nombre a 5 chiffres pour chiffrer chaque caractères. On peut

Au bat mot, +15 bits par symbole codé. Ca fait beaucoup. Mais, admettons.

effectivement augmenter ou diminuer certains intervalles pour tenir
compte du tableau des fréquences mais cela n'a pas grand intérêt du fait
de la suite de l'algo qui va camoufler le résultat obtenu.

C'est ici au plus que les points de vue divergent; mais ne sois pas inquiet,
si jamais il en sort qq chose, ça comportera la mention: "Cet algo. est basé
sur le point 1) du message <4c69a889$0$5402$
de P. Lheureux" -- ou toute mention à ta convenance.

Admettons que la lettre B se chiffre par 25789 situé dans l'intervalle
25500 a 25800. la clé suivante mélange l'ordre des 5 chiffres obtenus
avant de les incorporer dans un numéro aléatoire a 16 chiffres et c'est
la que cela se complique pour celui qui veut déchiffrer car l'ordre et
le mélange sont différents 16 fois de suite. La deuxième clé est une clé
qui contient aussi 256 chiffres montrant la position et l'ordre du mélange.

+ Grosse taille de clé, donc.. Mais je n'ai pas suivi cette partie.

--
christophe.

Philippe Lheureux

18/08/2010 à 13:31

Je sais pas d'où tu sors cette constante, et je ne vois pas "l'intérêt".
Pour ma part, je propose une taille maximale d'interval, en fonction de
la "sécurité" désirée: plus l'interval max. est grand, plus le nombre
d'essais de déchiffrement devra être grand.

Simple 99999-10000 = 89999 que je divise par 256 caractères a chiffrer , ce
qui fait 351.55 possibilité par caractère. Il serait bien sur possible de
prendre des intervalles entre 999999 et 100000 ce qui ferait 3515
possibilités de chiffrage par lettre. ( pas si mal :-)
Dans ce cas la , il faut mélanger le nombre a 6 chiffres obtenu et
l'incorporer dans un numéro produit aléatoirement .

C'est ici au plus que les points de vue divergent; mais ne sois pas
inquiet,
si jamais il en sort qq chose, ça comportera la mention: "Cet algo. est
basé
sur le point 1) du message
<4c69a889$0$5402$
de P. Lheureux" -- ou toute mention à ta convenance.

Pas de problème mais j'aurais bien aimé que tu fasses aussi les points
suivants .. qu'est ce que tu leur reproches ?

la suite consisterait en la production d'une clé de 256 caractères ( 16
series de 16 chiffres ) montrant l'ordre et la position des nombres pris
dans l'intervalle ..
exemple si B est codé 156815

on produit une première clé aléatoire pour chiffrer la première lettre
0056002001003400 signifie que le premier 1 de 156815 se trouvera en 10
position dans le mélange avec le chiffre aléatoire .. que le 5 se trouvera
en 7 eme et que le dernier chiffre , le 5 se trouvera en 3 ème position ce
qui revient a mélanger comme ci-après
0015005001006800 ou l'on retrouve bien 156815 mélangé.

on produit ensuite un numéro aléatoire de 16 chiffres
exemple 9541347821654952 et on substitue les 6 chiffres de l'intervalle
pour les mettre a la bonne position dans le numéro aléatoire

on obtient en croisant les deux
0015005001006800
croisé avec
9541347821654952
9515345821656852

suffit de remplacer les 0 par des chiffres aléatoires.

J'aime mieux autant de dire que déjà , a ce stade , si tu n'as pas la clé ,
tu n'es pas dans la merde :-)

ceci dit , afin d'éviter une répétition trop visible de la clé , on produit
16 clé différentes ( ordre et position ) , chacune chiffrant les 16
premières caractères individuellement.

Qu'en penses tu ?

Admettons que la lettre B se chiffre par 25789 situé dans l'intervalle
25500 a 25800. la clé suivante mélange l'ordre des 5 chiffres obtenus
avant de les incorporer dans un numéro aléatoire a 16 chiffres et c'est
la que cela se complique pour celui qui veut déchiffrer car l'ordre et
le mélange sont différents 16 fois de suite. La deuxième clé est une clé
qui contient aussi 256 chiffres montrant la position et l'ordre du
mélange.

+ Grosse taille de clé, donc.. Mais je n'ai pas suivi cette partie.

--
christophe.

__________ Information provenant d'ESET NOD32 Antivirus, version de la
base des signatures de virus 5375 (20100818) __________

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

Je sais pas d'où tu sors cette constante, et je ne vois pas "l'intérêt".
Pour ma part, je propose une taille maximale d'interval, en fonction de
la "sécurité" désirée: plus l'interval max. est grand, plus le nombre
d'essais de déchiffrement devra être grand.

Simple 99999-10000 = 89999 que je divise par 256 caractères a chiffrer , ce
qui fait 351.55 possibilité par caractère. Il serait bien sur possible de
prendre des intervalles entre 999999 et 100000 ce qui ferait 3515
possibilités de chiffrage par lettre. ( pas si mal :-)
Dans ce cas la , il faut mélanger le nombre a 6 chiffres obtenu et
l'incorporer dans un numéro produit aléatoirement .

C'est ici au plus que les points de vue divergent; mais ne sois pas
inquiet,
si jamais il en sort qq chose, ça comportera la mention: "Cet algo. est
basé
sur le point 1) du message
<4c69a889$0$5402$ba4acef3@reader.news.orange.fr>
de P. Lheureux" -- ou toute mention à ta convenance.

Pas de problème mais j'aurais bien aimé que tu fasses aussi les points
suivants .. qu'est ce que tu leur reproches ?

la suite consisterait en la production d'une clé de 256 caractères ( 16
series de 16 chiffres ) montrant l'ordre et la position des nombres pris
dans l'intervalle ..
exemple si B est codé 156815

on produit une première clé aléatoire pour chiffrer la première lettre
0056002001003400 signifie que le premier 1 de 156815 se trouvera en 10
position dans le mélange avec le chiffre aléatoire .. que le 5 se trouvera
en 7 eme et que le dernier chiffre , le 5 se trouvera en 3 ème position ce
qui revient a mélanger comme ci-après
0015005001006800 ou l'on retrouve bien 156815 mélangé.

on produit ensuite un numéro aléatoire de 16 chiffres
exemple 9541347821654952 et on substitue les 6 chiffres de l'intervalle
pour les mettre a la bonne position dans le numéro aléatoire

on obtient en croisant les deux
0015005001006800
croisé avec
9541347821654952
9515345821656852

suffit de remplacer les 0 par des chiffres aléatoires.

J'aime mieux autant de dire que déjà , a ce stade , si tu n'as pas la clé ,
tu n'es pas dans la merde :-)

ceci dit , afin d'éviter une répétition trop visible de la clé , on produit
16 clé différentes ( ordre et position ) , chacune chiffrant les 16
premières caractères individuellement.

Qu'en penses tu ?

Admettons que la lettre B se chiffre par 25789 situé dans l'intervalle
25500 a 25800. la clé suivante mélange l'ordre des 5 chiffres obtenus
avant de les incorporer dans un numéro aléatoire a 16 chiffres et c'est
la que cela se complique pour celui qui veut déchiffrer car l'ordre et
le mélange sont différents 16 fois de suite. La deuxième clé est une clé
qui contient aussi 256 chiffres montrant la position et l'ordre du
mélange.

+ Grosse taille de clé, donc.. Mais je n'ai pas suivi cette partie.

--
christophe.

__________ Information provenant d'ESET NOD32 Antivirus, version de la
base des signatures de virus 5375 (20100818) __________

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

Vous avez filtré cet utilisateur ! Consultez son message

Je sais pas d'où tu sors cette constante, et je ne vois pas "l'intérêt".
Pour ma part, je propose une taille maximale d'interval, en fonction de
la "sécurité" désirée: plus l'interval max. est grand, plus le nombre
d'essais de déchiffrement devra être grand.

Simple 99999-10000 = 89999 que je divise par 256 caractères a chiffrer , ce
qui fait 351.55 possibilité par caractère. Il serait bien sur possible de
prendre des intervalles entre 999999 et 100000 ce qui ferait 3515
possibilités de chiffrage par lettre. ( pas si mal :-)
Dans ce cas la , il faut mélanger le nombre a 6 chiffres obtenu et
l'incorporer dans un numéro produit aléatoirement .

C'est ici au plus que les points de vue divergent; mais ne sois pas
inquiet,
si jamais il en sort qq chose, ça comportera la mention: "Cet algo. est
basé
sur le point 1) du message
<4c69a889$0$5402$
de P. Lheureux" -- ou toute mention à ta convenance.

Pas de problème mais j'aurais bien aimé que tu fasses aussi les points
suivants .. qu'est ce que tu leur reproches ?

la suite consisterait en la production d'une clé de 256 caractères ( 16
series de 16 chiffres ) montrant l'ordre et la position des nombres pris
dans l'intervalle ..
exemple si B est codé 156815

on produit une première clé aléatoire pour chiffrer la première lettre
0056002001003400 signifie que le premier 1 de 156815 se trouvera en 10
position dans le mélange avec le chiffre aléatoire .. que le 5 se trouvera
en 7 eme et que le dernier chiffre , le 5 se trouvera en 3 ème position ce
qui revient a mélanger comme ci-après
0015005001006800 ou l'on retrouve bien 156815 mélangé.

on produit ensuite un numéro aléatoire de 16 chiffres
exemple 9541347821654952 et on substitue les 6 chiffres de l'intervalle
pour les mettre a la bonne position dans le numéro aléatoire

on obtient en croisant les deux
0015005001006800
croisé avec
9541347821654952
9515345821656852

suffit de remplacer les 0 par des chiffres aléatoires.

J'aime mieux autant de dire que déjà , a ce stade , si tu n'as pas la clé ,
tu n'es pas dans la merde :-)

ceci dit , afin d'éviter une répétition trop visible de la clé , on produit
16 clé différentes ( ordre et position ) , chacune chiffrant les 16
premières caractères individuellement.

Qu'en penses tu ?

Admettons que la lettre B se chiffre par 25789 situé dans l'intervalle
25500 a 25800. la clé suivante mélange l'ordre des 5 chiffres obtenus
avant de les incorporer dans un numéro aléatoire a 16 chiffres et c'est
la que cela se complique pour celui qui veut déchiffrer car l'ordre et
le mélange sont différents 16 fois de suite. La deuxième clé est une clé
qui contient aussi 256 chiffres montrant la position et l'ordre du
mélange.

+ Grosse taille de clé, donc.. Mais je n'ai pas suivi cette partie.

--
christophe.

__________ Information provenant d'ESET NOD32 Antivirus, version de la
base des signatures de virus 5375 (20100818) __________

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

Guy Ratajczak

18/08/2010 à 13:32

Le 18/08/2010 11:57, xtof pernod a tapoté :

Le 18/08/2010 08:57, mais Guy Ratajczak a fait rien qu'à écrire::
Houla ! Attention, terrain dangereux. Pour avoir implémenté et cassé
(avec l'aide de Christophe Henry) l'algo de Raymond H, je te confirme
que ce n'est pas une bonne idée.

Hein ?! Mais pourquoi cela ? Que peut-il y avoir de mal à casser un algo
lâché un jour de pluie sur usenet ? (Raymond: not found, qu'est-ce qu'il
fait dans la vie: pêcheur de fond, expert en Champolionique aigüe ?...)

Ah bah notre cher cousin Raymond [1] a rajouté d'obscures étapes pour
rendre son algo complexe et obscur. Résultat, plus personne n'a voulu
perdre de temps à le recasser . Et lui, tout fier, s'est senti conforté
dans l'idée que c'était incassable.

En fait sa proposition de base n'a pas tenue :
- chiffré plus long que le clair ;
- certains bits de sortie se retrouvaient calculé sans la clé (!) ;
- Christophe H a trouvé que plusieurs clés différentes donnaient le même
chiffré ;
- J'ai sorti l'ensemble des clés de 32 bits possibles à partir d'un
clair connu avec un soft de 30 lignes en une fraction de secondes ;
- testé avec 64 bits : explosion du nombre de clés équivalentes et temps
de cassage quasi inchangé. Comme le disait Christophe H, c'était
indépendant de la longueur de clé.

Alors, en repartant de cette base toutepourrie(c) il a rajouté des
étapes qui ne changeaient rien sinon à rendre le cassage de clé plus
complexe à écrire, et à rajouter des failles. Mais rien d'impossible. Il
commercialise son soft...

aoké. je reprécise parce que ça n'a pas du apparaitre clairement:
je prends le point 1) uniquement, qui est le seul que j'ai capté:
. Affecter à chaque symbole un interval de taille imprédictible,
sauf à avoir la clé privée
. Se servir de ces intervalles en codage arithmétique, qui masquera
(peut-être ?!) toute propriété statistique

Tiote question : ce codage arithmétique étant parfaitement réversible,
il ne change rien ou me trompe-je ? On parle bien de la même chose [2] ?

J'te soutiens quand même.

Ah bah c'est ben jôntyl -- affute ton compilateur préféré, je finis de
me battre avec quelque drives non libres et je m'y mets ; je sens
confusément qu'il va falloir une phase préalable de substitution,
sinon le 'A' sera toujours le 1er. Quand on commence à rajouter
des complications..

AMHA pas la peine de rajouter de complications ici. Une substitution
simple va rallonger le travail de casse (et donc nos essais si qq'un s'y
colle) sans rajouter de véritable sécurité. Autant aller au plus simple.
A moins que tu ne parles de S-boxes...

Et le compilateur est toujours affuté. Juste l'utilisateur qui vieillit
mais là l'on n'y peut rien. Dans un grand excès de faiblesse je veux
bien jeter à oeil à ce que tu sortira de l'idée du superlutin, et voir
où sont les faiblesses. J'espère vivement qu'on pourra rapidement sortir
la phrase mythique.

[1] :
http://groups.google.fr/group/fr.misc.cryptologie/browse_frm/thread/cd023bbc6ccdc7e7/bb61dd2ec06edef9?hl=fr&tvc=1&q=raymond+h+mister+jack#bb61dd2ec06edef9

[2] : http://fr.wikipedia.org/wiki/Codage_arithm%C3%A9tique

--
Guy
"Vous ne pouvez faire confiance à un algorithme de cryptage créé par
quelqu'un qui n'a pas /fait ses classes/ en cassant des codes."
-+- Brian Snow, ancien cryptographe à la NSA -+-

Le 18/08/2010 11:57, xtof pernod a tapoté :

Le 18/08/2010 08:57, mais Guy Ratajczak a fait rien qu'à écrire::

Houla ! Attention, terrain dangereux. Pour avoir implémenté et cassé
(avec l'aide de Christophe Henry) l'algo de Raymond H, je te confirme
que ce n'est pas une bonne idée.

Hein ?! Mais pourquoi cela ? Que peut-il y avoir de mal à casser un algo
lâché un jour de pluie sur usenet ? (Raymond: not found, qu'est-ce qu'il
fait dans la vie: pêcheur de fond, expert en Champolionique aigüe ?...)

Ah bah notre cher cousin Raymond [1] a rajouté d'obscures étapes pour
rendre son algo complexe et obscur. Résultat, plus personne n'a voulu
perdre de temps à le recasser . Et lui, tout fier, s'est senti conforté
dans l'idée que c'était incassable.

En fait sa proposition de base n'a pas tenue :
- chiffré plus long que le clair ;
- certains bits de sortie se retrouvaient calculé sans la clé (!) ;
- Christophe H a trouvé que plusieurs clés différentes donnaient le même
chiffré ;
- J'ai sorti l'ensemble des clés de 32 bits possibles à partir d'un
clair connu avec un soft de 30 lignes en une fraction de secondes ;
- testé avec 64 bits : explosion du nombre de clés équivalentes et temps
de cassage quasi inchangé. Comme le disait Christophe H, c'était
indépendant de la longueur de clé.

Alors, en repartant de cette base toutepourrie(c) il a rajouté des
étapes qui ne changeaient rien sinon à rendre le cassage de clé plus
complexe à écrire, et à rajouter des failles. Mais rien d'impossible. Il
commercialise son soft...

aoké. je reprécise parce que ça n'a pas du apparaitre clairement:
je prends le point 1) uniquement, qui est le seul que j'ai capté:
. Affecter à chaque symbole un interval de taille imprédictible,
sauf à avoir la clé privée
. Se servir de ces intervalles en codage arithmétique, qui masquera
(peut-être ?!) toute propriété statistique

Tiote question : ce codage arithmétique étant parfaitement réversible,
il ne change rien ou me trompe-je ? On parle bien de la même chose [2] ?

J'te soutiens quand même.

Ah bah c'est ben jôntyl -- affute ton compilateur préféré, je finis de
me battre avec quelque drives non libres et je m'y mets ; je sens
confusément qu'il va falloir une phase préalable de substitution,
sinon le 'A' sera toujours le 1er. Quand on commence à rajouter
des complications..

AMHA pas la peine de rajouter de complications ici. Une substitution
simple va rallonger le travail de casse (et donc nos essais si qq'un s'y
colle) sans rajouter de véritable sécurité. Autant aller au plus simple.
A moins que tu ne parles de S-boxes...

Et le compilateur est toujours affuté. Juste l'utilisateur qui vieillit
mais là l'on n'y peut rien. Dans un grand excès de faiblesse je veux
bien jeter à oeil à ce que tu sortira de l'idée du superlutin, et voir
où sont les faiblesses. J'espère vivement qu'on pourra rapidement sortir
la phrase mythique.

[1] :
http://groups.google.fr/group/fr.misc.cryptologie/browse_frm/thread/cd023bbc6ccdc7e7/bb61dd2ec06edef9?hl=fr&tvc=1&q=raymond+h+mister+jack#bb61dd2ec06edef9

[2] : http://fr.wikipedia.org/wiki/Codage_arithm%C3%A9tique

--
Guy
"Vous ne pouvez faire confiance à un algorithme de cryptage créé par
quelqu'un qui n'a pas /fait ses classes/ en cassant des codes."
-+- Brian Snow, ancien cryptographe à la NSA -+-

Vous avez filtré cet utilisateur ! Consultez son message

Le 18/08/2010 11:57, xtof pernod a tapoté :

Le 18/08/2010 08:57, mais Guy Ratajczak a fait rien qu'à écrire::
Houla ! Attention, terrain dangereux. Pour avoir implémenté et cassé
(avec l'aide de Christophe Henry) l'algo de Raymond H, je te confirme
que ce n'est pas une bonne idée.

Hein ?! Mais pourquoi cela ? Que peut-il y avoir de mal à casser un algo
lâché un jour de pluie sur usenet ? (Raymond: not found, qu'est-ce qu'il
fait dans la vie: pêcheur de fond, expert en Champolionique aigüe ?...)

Ah bah notre cher cousin Raymond [1] a rajouté d'obscures étapes pour
rendre son algo complexe et obscur. Résultat, plus personne n'a voulu
perdre de temps à le recasser . Et lui, tout fier, s'est senti conforté
dans l'idée que c'était incassable.

En fait sa proposition de base n'a pas tenue :
- chiffré plus long que le clair ;
- certains bits de sortie se retrouvaient calculé sans la clé (!) ;
- Christophe H a trouvé que plusieurs clés différentes donnaient le même
chiffré ;
- J'ai sorti l'ensemble des clés de 32 bits possibles à partir d'un
clair connu avec un soft de 30 lignes en une fraction de secondes ;
- testé avec 64 bits : explosion du nombre de clés équivalentes et temps
de cassage quasi inchangé. Comme le disait Christophe H, c'était
indépendant de la longueur de clé.

Alors, en repartant de cette base toutepourrie(c) il a rajouté des
étapes qui ne changeaient rien sinon à rendre le cassage de clé plus
complexe à écrire, et à rajouter des failles. Mais rien d'impossible. Il
commercialise son soft...

aoké. je reprécise parce que ça n'a pas du apparaitre clairement:
je prends le point 1) uniquement, qui est le seul que j'ai capté:
. Affecter à chaque symbole un interval de taille imprédictible,
sauf à avoir la clé privée
. Se servir de ces intervalles en codage arithmétique, qui masquera
(peut-être ?!) toute propriété statistique

Tiote question : ce codage arithmétique étant parfaitement réversible,
il ne change rien ou me trompe-je ? On parle bien de la même chose [2] ?

J'te soutiens quand même.

Ah bah c'est ben jôntyl -- affute ton compilateur préféré, je finis de
me battre avec quelque drives non libres et je m'y mets ; je sens
confusément qu'il va falloir une phase préalable de substitution,
sinon le 'A' sera toujours le 1er. Quand on commence à rajouter
des complications..

AMHA pas la peine de rajouter de complications ici. Une substitution
simple va rallonger le travail de casse (et donc nos essais si qq'un s'y
colle) sans rajouter de véritable sécurité. Autant aller au plus simple.
A moins que tu ne parles de S-boxes...

Et le compilateur est toujours affuté. Juste l'utilisateur qui vieillit
mais là l'on n'y peut rien. Dans un grand excès de faiblesse je veux
bien jeter à oeil à ce que tu sortira de l'idée du superlutin, et voir
où sont les faiblesses. J'espère vivement qu'on pourra rapidement sortir
la phrase mythique.

[1] :
http://groups.google.fr/group/fr.misc.cryptologie/browse_frm/thread/cd023bbc6ccdc7e7/bb61dd2ec06edef9?hl=fr&tvc=1&q=raymond+h+mister+jack#bb61dd2ec06edef9

[2] : http://fr.wikipedia.org/wiki/Codage_arithm%C3%A9tique

--
Guy
"Vous ne pouvez faire confiance à un algorithme de cryptage créé par
quelqu'un qui n'a pas /fait ses classes/ en cassant des codes."
-+- Brian Snow, ancien cryptographe à la NSA -+-

Philippe Lheureux

18/08/2010 à 13:35

2 défauts:
. le chiffré sera plus grand que le clair, en fonction directe
de la 'sécurité' désirée
. Si le texte est trop petit: possibilité d'attaque exhaustive
sur le chiffré; si le texte est suffisament grand: attaque
statistique, les symboles les plus courants finiront par
exhiber les mêmes motifs ('patterns') binaires..

J'te soutiens quand même.

c'est pour cette raison qu'il y a le deuxième mélange juste derrière.
Prendre la moitié de l'algo et y trouver une faiblesse ne rime pas a grand
chose vu que le tout est plus que la somme des parties.

xtof pernod

18/08/2010 à 14:40

Le 18/08/2010 13:35, Philippe Lheureux a fait rien qu'à écrire::

(Au passage, si tu apprenais à quoter, on y gagnerait en lisibilité =)

2 défauts: (...)
J'te soutiens quand même.

c'est pour cette raison qu'il y a le deuxième mélange juste derrière.

Mélange, le terme est pas mal choisi..

Prendre la moitié de l'algo et y trouver une faiblesse ne rime pas a
grand chose

Oui, tu as entièrement raison sur ce coup-là. Seulement, et c'est le dernier
coup que je le dis, je m'inspire de ce que j'ai compris, ie. le point 1), dont
tu es l'auteur incontesté; de plus je pense faire les choses très differement.

vu que le tout est plus que la somme des parties.

No comment.

--
christophe.

xtof pernod

18/08/2010 à 14:50

Le 18/08/2010 13:32, mais Guy Ratajczak a fait rien qu'à écrire::

Le 18/08/2010 11:57, xtof pernod a tapoté :
Le 18/08/2010 08:57, mais Guy Ratajczak a fait rien qu'à écrire::
Houla ! (...)

Ah bah notre cher cousin Raymond [1] a rajouté d'obscures étapes pour
rendre son algo complexe et obscur. Résultat, plus personne n'a voulu
perdre de temps à le recasser . Et lui, tout fier, s'est senti conforté
dans l'idée que c'était incassable.

Ah oui, ça me dit vaguement qeq' chose. . Ca s'est déja vu, pour sûr.

En fait sa proposition de base n'a pas tenue :
- chiffré plus long que le clair ;

Arf, c'est le cas ici..

- certains bits de sortie se retrouvaient calculé sans la clé (!) ;
- Christophe H a trouvé que plusieurs clés différentes donnaient le même
chiffré ;
- J'ai sorti l'ensemble des clés de 32 bits possibles à partir d'un
clair connu avec un soft de 30 lignes en une fraction de secondes ;

?!? la vache.. Il faut pourtant quelques secondes, pour compter jusqu'à 2^32.
A 1800MHz, tout du mmoins.

- testé avec 64 bits : explosion du nombre de clés équivalentes et temps
de cassage quasi inchangé. Comme le disait Christophe H, c'était
indépendant de la longueur de clé.

Alors, en repartant de cette base toutepourrie(c) il a rajouté des
étapes qui ne changeaient rien sinon à rendre le cassage de clé plus
complexe à écrire, et à rajouter des failles. Mais rien d'impossible. Il
commercialise son soft...

Et il en vit bien ?

aoké. je reprécise parce que ça n'a pas du apparaitre clairement:
je prends le point 1) uniquement, qui est le seul que j'ai capté:
. Affecter à chaque symbole un interval de taille imprédictible,
sauf à avoir la clé privée
. Se servir de ces intervalles en codage arithmétique, qui masquera
(peut-être ?!) toute propriété statistique

Tiote question : ce codage arithmétique étant parfaitement réversible,

Si & Ssi tu as les fréquences cumulées des symboles. Sinon, c'est de la
devinette, à moins d'attaque que je ne connais pas / à deviser.

A voir avec le code, donc.

il ne change rien ou me trompe-je ? On parle bien de la même chose [2] ?

Concrêtement, j'utilise le "Range Coder" de "ppmd", qui fut naguère au top
en matière de compression; (très) légèrement moins 'optimal' que l'arithmé-
tique, il est DP, alors qu'AC est (était ?) sous brevet (IBM ?).

Il a la particularité d'être bijectif, c-à-d que tout flux, y compris sa
propre sortie, constitue un flux d'entrée valide. Indirectement, ce peut
être une qualité en crypto.

J'te soutiens quand même.

Ah bah c'est ben jôntyl -- affute ton compilateur préféré, je finis de
me battre avec quelque drives non libres et je m'y mets ; je sens
confusément qu'il va falloir une phase préalable de substitution,
sinon le 'A' sera toujours le 1er. Quand on commence à rajouter
des complications..

AMHA pas la peine de rajouter de complications ici. Une substitution
simple va rallonger le travail de casse (et donc nos essais si qq'un s'y
colle) sans rajouter de véritable sécurité. Autant aller au plus simple.

Tûtàfé. Je pensais mettre ça en option, débrayable. Ca complique l'attaque,
à peu de frais, mais c'est tout.

A moins que tu ne parles de S-boxes...

Pas franchement, il s'agit que le 'A' ne tombe pas toujours en 1er, mais
seulement 1/27 fois.. Tu vois le genre.

Et le compilateur est toujours affuté. Juste l'utilisateur qui vieillit
mais là l'on n'y peut rien. Dans un grand excès de faiblesse je veux

Mon dieu, vous êtes vieux et faible, mais si vous dégainez le compilo,
rien n'est perdu !

bien jeter à oeil à ce que tu sortira de l'idée du superlutin, et voir

Je re-précise: inspirée de ce que j'ai compris du point 1:)

où sont les faiblesses. J'espère vivement qu'on pourra rapidement sortir
la phrase mythique.

Qui est ? Alleluiha ? Thalassa ? Osannah ? "Vous êtes un crétin" ? All/None
of the above ?

--
christophe.

Le 18/08/2010 13:32, mais Guy Ratajczak a fait rien qu'à écrire::

Le 18/08/2010 11:57, xtof pernod a tapoté :

Le 18/08/2010 08:57, mais Guy Ratajczak a fait rien qu'à écrire::

Houla ! (...)

Ah bah notre cher cousin Raymond [1] a rajouté d'obscures étapes pour
rendre son algo complexe et obscur. Résultat, plus personne n'a voulu
perdre de temps à le recasser . Et lui, tout fier, s'est senti conforté
dans l'idée que c'était incassable.

Ah oui, ça me dit vaguement qeq' chose. . Ca s'est déja vu, pour sûr.

En fait sa proposition de base n'a pas tenue :
- chiffré plus long que le clair ;

Arf, c'est le cas ici..

- certains bits de sortie se retrouvaient calculé sans la clé (!) ;
- Christophe H a trouvé que plusieurs clés différentes donnaient le même
chiffré ;
- J'ai sorti l'ensemble des clés de 32 bits possibles à partir d'un
clair connu avec un soft de 30 lignes en une fraction de secondes ;

?!? la vache.. Il faut pourtant quelques secondes, pour compter jusqu'à 2^32.
A 1800MHz, tout du mmoins.

- testé avec 64 bits : explosion du nombre de clés équivalentes et temps
de cassage quasi inchangé. Comme le disait Christophe H, c'était
indépendant de la longueur de clé.

Alors, en repartant de cette base toutepourrie(c) il a rajouté des
étapes qui ne changeaient rien sinon à rendre le cassage de clé plus
complexe à écrire, et à rajouter des failles. Mais rien d'impossible. Il
commercialise son soft...

Et il en vit bien ?

aoké. je reprécise parce que ça n'a pas du apparaitre clairement:
je prends le point 1) uniquement, qui est le seul que j'ai capté:
. Affecter à chaque symbole un interval de taille imprédictible,
sauf à avoir la clé privée
. Se servir de ces intervalles en codage arithmétique, qui masquera
(peut-être ?!) toute propriété statistique

Tiote question : ce codage arithmétique étant parfaitement réversible,

Si & Ssi tu as les fréquences cumulées des symboles. Sinon, c'est de la
devinette, à moins d'attaque que je ne connais pas / à deviser.

A voir avec le code, donc.

il ne change rien ou me trompe-je ? On parle bien de la même chose [2] ?

Concrêtement, j'utilise le "Range Coder" de "ppmd", qui fut naguère au top
en matière de compression; (très) légèrement moins 'optimal' que l'arithmé-
tique, il est DP, alors qu'AC est (était ?) sous brevet (IBM ?).

Il a la particularité d'être bijectif, c-à-d que tout flux, y compris sa
propre sortie, constitue un flux d'entrée valide. Indirectement, ce peut
être une qualité en crypto.

J'te soutiens quand même.

Ah bah c'est ben jôntyl -- affute ton compilateur préféré, je finis de
me battre avec quelque drives non libres et je m'y mets ; je sens
confusément qu'il va falloir une phase préalable de substitution,
sinon le 'A' sera toujours le 1er. Quand on commence à rajouter
des complications..

AMHA pas la peine de rajouter de complications ici. Une substitution
simple va rallonger le travail de casse (et donc nos essais si qq'un s'y
colle) sans rajouter de véritable sécurité. Autant aller au plus simple.

Tûtàfé. Je pensais mettre ça en option, débrayable. Ca complique l'attaque,
à peu de frais, mais c'est tout.

A moins que tu ne parles de S-boxes...

Pas franchement, il s'agit que le 'A' ne tombe pas toujours en 1er, mais
seulement 1/27 fois.. Tu vois le genre.

Et le compilateur est toujours affuté. Juste l'utilisateur qui vieillit
mais là l'on n'y peut rien. Dans un grand excès de faiblesse je veux

Mon dieu, vous êtes vieux et faible, mais si vous dégainez le compilo,
rien n'est perdu !

bien jeter à oeil à ce que tu sortira de l'idée du superlutin, et voir

Je re-précise: inspirée de ce que j'ai compris du point 1:)

où sont les faiblesses. J'espère vivement qu'on pourra rapidement sortir
la phrase mythique.

Qui est ? Alleluiha ? Thalassa ? Osannah ? "Vous êtes un crétin" ? All/None
of the above ?

--
christophe.

Vous avez filtré cet utilisateur ! Consultez son message

Le 18/08/2010 13:32, mais Guy Ratajczak a fait rien qu'à écrire::

Le 18/08/2010 11:57, xtof pernod a tapoté :
Le 18/08/2010 08:57, mais Guy Ratajczak a fait rien qu'à écrire::
Houla ! (...)

Ah bah notre cher cousin Raymond [1] a rajouté d'obscures étapes pour
rendre son algo complexe et obscur. Résultat, plus personne n'a voulu
perdre de temps à le recasser . Et lui, tout fier, s'est senti conforté
dans l'idée que c'était incassable.

Ah oui, ça me dit vaguement qeq' chose. . Ca s'est déja vu, pour sûr.

En fait sa proposition de base n'a pas tenue :
- chiffré plus long que le clair ;

Arf, c'est le cas ici..

- certains bits de sortie se retrouvaient calculé sans la clé (!) ;
- Christophe H a trouvé que plusieurs clés différentes donnaient le même
chiffré ;
- J'ai sorti l'ensemble des clés de 32 bits possibles à partir d'un
clair connu avec un soft de 30 lignes en une fraction de secondes ;

?!? la vache.. Il faut pourtant quelques secondes, pour compter jusqu'à 2^32.
A 1800MHz, tout du mmoins.

- testé avec 64 bits : explosion du nombre de clés équivalentes et temps
de cassage quasi inchangé. Comme le disait Christophe H, c'était
indépendant de la longueur de clé.

Alors, en repartant de cette base toutepourrie(c) il a rajouté des
étapes qui ne changeaient rien sinon à rendre le cassage de clé plus
complexe à écrire, et à rajouter des failles. Mais rien d'impossible. Il
commercialise son soft...

Et il en vit bien ?

aoké. je reprécise parce que ça n'a pas du apparaitre clairement:
je prends le point 1) uniquement, qui est le seul que j'ai capté:
. Affecter à chaque symbole un interval de taille imprédictible,
sauf à avoir la clé privée
. Se servir de ces intervalles en codage arithmétique, qui masquera
(peut-être ?!) toute propriété statistique

Tiote question : ce codage arithmétique étant parfaitement réversible,

Si & Ssi tu as les fréquences cumulées des symboles. Sinon, c'est de la
devinette, à moins d'attaque que je ne connais pas / à deviser.

A voir avec le code, donc.

il ne change rien ou me trompe-je ? On parle bien de la même chose [2] ?

Concrêtement, j'utilise le "Range Coder" de "ppmd", qui fut naguère au top
en matière de compression; (très) légèrement moins 'optimal' que l'arithmé-
tique, il est DP, alors qu'AC est (était ?) sous brevet (IBM ?).

Il a la particularité d'être bijectif, c-à-d que tout flux, y compris sa
propre sortie, constitue un flux d'entrée valide. Indirectement, ce peut
être une qualité en crypto.

J'te soutiens quand même.

Ah bah c'est ben jôntyl -- affute ton compilateur préféré, je finis de
me battre avec quelque drives non libres et je m'y mets ; je sens
confusément qu'il va falloir une phase préalable de substitution,
sinon le 'A' sera toujours le 1er. Quand on commence à rajouter
des complications..

AMHA pas la peine de rajouter de complications ici. Une substitution
simple va rallonger le travail de casse (et donc nos essais si qq'un s'y
colle) sans rajouter de véritable sécurité. Autant aller au plus simple.

Tûtàfé. Je pensais mettre ça en option, débrayable. Ca complique l'attaque,
à peu de frais, mais c'est tout.

A moins que tu ne parles de S-boxes...

Pas franchement, il s'agit que le 'A' ne tombe pas toujours en 1er, mais
seulement 1/27 fois.. Tu vois le genre.

Et le compilateur est toujours affuté. Juste l'utilisateur qui vieillit
mais là l'on n'y peut rien. Dans un grand excès de faiblesse je veux

Mon dieu, vous êtes vieux et faible, mais si vous dégainez le compilo,
rien n'est perdu !

bien jeter à oeil à ce que tu sortira de l'idée du superlutin, et voir

Je re-précise: inspirée de ce que j'ai compris du point 1:)

où sont les faiblesses. J'espère vivement qu'on pourra rapidement sortir
la phrase mythique.

Qui est ? Alleluiha ? Thalassa ? Osannah ? "Vous êtes un crétin" ? All/None
of the above ?

--
christophe.

Cryptographie par encapsculage hasardeux

10 réponses

Veuillez sélectionner un problème