1 - Répartir le plus aléatoirement possible les 256 caractères ASCII dans un
intervalle compris entre 10000 et 99999, ce qui fait une place de 351
possibilités environ de coder chaque caractère avec 5 chiffres différents.
Peu importe si l'un des caractères à un peu moins ou un peu plus de
possibilités de chiffrage.
Exemple la lettre B codée dans l'intervalle 17371 à 17722 peut s'écrire en
prenant toutes les valeurs comprises dans l'intervalle. Le chiffre 17569
compris dans cet intervalle correspondra donc à B.
Cette table de correspondance entre intervalles et caractères est la
première partie de la clé. En fait quant on chiffre B , le logiciel connait
l'intervalle et choisi une valeur au hasard comprise dans cet intervalle.
2 - Générer le plus aléatoirement possible un nombre de 16 chiffres
Exemple : 4589324876211002
3 - Définir une seconde partie de clé montrant l'ordre et la place des
numéros à cinq chiffres qui seront incorporés dans le numéro aléatoire
exemple : 0005002004000310
Le chiffre 1 correspond au premier chiffre du chiffrage précédent : 1
Le chiffre 5 correspond au dernier chiffre du chiffrage précédent : 9
Pour la lettre B codée précédemment 17569, cela donnerait 0009007006000510
4 - Remplacer maintenant les zéro par les chiffres du numéro aléatoire
4589324876211002 devient donc 4589327876211512 ou l'on retrouve le 9, le 7 ,
le 6 , le 5 et le 1 en position comme dans la clé.
5- Définir une clé aléatoire a 16 chiffres sans utiliser de zéro qui sera
la troisième et dernière partie de la clé. Exemple 3359221798458952
6 - Faire un XOR entre le numéro obtenu en 4 et la clé obtenue en 5 puis
diviser le nombre obtenu par le premier chiffre de la clé 5.
Dans ce cas, le premier chiffrage de caractère obtenu serait divisé par 3,
le deuxième par 3 aussi et le troisième par 5
Quant on arrive au bout on repars au début de la clé.
7 - Procéder ainsi pour chaque caractère à chiffrer.
Le déchiffrage s'effectue de manière inverse.. on re-multiplie le premier
chiffre par 3 pour obtenir le XOR puis un XOR avec la fin de clé redonne le
chiffre ou la deuxième partie de clé permet de remettre les bons numéro dans
l'ordre et de trouver l'intervalle donc le caractère chiffré.
Un tel code constitué de 3 clés indépendantes et aléatoires semble difficile
à attaquer.
Votre avis est le bienvenu et si vous voulez le programmer , pas de
problème.
Le 17/08/2010 02:48, Pierre Vandevenne a fait rien qu'à écrire::
PL est absolument tout, plombier, cryptographe, psychologue, programmeur, égyptologue, etc... entre autres.
Il est effectivement gril^Z^Z^Z^Zcélèbre sur usenet.
Mais oui, ca y est, ça me revient maintenant.. Pardonne la faible fiabilité de ma pauvre mémoire.
Ceci dit: c'est rédigé de manière intelligible, ex, le 1), -pou r moi- et à vue de nez, je dirais qu'avec des intervalles aléatoires, ça donn e un nbre exponentiel de possibilités. Y'a de l'idée !..
J'ai du mal à voir une différence statistique entre trouver une let tre et trouver un intervalle.
xtof pernod a écrit:
Le 17/08/2010 02:48, Pierre Vandevenne a fait rien qu'à écrire::
PL est absolument tout, plombier, cryptographe, psychologue,
programmeur, égyptologue, etc... entre autres.
Il est effectivement gril^Z^Z^Z^Zcélèbre sur usenet.
Mais oui, ca y est, ça me revient maintenant.. Pardonne la faible
fiabilité de ma pauvre mémoire.
Ceci dit: c'est rédigé de manière intelligible, ex, le 1), -pou r moi- et à
vue de nez, je dirais qu'avec des intervalles aléatoires, ça donn e un nbre
exponentiel de possibilités. Y'a de l'idée !..
J'ai du mal à voir une différence statistique entre trouver une let tre et
trouver un intervalle.
Le 17/08/2010 02:48, Pierre Vandevenne a fait rien qu'à écrire::
PL est absolument tout, plombier, cryptographe, psychologue, programmeur, égyptologue, etc... entre autres.
Il est effectivement gril^Z^Z^Z^Zcélèbre sur usenet.
Mais oui, ca y est, ça me revient maintenant.. Pardonne la faible fiabilité de ma pauvre mémoire.
Ceci dit: c'est rédigé de manière intelligible, ex, le 1), -pou r moi- et à vue de nez, je dirais qu'avec des intervalles aléatoires, ça donn e un nbre exponentiel de possibilités. Y'a de l'idée !..
J'ai du mal à voir une différence statistique entre trouver une let tre et trouver un intervalle.
Philippe Lheureux
J'ai du mal à voir une différence statistique entre trouver une lettre et trouver un intervalle.
C'est tout simplement qu'un intervalle permet de chiffrer différemment une même lettre , peut être variable et segmenté.
J'ai du mal à voir une différence statistique entre trouver une lettre et
trouver un intervalle.
C'est tout simplement qu'un intervalle permet de chiffrer différemment une
même lettre , peut être variable et segmenté.
J'ai du mal à voir une différence statistique entre trouver une lettre et trouver un intervalle.
C'est tout simplement qu'un intervalle permet de chiffrer différemment une même lettre , peut être variable et segmenté.
Stephane CARPENTIER
Philippe Lheureux a écrit:
PL est absolument tout, plombier, cryptographe, psychologue, programmeur, égyptologue, etc... entre autres.
PL est simplement curieux de tout .... défaut pour certains
Mais non, ce n'est un défaut pour personne. Ce qui m'amuse (et d'autr es aussi), c'est qu'il te suffit de voir une émission sur Arte pour deve nir expert dans un domaine.
Bien entendu , dans mon système CEH , il est possible de génére r des intervalles de 700 possibilités et d'autres n'en ayant que 10 , cel a n'est pas un problème. J'ai posté mon idée pour savoir si a première vue , c'est cassa ble ou pas et quelle genre d'attaque pourrait casser ce chiffre.
Si je te dis que ton algo n'a aucun intérêt, tu vas me dire que je suis jaloux. Je vais donc t'expliquer ce que je lui repproche. Mais comme tu es incapable de prendre en compte ce qui t'est expliqué, je ne reviendra i pas dessus.
D'abord, le principe n'est pas original.
Un peu de lecture : http://www.apprendre-en-ligne.net/crypto/homophone/renversement.html
Contrairement à ton algo, les intervalles ont été calculés de f açon intelligentes. Le but est que le E soit codé de plus de façon que l e V pour ne pas être repérable.
Contrairement à ton algo, les différentes codes pris par une lettre ne se suivent pas. Si tu vois autant d'occurences de 142, 143, 145 et 146, ç a montrera qu'il font partie du même intervalle.
Contrairement à ton algo, le texte chiffré n'a pas une taille je ne sais combien de fois plus grosse que le texte clair.
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
Philippe Lheureux a écrit:
PL est absolument tout, plombier, cryptographe, psychologue,
programmeur, égyptologue, etc... entre autres.
PL est simplement curieux de tout .... défaut pour certains
Mais non, ce n'est un défaut pour personne. Ce qui m'amuse (et d'autr es
aussi), c'est qu'il te suffit de voir une émission sur Arte pour deve nir
expert dans un domaine.
Bien entendu , dans mon système CEH , il est possible de génére r des
intervalles de 700 possibilités et d'autres n'en ayant que 10 , cel a n'est
pas un problème.
J'ai posté mon idée pour savoir si a première vue , c'est cassa ble ou pas
et quelle genre d'attaque pourrait casser ce chiffre.
Si je te dis que ton algo n'a aucun intérêt, tu vas me dire que je suis
jaloux. Je vais donc t'expliquer ce que je lui repproche. Mais comme tu es
incapable de prendre en compte ce qui t'est expliqué, je ne reviendra i pas
dessus.
D'abord, le principe n'est pas original.
Un peu de lecture :
http://www.apprendre-en-ligne.net/crypto/homophone/renversement.html
Contrairement à ton algo, les intervalles ont été calculés de f açon
intelligentes. Le but est que le E soit codé de plus de façon que l e V pour
ne pas être repérable.
Contrairement à ton algo, les différentes codes pris par une lettre ne se
suivent pas. Si tu vois autant d'occurences de 142, 143, 145 et 146, ç a
montrera qu'il font partie du même intervalle.
Contrairement à ton algo, le texte chiffré n'a pas une taille je ne sais
combien de fois plus grosse que le texte clair.
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec
lesquels tu ne sera pas d'accord
PL est absolument tout, plombier, cryptographe, psychologue, programmeur, égyptologue, etc... entre autres.
PL est simplement curieux de tout .... défaut pour certains
Mais non, ce n'est un défaut pour personne. Ce qui m'amuse (et d'autr es aussi), c'est qu'il te suffit de voir une émission sur Arte pour deve nir expert dans un domaine.
Bien entendu , dans mon système CEH , il est possible de génére r des intervalles de 700 possibilités et d'autres n'en ayant que 10 , cel a n'est pas un problème. J'ai posté mon idée pour savoir si a première vue , c'est cassa ble ou pas et quelle genre d'attaque pourrait casser ce chiffre.
Si je te dis que ton algo n'a aucun intérêt, tu vas me dire que je suis jaloux. Je vais donc t'expliquer ce que je lui repproche. Mais comme tu es incapable de prendre en compte ce qui t'est expliqué, je ne reviendra i pas dessus.
D'abord, le principe n'est pas original.
Un peu de lecture : http://www.apprendre-en-ligne.net/crypto/homophone/renversement.html
Contrairement à ton algo, les intervalles ont été calculés de f açon intelligentes. Le but est que le E soit codé de plus de façon que l e V pour ne pas être repérable.
Contrairement à ton algo, les différentes codes pris par une lettre ne se suivent pas. Si tu vois autant d'occurences de 142, 143, 145 et 146, ç a montrera qu'il font partie du même intervalle.
Contrairement à ton algo, le texte chiffré n'a pas une taille je ne sais combien de fois plus grosse que le texte clair.
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
Philippe Lheureux
Mais non, ce n'est un défaut pour personne. Ce qui m'amuse (et d'autres aussi), c'est qu'il te suffit de voir une émission sur Arte pour devenir expert dans un domaine.
Expert faut pas pousser ... assez imaginatif pour produire quelque chose et me servir de ce que j'ai vu .. OUI
Bien entendu , dans mon système CEH , il est possible de générer des intervalles de 700 possibilités et d'autres n'en ayant que 10 , cela n'est pas un problème. J'ai posté mon idée pour savoir si a première vue , c'est cassable ou pas et quelle genre d'attaque pourrait casser ce chiffre.
Si je te dis que ton algo n'a aucun intérêt, tu vas me dire que je suis jaloux.
Non je vais te dire que j'ai l'habitude :-)
Je vais donc t'expliquer ce que je lui repproche. Mais comme tu es
incapable de prendre en compte ce qui t'est expliqué, je ne reviendrai pas dessus.
D'abord, le principe n'est pas original.
Un peu de lecture : http://www.apprendre-en-ligne.net/crypto/homophone/renversement.html
Merci pour le tableau des % qui peut servir pour répartir les intervalles intelligemment
Contrairement à ton algo, les intervalles ont été calculés de façon intelligentes. Le but est que le E soit codé de plus de façon que le V pour ne pas être repérable.
de toute façon, vu ce qui se passe après dans l'algorithme , c'etait pas repérable :-)
Contrairement à ton algo, les différentes codes pris par une lettre ne se suivent pas. Si tu vois autant d'occurences de 142, 143, 145 et 146, ça montrera qu'il font partie du même intervalle.
justement , tu ne le vois pas dans mon algo parce que les séquences sont brouillées et mélangées avec des chiffres aléatoires.
Contrairement à ton algo, le texte chiffré n'a pas une taille je ne sais combien de fois plus grosse que le texte clair.
a vrai dire , si le fait de faire gonfler le résultat le rend vraiment incassable , l'enjeu en vaut la chandelle.
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
je suis d'accord avec tout mais tu n'as pas tout lu ...
Ps ... je me souviens de toi et de pierre sans avoir besoin de manger du phosphore :-)
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 5374 (20100817) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
Mais non, ce n'est un défaut pour personne. Ce qui m'amuse (et d'autres
aussi), c'est qu'il te suffit de voir une émission sur Arte pour devenir
expert dans un domaine.
Expert faut pas pousser ... assez imaginatif pour produire quelque chose et
me servir de ce que j'ai vu .. OUI
Bien entendu , dans mon système CEH , il est possible de générer des
intervalles de 700 possibilités et d'autres n'en ayant que 10 , cela
n'est
pas un problème.
J'ai posté mon idée pour savoir si a première vue , c'est cassable ou pas
et quelle genre d'attaque pourrait casser ce chiffre.
Si je te dis que ton algo n'a aucun intérêt, tu vas me dire que je suis
jaloux.
Non je vais te dire que j'ai l'habitude :-)
Je vais donc t'expliquer ce que je lui repproche. Mais comme tu es
incapable de prendre en compte ce qui t'est expliqué, je ne reviendrai pas
dessus.
D'abord, le principe n'est pas original.
Un peu de lecture :
http://www.apprendre-en-ligne.net/crypto/homophone/renversement.html
Merci pour le tableau des % qui peut servir pour répartir les intervalles
intelligemment
Contrairement à ton algo, les intervalles ont été calculés de façon
intelligentes. Le but est que le E soit codé de plus de façon que le V
pour
ne pas être repérable.
de toute façon, vu ce qui se passe après dans l'algorithme , c'etait pas
repérable :-)
Contrairement à ton algo, les différentes codes pris par une lettre ne se
suivent pas. Si tu vois autant d'occurences de 142, 143, 145 et 146, ça
montrera qu'il font partie du même intervalle.
justement , tu ne le vois pas dans mon algo parce que les séquences sont
brouillées et mélangées avec des chiffres aléatoires.
Contrairement à ton algo, le texte chiffré n'a pas une taille je ne sais
combien de fois plus grosse que le texte clair.
a vrai dire , si le fait de faire gonfler le résultat le rend vraiment
incassable , l'enjeu en vaut la chandelle.
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec
lesquels tu ne sera pas d'accord
je suis d'accord avec tout mais tu n'as pas tout lu ...
Ps ... je me souviens de toi et de pierre sans avoir besoin de manger du
phosphore :-)
__________ Information provenant d'ESET NOD32 Antivirus, version de la
base des signatures de virus 5374 (20100817) __________
Le message a été vérifié par ESET NOD32 Antivirus.
Mais non, ce n'est un défaut pour personne. Ce qui m'amuse (et d'autres aussi), c'est qu'il te suffit de voir une émission sur Arte pour devenir expert dans un domaine.
Expert faut pas pousser ... assez imaginatif pour produire quelque chose et me servir de ce que j'ai vu .. OUI
Bien entendu , dans mon système CEH , il est possible de générer des intervalles de 700 possibilités et d'autres n'en ayant que 10 , cela n'est pas un problème. J'ai posté mon idée pour savoir si a première vue , c'est cassable ou pas et quelle genre d'attaque pourrait casser ce chiffre.
Si je te dis que ton algo n'a aucun intérêt, tu vas me dire que je suis jaloux.
Non je vais te dire que j'ai l'habitude :-)
Je vais donc t'expliquer ce que je lui repproche. Mais comme tu es
incapable de prendre en compte ce qui t'est expliqué, je ne reviendrai pas dessus.
D'abord, le principe n'est pas original.
Un peu de lecture : http://www.apprendre-en-ligne.net/crypto/homophone/renversement.html
Merci pour le tableau des % qui peut servir pour répartir les intervalles intelligemment
Contrairement à ton algo, les intervalles ont été calculés de façon intelligentes. Le but est que le E soit codé de plus de façon que le V pour ne pas être repérable.
de toute façon, vu ce qui se passe après dans l'algorithme , c'etait pas repérable :-)
Contrairement à ton algo, les différentes codes pris par une lettre ne se suivent pas. Si tu vois autant d'occurences de 142, 143, 145 et 146, ça montrera qu'il font partie du même intervalle.
justement , tu ne le vois pas dans mon algo parce que les séquences sont brouillées et mélangées avec des chiffres aléatoires.
Contrairement à ton algo, le texte chiffré n'a pas une taille je ne sais combien de fois plus grosse que le texte clair.
a vrai dire , si le fait de faire gonfler le résultat le rend vraiment incassable , l'enjeu en vaut la chandelle.
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
je suis d'accord avec tout mais tu n'as pas tout lu ...
Ps ... je me souviens de toi et de pierre sans avoir besoin de manger du phosphore :-)
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 5374 (20100817) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
Guy Ratajczak
Salut !
Le 17/08/2010 20:24, Stephane CARPENTIER a écrit :
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
Moi j'dis qu'c'est un peu facile de foutre les jetons à tout l'monde, en réveillant, finalement, le SEUL gars de fr.misc.cryptologie qui ne peut pas entendre ce qu'il nous demande de lui dire, et en laissant les pauvres bougres que nous sommes devoir débattre avec lui. Donc, de poster dans d'atroces souffrances...
Je sais pas s'il est d'accord ou pas avec ce point, mais j'avais que ça à expliquer.
Bon courage, -- Guy
Salut !
Le 17/08/2010 20:24, Stephane CARPENTIER a écrit :
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec
lesquels tu ne sera pas d'accord
Moi j'dis qu'c'est un peu facile de foutre les jetons à tout l'monde, en
réveillant, finalement, le SEUL gars de fr.misc.cryptologie qui ne peut
pas entendre ce qu'il nous demande de lui dire, et en laissant les
pauvres bougres que nous sommes devoir débattre avec lui.
Donc, de poster dans d'atroces souffrances...
Je sais pas s'il est d'accord ou pas avec ce point, mais j'avais que ça
à expliquer.
Le 17/08/2010 20:24, Stephane CARPENTIER a écrit :
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
Moi j'dis qu'c'est un peu facile de foutre les jetons à tout l'monde, en réveillant, finalement, le SEUL gars de fr.misc.cryptologie qui ne peut pas entendre ce qu'il nous demande de lui dire, et en laissant les pauvres bougres que nous sommes devoir débattre avec lui. Donc, de poster dans d'atroces souffrances...
Je sais pas s'il est d'accord ou pas avec ce point, mais j'avais que ça à expliquer.
Bon courage, -- Guy
xtof pernod
Le 17/08/2010 19:56, Stephane CARPENTIER a fait rien qu'à écrire::
xtof pernod a écrit:
Le 17/08/2010 02:48, Pierre Vandevenne a fait rien qu'à écrire::
PL est absolument tout, plombier, cryptographe, psychologue, programmeur, égyptologue, etc... entre autres.
Il est effectivement gril^Z^Z^Z^Zcélèbre sur usenet.
La hiérarchie fr., tout du moins. Y'a pire comme dégén^H^H^^HH^Hrêveur. Si tu fréquentes comp.compression, par ex., tu vois surement qui je veux dire.
(blah Y'a de l'idée..)
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. Le décodage ne peut s'effectuer si & ssi le décodeur a *exactement* la même table de fréquence.
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)
Ce qui ne serait pas le cas en codage de Huffmann: gzip peut se resynchroniser avec un flux dont des bits ont été perdus/corrompus.
Bon, c'est pas forcément clair, ça tient bien autant de la compression que de la crypto, et le plus gros défault, jusqu'ici, est que le flux d'entrée est _étendu_ pour donner le flux chiffré, et cette augmentation est fonction de la "sécurité" désirée. Pas terrible.
D'un autre côté, c'est pas tous les jours qu'on tombe sur un algo dont la sécurité est démontrable. D'où mon interêt pour la phase 1) -- je pense pas que l'OP s'embêtera à formaliser le reste, malgré la demande.
Le 17/08/2010 19:56, Stephane CARPENTIER a fait rien qu'à écrire::
xtof pernod a écrit:
Le 17/08/2010 02:48, Pierre Vandevenne a fait rien qu'à écrire::
PL est absolument tout, plombier, cryptographe, psychologue,
programmeur, égyptologue, etc... entre autres.
Il est effectivement gril^Z^Z^Z^Zcélèbre sur usenet.
La hiérarchie fr., tout du moins. Y'a pire comme dégén^H^H^^HH^Hrêveur.
Si tu fréquentes comp.compression, par ex., tu vois surement qui je veux dire.
(blah Y'a de l'idée..)
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. Le décodage ne peut s'effectuer si & ssi le décodeur a
*exactement* la même table de fréquence.
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)
Ce qui ne serait pas le cas en codage de Huffmann: gzip peut se resynchroniser
avec un flux dont des bits ont été perdus/corrompus.
Bon, c'est pas forcément clair, ça tient bien autant de la compression que de
la crypto, et le plus gros défault, jusqu'ici, est que le flux d'entrée est
_étendu_ pour donner le flux chiffré, et cette augmentation est fonction de la
"sécurité" désirée. Pas terrible.
D'un autre côté, c'est pas tous les jours qu'on tombe sur un algo dont la
sécurité est démontrable. D'où mon interêt pour la phase 1) -- je pense pas
que l'OP s'embêtera à formaliser le reste, malgré la demande.
Le 17/08/2010 19:56, Stephane CARPENTIER a fait rien qu'à écrire::
xtof pernod a écrit:
Le 17/08/2010 02:48, Pierre Vandevenne a fait rien qu'à écrire::
PL est absolument tout, plombier, cryptographe, psychologue, programmeur, égyptologue, etc... entre autres.
Il est effectivement gril^Z^Z^Z^Zcélèbre sur usenet.
La hiérarchie fr., tout du moins. Y'a pire comme dégén^H^H^^HH^Hrêveur. Si tu fréquentes comp.compression, par ex., tu vois surement qui je veux dire.
(blah Y'a de l'idée..)
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. Le décodage ne peut s'effectuer si & ssi le décodeur a *exactement* la même table de fréquence.
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)
Ce qui ne serait pas le cas en codage de Huffmann: gzip peut se resynchroniser avec un flux dont des bits ont été perdus/corrompus.
Bon, c'est pas forcément clair, ça tient bien autant de la compression que de la crypto, et le plus gros défault, jusqu'ici, est que le flux d'entrée est _étendu_ pour donner le flux chiffré, et cette augmentation est fonction de la "sécurité" désirée. Pas terrible.
D'un autre côté, c'est pas tous les jours qu'on tombe sur un algo dont la sécurité est démontrable. D'où mon interêt pour la phase 1) -- je pense pas que l'OP s'embêtera à formaliser le reste, malgré la demande.
Le 17/08/2010 20:56, Guy Ratajczak a fait rien qu'à écrire::
Salut !
Le 17/08/2010 20:24, Stephane CARPENTIER a écrit :
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
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..
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à..
pas entendre ce qu'il nous demande de lui dire, et en laissant les pauvres bougres que nous sommes devoir débattre avec lui. Donc, de poster dans d'atroces souffrances...
Argh ! A ce point ? Mon dieu, mais c'est affreux... ne reste pas comme ça =)
Je sais pas s'il est d'accord ou pas avec ce point, mais j'avais que ça à expliquer.
Bon courage,
(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..
-- christophe.
Le 17/08/2010 20:56, Guy Ratajczak a fait rien qu'à écrire::
Salut !
Le 17/08/2010 20:24, Stephane CARPENTIER a écrit :
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec
lesquels tu ne sera pas d'accord
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..
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à..
pas entendre ce qu'il nous demande de lui dire, et en laissant les
pauvres bougres que nous sommes devoir débattre avec lui.
Donc, de poster dans d'atroces souffrances...
Argh ! A ce point ? Mon dieu, mais c'est affreux... ne reste pas comme ça =)
Je sais pas s'il est d'accord ou pas avec ce point, mais j'avais que ça
à expliquer.
Bon courage,
(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..
Le 17/08/2010 20:56, Guy Ratajczak a fait rien qu'à écrire::
Salut !
Le 17/08/2010 20:24, Stephane CARPENTIER a écrit :
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
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..
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à..
pas entendre ce qu'il nous demande de lui dire, et en laissant les pauvres bougres que nous sommes devoir débattre avec lui. Donc, de poster dans d'atroces souffrances...
Argh ! A ce point ? Mon dieu, mais c'est affreux... ne reste pas comme ça =)
Je sais pas s'il est d'accord ou pas avec ce point, mais j'avais que ça à expliquer.
Bon courage,
(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..
-- christophe.
Stephane CARPENTIER
xtof pernod a écrit:
Le 17/08/2010 19:56, Stephane CARPENTIER a fait rien qu'à écrire ::
xtof pernod a écrit: 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 (pratiqu ement) 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.
Pour mémoire, il a écrit ça :
« 1 - Répartir le plus aléatoirement possible les 256 caractères AS CII dans un intervalle compris entre 10000 et 99999, ce qui fait une place de 351 possibilités environ de coder chaque caractère avec 5 chiffres diff érents. Peu importe si l'un des caractères à un peu moins ou un peu plus de possibilités de chiffrage. »
Ses intervalles font donc tous plus ou moins la même taille.
Tu connais à peu près les limites de chaque intervalle, en faisant une divcision rapide, ensuite, tu afines. Si les féquences de veux valeur s collées sont très différentes, ça veut dire qu'il y a un change ment 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 des sin ou par un intervalle, le principe est toujours le même. C'est du 1 po ur 1.
Ca laisse un nombre de possibilités exponentiel, et potentiellement intractable. (A moins d'autre attaque sur la clef générant la tab le, bien sûr)
Pas d'après sa façon de présenter les choses.
Ce qui ne serait pas le cas en codage de Huffmann: gzip peut se resynchroniser avec un flux dont des bits ont été perdus/corrompu s.
Lui, il ne compresse pas, il décompresse. Et plutôt dix fois qu'une .
En général, quand tu peux compresser un message chiffré, c'est qu 'il y a de l'information redondante et c'est un signe de faiblesse. Je serais sincèrement épaté qu'un message chiffré avec sa technique soit incompressible (sans perte j'entends).
Et si tu ne peux pas le compresser, ce n'est pas génial pour la trans mission et pour l'archivage, ça tu l'as remarqué.
D'un autre côté, c'est pas tous les jours qu'on tombe sur un alg o dont la sécurité est démontrable.
Maintenant, si. Pour les trucs sérieux bien sûr.
D'où mon interêt pour la phase 1) -- je pense pas que l'OP s'embêtera à formaliser le reste, malgré la demand e.
Je ne commenterai pas cette phrase.
xtof pernod a écrit:
Le 17/08/2010 19:56, Stephane CARPENTIER a fait rien qu'à écrire ::
xtof pernod a écrit:
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 (pratiqu ement)
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.
Pour mémoire, il a écrit ça :
«
1 - Répartir le plus aléatoirement possible les 256 caractères AS CII dans un
intervalle compris entre 10000 et 99999, ce qui fait une place de 351
possibilités environ de coder chaque caractère avec 5 chiffres diff érents.
Peu importe si l'un des caractères à un peu moins ou un peu plus de
possibilités de chiffrage.
»
Ses intervalles font donc tous plus ou moins la même taille.
Tu connais à peu près les limites de chaque intervalle, en faisant une
divcision rapide, ensuite, tu afines. Si les féquences de veux valeur s
collées sont très différentes, ça veut dire qu'il y a un change ment
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 des sin
ou par un intervalle, le principe est toujours le même. C'est du 1 po ur 1.
Ca laisse un nombre de possibilités exponentiel, et potentiellement
intractable. (A moins d'autre attaque sur la clef générant la tab le, bien
sûr)
Pas d'après sa façon de présenter les choses.
Ce qui ne serait pas le cas en codage de Huffmann: gzip peut se
resynchroniser avec un flux dont des bits ont été perdus/corrompu s.
Lui, il ne compresse pas, il décompresse. Et plutôt dix fois qu'une .
En général, quand tu peux compresser un message chiffré, c'est qu 'il y a de
l'information redondante et c'est un signe de faiblesse. Je serais
sincèrement épaté qu'un message chiffré avec sa technique soit
incompressible (sans perte j'entends).
Et si tu ne peux pas le compresser, ce n'est pas génial pour la trans mission
et pour l'archivage, ça tu l'as remarqué.
D'un autre côté, c'est pas tous les jours qu'on tombe sur un alg o dont la
sécurité est démontrable.
Maintenant, si. Pour les trucs sérieux bien sûr.
D'où mon interêt pour la phase 1) -- je pense
pas que l'OP s'embêtera à formaliser le reste, malgré la demand e.
Le 17/08/2010 19:56, Stephane CARPENTIER a fait rien qu'à écrire ::
xtof pernod a écrit: 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 (pratiqu ement) 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.
Pour mémoire, il a écrit ça :
« 1 - Répartir le plus aléatoirement possible les 256 caractères AS CII dans un intervalle compris entre 10000 et 99999, ce qui fait une place de 351 possibilités environ de coder chaque caractère avec 5 chiffres diff érents. Peu importe si l'un des caractères à un peu moins ou un peu plus de possibilités de chiffrage. »
Ses intervalles font donc tous plus ou moins la même taille.
Tu connais à peu près les limites de chaque intervalle, en faisant une divcision rapide, ensuite, tu afines. Si les féquences de veux valeur s collées sont très différentes, ça veut dire qu'il y a un change ment 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 des sin ou par un intervalle, le principe est toujours le même. C'est du 1 po ur 1.
Ca laisse un nombre de possibilités exponentiel, et potentiellement intractable. (A moins d'autre attaque sur la clef générant la tab le, bien sûr)
Pas d'après sa façon de présenter les choses.
Ce qui ne serait pas le cas en codage de Huffmann: gzip peut se resynchroniser avec un flux dont des bits ont été perdus/corrompu s.
Lui, il ne compresse pas, il décompresse. Et plutôt dix fois qu'une .
En général, quand tu peux compresser un message chiffré, c'est qu 'il y a de l'information redondante et c'est un signe de faiblesse. Je serais sincèrement épaté qu'un message chiffré avec sa technique soit incompressible (sans perte j'entends).
Et si tu ne peux pas le compresser, ce n'est pas génial pour la trans mission et pour l'archivage, ça tu l'as remarqué.
D'un autre côté, c'est pas tous les jours qu'on tombe sur un alg o dont la sécurité est démontrable.
Maintenant, si. Pour les trucs sérieux bien sûr.
D'où mon interêt pour la phase 1) -- je pense pas que l'OP s'embêtera à formaliser le reste, malgré la demand e.
Je ne commenterai pas cette phrase.
Philippe Lheureux
Simple: vu sous l'angle d'un codage arithmétique, il n'y a (pratiquement) aucune statistique qui remonte, dans le flux chiffré.
Surtout qu'en plus les chiffres de l'intervalle sont mélangés entre eux et avec d'autres chiffres aléatoires grâce a une clé
Je suppose, trivialement, que la taille d'un interval représente la fréquence d'un symbole. Le décodage ne peut s'effectuer si & ssi le décodeur a *exactement* la même table de fréquence.
c'est fait pour ..
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)
Elle est quand même assez longue.
Ce qui ne serait pas le cas en codage de Huffmann: gzip peut se resynchroniser avec un flux dont des bits ont été perdus/corrompus.
Bon, c'est pas forcément clair, ça tient bien autant de la compression que de la crypto, et le plus gros défault, jusqu'ici, est que le flux d'entrée est _étendu_ pour donner le flux chiffré, et cette augmentation est fonction de la "sécurité" désirée. Pas terrible.
D'un autre côté, c'est pas tous les jours qu'on tombe sur un algo dont la sécurité est démontrable. D'où mon interêt pour la phase 1) -- je pense pas que l'OP s'embêtera à formaliser le reste, malgré la demande.
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 5374 (20100817) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
Simple: vu sous l'angle d'un codage arithmétique, il n'y a (pratiquement)
aucune statistique qui remonte, dans le flux chiffré.
Surtout qu'en plus les chiffres de l'intervalle sont mélangés entre eux et
avec d'autres chiffres aléatoires grâce a une clé
Je suppose, trivialement, que la taille d'un interval représente la
fréquence
d'un symbole. Le décodage ne peut s'effectuer si & ssi le décodeur a
*exactement* la même table de fréquence.
c'est fait pour ..
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)
Elle est quand même assez longue.
Ce qui ne serait pas le cas en codage de Huffmann: gzip peut se
resynchroniser
avec un flux dont des bits ont été perdus/corrompus.
Bon, c'est pas forcément clair, ça tient bien autant de la compression que
de la crypto, et le plus gros défault, jusqu'ici, est que le flux d'entrée
est
_étendu_ pour donner le flux chiffré, et cette augmentation est fonction
de la
"sécurité" désirée. Pas terrible.
D'un autre côté, c'est pas tous les jours qu'on tombe sur un algo dont la
sécurité est démontrable. D'où mon interêt pour la phase 1) -- je pense
pas
que l'OP s'embêtera à formaliser le reste, malgré la demande.
Simple: vu sous l'angle d'un codage arithmétique, il n'y a (pratiquement) aucune statistique qui remonte, dans le flux chiffré.
Surtout qu'en plus les chiffres de l'intervalle sont mélangés entre eux et avec d'autres chiffres aléatoires grâce a une clé
Je suppose, trivialement, que la taille d'un interval représente la fréquence d'un symbole. Le décodage ne peut s'effectuer si & ssi le décodeur a *exactement* la même table de fréquence.
c'est fait pour ..
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)
Elle est quand même assez longue.
Ce qui ne serait pas le cas en codage de Huffmann: gzip peut se resynchroniser avec un flux dont des bits ont été perdus/corrompus.
Bon, c'est pas forcément clair, ça tient bien autant de la compression que de la crypto, et le plus gros défault, jusqu'ici, est que le flux d'entrée est _étendu_ pour donner le flux chiffré, et cette augmentation est fonction de la "sécurité" désirée. Pas terrible.
D'un autre côté, c'est pas tous les jours qu'on tombe sur un algo dont la sécurité est démontrable. D'où mon interêt pour la phase 1) -- je pense pas que l'OP s'embêtera à formaliser le reste, malgré la demande.
__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 5374 (20100817) __________
Le message a été vérifié par ESET NOD32 Antivirus.
http://www.eset.com
Stephane CARPENTIER
Guy Ratajczak a écrit:
Le 17/08/2010 20:24, Stephane CARPENTIER a écrit :
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
Moi j'dis qu'c'est un peu facile
Oui, j'ai donné, j'en ai vu d'autres donner, je passe la main. C'est chacun son tour. Je suis tombé dans la facilité.
de foutre les jetons à tout l'monde,
Meuh non.
en réveillant, finalement,
He ho, je ne l'ai pas réveillé. Il se réveille tout seul de temps en temps. Avant mon premier message, il s'était déjà répondu 2 fois tout seul.
le SEUL gars de fr.misc.cryptologie qui ne peut pas entendre ce qu'il nous demande de lui dire, et en laissant les pauvres bougres que nous sommes devoir débattre avec lui.
Il y en a que ça peut amuser. Moi, ça m'a lassé.
Donc, de poster dans d'atroces souffrances...
Meuh non, il n'est pas méchant Zhappy.
Guy Ratajczak a écrit:
Le 17/08/2010 20:24, Stephane CARPENTIER a écrit :
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec
lesquels tu ne sera pas d'accord
Moi j'dis qu'c'est un peu facile
Oui, j'ai donné, j'en ai vu d'autres donner, je passe la main. C'est chacun
son tour. Je suis tombé dans la facilité.
de foutre les jetons à tout l'monde,
Meuh non.
en
réveillant, finalement,
He ho, je ne l'ai pas réveillé. Il se réveille tout seul de temps en temps.
Avant mon premier message, il s'était déjà répondu 2 fois tout seul.
le SEUL gars de fr.misc.cryptologie qui ne peut
pas entendre ce qu'il nous demande de lui dire, et en laissant les
pauvres bougres que nous sommes devoir débattre avec lui.
Le 17/08/2010 20:24, Stephane CARPENTIER a écrit :
<EOT> je laisse aux autres le plaisir de t'expliquer les points avec lesquels tu ne sera pas d'accord
Moi j'dis qu'c'est un peu facile
Oui, j'ai donné, j'en ai vu d'autres donner, je passe la main. C'est chacun son tour. Je suis tombé dans la facilité.
de foutre les jetons à tout l'monde,
Meuh non.
en réveillant, finalement,
He ho, je ne l'ai pas réveillé. Il se réveille tout seul de temps en temps. Avant mon premier message, il s'était déjà répondu 2 fois tout seul.
le SEUL gars de fr.misc.cryptologie qui ne peut pas entendre ce qu'il nous demande de lui dire, et en laissant les pauvres bougres que nous sommes devoir débattre avec lui.
