voila je me pose une question, peut-=EAtre l'id=E9e est-elle idiote.
Comment peux faire un cryptanaliste pour tenter de d=E9coder le chiffre
=E0 clef priv=E9 suivant:
Soit le mot de passe de longueur finie, qui par une certaine bijection
sert a g=E9n=E9rer la clef compos=E9e de:
P(0) entre 0 et 1
MU entre 3.57 et 4
P(0) et MU sont cod=E9s sur "pas mal" de bits, assez pour rendre
impossible une attaque bruteforce sur l'ensemble des valeurs
possibles.
Pour chaque M(n) du message a crypter on calcul le mot crypt=E9 C(n) =3D
M(n) XOR ( mu*P(n-1)*(1-P(n-1)) )
(et reciproquement pour decrypter)
Sachant que la suite logistique est totalement chaotique pour MU entre
3=2E57 et 4, il est en th=E9orie impossible de pr=E9dire son comportement si
on ne connais pas la valeur initiale et MU.
HASH = MD5, SHA1 ou bien n'importe quelle fonction de hash plus performante. La connaissance de valeurs M(n) permet de remonter a HASH(P(n)) mais comme les fonctions de hash ne sont pas bijectives... on ne peut pas forcément remonter a la bonne valeur de P(n) facilement, et donc remonter a MU et P(0) ??
Haha, cette fois j'attend votre solution avec impatience
Le système n'est pas très bien défini car - on ne sait pas la précision utilisée pour P et mu; dans ce qui suit je vais raisonner en supposant que c'est assimilable à du binaire sur 56 bits avec un facteur d'échelle qui va bien, ce qui est proche de ce que donnerais du double-precision IEEE 754. - on ne sait pas la largeur de la sortie du hash; disons 160 bits (SHA-1) - on ne sait pas comment P(n) est transformé en suite binaire pour calculer HASH (mais c'est sans grande importance pour évaluer la sécurité, c'est juste une variante du hash)
Le système est vulnérable à la force brute: il est concevable d'énumérer une fraction des 2^^56 valeurs possibles de P, et de rechercher si la valeur correspondante du hash de 160 bits est utilisée dans une fraction du message pour laquelle on dispose de clair connu (ou simplement possible: la taille de 160 bits rend les faux positifs très improbables et on peut donc se permettre d'avoir des doutes sur le clair). Si on connais disons 20 Mo de clair, soit 2^20 hash, on trouve un P tout les 2^46 essais coutant un hash et une consultation d'une table tenant en RAM d'un PC. Dès que l'on a 2 valeurs consécutives de P séparées d'un petit nombre de pas (genre 20), on retrouve mu, et le cryptosystème s'effondre (le hash rend même plus facile de remonter en arrière à partir de la redondance du clair). On peut accélérer notablement la recherche en concentrant ses efforts dans l'intervalle de P atteind le plus souvent, compte tenu de l'intervalle de mu.
Autre attaque: les valeurs de P ont tendance à entrer dans un cycle relativement court, souvent inférieur à 2^25 valeurs de P (à vue de nez, pas le temps d'essayer) soit 640 Mo de chiffré, ce qui en terme de cryptographie moderne est très peu (c'est quelques minutes de vidéo HD). Cela permet toutes sortes d'attaques SANS disposer de clair connu, à partir de l'endroit où l'on est rentré dans le cycle court, sans même avoir à retrouver explicitement P et mu.
Les deux attaques se combinent plutôt bien, la seconde permettant de retrouver du clair connu à la fin du message, puis la première retrouvant P et mu pour casser tout le reste.
Ah, et le système n'a aucun intérêt pratique: il est moins efficace qu'un système plus simple et plus sur genre C(n) = M(n) XOR HASH(clé || n) qui de plus a l'avantage de permettre l'accès direct au clair sans déchiffrer tout ce qui précède.
François Grieu
Le 20 avr, 15:38, jeffvi...@gmail.com ammende son système
HASH = MD5, SHA1 ou bien n'importe quelle fonction de hash plus
performante.
La connaissance de valeurs M(n) permet de remonter a HASH(P(n)) mais
comme les fonctions
de hash ne sont pas bijectives... on ne peut pas forcément remonter a
la bonne valeur de P(n) facilement, et donc remonter a MU et P(0) ??
Haha, cette fois j'attend votre solution avec impatience
Le système n'est pas très bien défini car
- on ne sait pas la précision utilisée pour P et mu; dans ce qui suit
je vais raisonner en supposant que c'est assimilable à du binaire sur
56 bits avec un facteur d'échelle qui va bien, ce qui est proche de ce
que donnerais du double-precision IEEE 754.
- on ne sait pas la largeur de la sortie du hash; disons 160 bits
(SHA-1)
- on ne sait pas comment P(n) est transformé en suite binaire pour
calculer HASH (mais c'est sans grande importance pour évaluer la
sécurité, c'est juste une variante du hash)
Le système est vulnérable à la force brute: il est concevable
d'énumérer une fraction des 2^^56 valeurs possibles de P, et de
rechercher si la valeur correspondante du hash de 160 bits est
utilisée dans une fraction du message pour laquelle on dispose de
clair connu (ou simplement possible: la taille de 160 bits rend les
faux positifs très improbables et on peut donc se permettre d'avoir
des doutes sur le clair). Si on connais disons 20 Mo de clair, soit
2^20 hash, on trouve un P tout les 2^46 essais coutant un hash et une
consultation d'une table tenant en RAM d'un PC. Dès que l'on a 2
valeurs consécutives de P séparées d'un petit nombre de pas (genre
20), on retrouve mu, et le cryptosystème s'effondre (le hash rend même
plus facile de remonter en arrière à partir de la redondance du
clair). On peut accélérer notablement la recherche en concentrant ses
efforts dans l'intervalle de P atteind le plus souvent, compte tenu de
l'intervalle de mu.
Autre attaque: les valeurs de P ont tendance à entrer dans un cycle
relativement court, souvent inférieur à 2^25 valeurs de P (à vue de
nez, pas le temps d'essayer) soit 640 Mo de chiffré, ce qui en terme
de cryptographie moderne est très peu (c'est quelques minutes de vidéo
HD). Cela permet toutes sortes d'attaques SANS disposer de clair
connu, à partir de l'endroit où l'on est rentré dans le cycle court,
sans même avoir à retrouver explicitement P et mu.
Les deux attaques se combinent plutôt bien, la seconde permettant de
retrouver du clair connu à la fin du message, puis la première
retrouvant P et mu pour casser tout le reste.
Ah, et le système n'a aucun intérêt pratique: il est moins efficace
qu'un système plus simple et plus sur genre
C(n) = M(n) XOR HASH(clé || n)
qui de plus a l'avantage de permettre l'accès direct au clair sans
déchiffrer tout ce qui précède.
HASH = MD5, SHA1 ou bien n'importe quelle fonction de hash plus performante. La connaissance de valeurs M(n) permet de remonter a HASH(P(n)) mais comme les fonctions de hash ne sont pas bijectives... on ne peut pas forcément remonter a la bonne valeur de P(n) facilement, et donc remonter a MU et P(0) ??
Haha, cette fois j'attend votre solution avec impatience
Le système n'est pas très bien défini car - on ne sait pas la précision utilisée pour P et mu; dans ce qui suit je vais raisonner en supposant que c'est assimilable à du binaire sur 56 bits avec un facteur d'échelle qui va bien, ce qui est proche de ce que donnerais du double-precision IEEE 754. - on ne sait pas la largeur de la sortie du hash; disons 160 bits (SHA-1) - on ne sait pas comment P(n) est transformé en suite binaire pour calculer HASH (mais c'est sans grande importance pour évaluer la sécurité, c'est juste une variante du hash)
Le système est vulnérable à la force brute: il est concevable d'énumérer une fraction des 2^^56 valeurs possibles de P, et de rechercher si la valeur correspondante du hash de 160 bits est utilisée dans une fraction du message pour laquelle on dispose de clair connu (ou simplement possible: la taille de 160 bits rend les faux positifs très improbables et on peut donc se permettre d'avoir des doutes sur le clair). Si on connais disons 20 Mo de clair, soit 2^20 hash, on trouve un P tout les 2^46 essais coutant un hash et une consultation d'une table tenant en RAM d'un PC. Dès que l'on a 2 valeurs consécutives de P séparées d'un petit nombre de pas (genre 20), on retrouve mu, et le cryptosystème s'effondre (le hash rend même plus facile de remonter en arrière à partir de la redondance du clair). On peut accélérer notablement la recherche en concentrant ses efforts dans l'intervalle de P atteind le plus souvent, compte tenu de l'intervalle de mu.
Autre attaque: les valeurs de P ont tendance à entrer dans un cycle relativement court, souvent inférieur à 2^25 valeurs de P (à vue de nez, pas le temps d'essayer) soit 640 Mo de chiffré, ce qui en terme de cryptographie moderne est très peu (c'est quelques minutes de vidéo HD). Cela permet toutes sortes d'attaques SANS disposer de clair connu, à partir de l'endroit où l'on est rentré dans le cycle court, sans même avoir à retrouver explicitement P et mu.
Les deux attaques se combinent plutôt bien, la seconde permettant de retrouver du clair connu à la fin du message, puis la première retrouvant P et mu pour casser tout le reste.
Ah, et le système n'a aucun intérêt pratique: il est moins efficace qu'un système plus simple et plus sur genre C(n) = M(n) XOR HASH(clé || n) qui de plus a l'avantage de permettre l'accès direct au clair sans déchiffrer tout ce qui précède.
François Grieu
Francois Grieu
Euh pardon, je voulais dire 2^36 essais pour trouver un P, et en 2^46 on a 2^10 P et une chance appréciable de pouvoir trouver mu.
François Grieu
Euh pardon, je voulais dire 2^36 essais pour trouver un P, et en 2^46
on a 2^10 P et une chance appréciable de pouvoir trouver mu.
Euh pardon, je voulais dire 2^36 essais pour trouver un P, et en 2^46 on a 2^10 P et une chance appréciable de pouvoir trouver mu.
François Grieu
Jeff Vidal
On 20 avr, 17:57, Francois Grieu wrote:
Ah, et le système n'a aucun intérêt pratique: il est moins efficace qu'un système plus simple et plus sur genre C(n) = M(n) XOR HASH(clé || n)
|| = OU logique ? Je vois pas en quoi c'est plus sûr...
Ma reflexion était justement d'utiliser du pseudo-aléatoire pour embrouiller le decryptage, mais bon visiblement, ça ne fonctionne pas. Qu'importe c'était juste des refexions en l'air. Merci pour la demonstration en tout cas bravo.
On 20 avr, 17:57, Francois Grieu <fgr...@gmail.com> wrote:
Ah, et le système n'a aucun intérêt pratique: il est moins efficace
qu'un système plus simple et plus sur genre
C(n) = M(n) XOR HASH(clé || n)
|| = OU logique ?
Je vois pas en quoi c'est plus sûr...
Ma reflexion était justement d'utiliser du pseudo-aléatoire pour
embrouiller le decryptage, mais bon visiblement, ça ne fonctionne pas.
Qu'importe c'était juste des refexions en l'air.
Merci pour la demonstration en tout cas bravo.
Ah, et le système n'a aucun intérêt pratique: il est moins efficace qu'un système plus simple et plus sur genre C(n) = M(n) XOR HASH(clé || n)
|| = OU logique ? Je vois pas en quoi c'est plus sûr...
Ma reflexion était justement d'utiliser du pseudo-aléatoire pour embrouiller le decryptage, mais bon visiblement, ça ne fonctionne pas. Qu'importe c'était juste des refexions en l'air. Merci pour la demonstration en tout cas bravo.
Francois Grieu
On 20 avr, 19:39, Jeff Vidal wrote:
On 20 avr, 17:57, Francois Grieu wrote:
Ah, et le système n'a aucun intérêt pratique: il est moins efficace qu'un système plus simple et plus sur genre C(n) = M(n) XOR HASH(clé || n)
|| = OU logique ? Je vois pas en quoi c'est plus sûr...
Dans mon esprit, clé || n désigne la concaténation de la clé et de l'expression binaire de n.
C'est plus sur, au sens où avec certaines hypothèses standard sur la fonction de hashage (que la fonction de hashage est assimilable à un oracle qui tire un nombre au hasard chaque fois que l'on lui présente une nouvelle entrée, et sinon ressort la valeur précédente qu'il avait sorti pour l'entrée en question) la sécurité (en bit) est en gros limitée par la taille en bit de la clé et la moitié de la largeur de la sortie du hash; alors que dans le système que vous proposiez, la sécurité est en gros limitée au quart de la taille en bit de la clé, si l'on considère ma seconde attaque.
Ma reflexion était justement d'utiliser du pseudo-aléatoire pour embrouiller le decryptage, mais bon visiblement, ça ne fonctionne pas. Qu'importe c'était juste des refexions en l'air. Merci pour la demonstration en tout cas bravo.
Désolé si mon ton a pu sembler cassant, ce n'était pas le but. Je voulais seulement souligner que créer un cryptosystème en suivant la ligne de pensée "cahotique implique sur", cela ne fonctionne pas du tout. En fait on ne connais pas de technique dont ont sait garantir qu'elle fonctionne, sauf à supposer un autre bloc sur, genre un hash. Les meilleurs systèmes efficaces arrivent tout juste à démontrer qu'ils résistent à telle ou telle technique (le minimum est la cryptanalyse différentielle), et en fait bien peu de gens arrivent à comprendre complètement de telles démonstrations (je ne me compte pas dans le nombre).
François Grieu
On 20 avr, 19:39, Jeff Vidal <jeffvi...@gmail.com> wrote:
On 20 avr, 17:57, Francois Grieu <fgr...@gmail.com> wrote:
Ah, et le système n'a aucun intérêt pratique: il est moins efficace
qu'un système plus simple et plus sur genre
C(n) = M(n) XOR HASH(clé || n)
|| = OU logique ?
Je vois pas en quoi c'est plus sûr...
Dans mon esprit, clé || n désigne la concaténation de la clé et de
l'expression binaire de n.
C'est plus sur, au sens où avec certaines hypothèses standard sur la
fonction de hashage (que la fonction de hashage est assimilable à un
oracle qui tire un nombre au hasard chaque fois que l'on lui présente
une nouvelle entrée, et sinon ressort la valeur précédente qu'il avait
sorti pour l'entrée en question) la sécurité (en bit) est en gros
limitée par la taille en bit de la clé et la moitié de la largeur de
la sortie du hash; alors que dans le système que vous proposiez, la
sécurité est en gros limitée au quart de la taille en bit de la clé,
si l'on considère ma seconde attaque.
Ma reflexion était justement d'utiliser du pseudo-aléatoire pour
embrouiller le decryptage, mais bon visiblement, ça ne fonctionne pas.
Qu'importe c'était juste des refexions en l'air.
Merci pour la demonstration en tout cas bravo.
Désolé si mon ton a pu sembler cassant, ce n'était pas le but. Je
voulais seulement souligner que créer un cryptosystème en suivant la
ligne de pensée "cahotique implique sur", cela ne fonctionne pas du
tout. En fait on ne connais pas de technique dont ont sait garantir
qu'elle fonctionne, sauf à supposer un autre bloc sur, genre un hash.
Les meilleurs systèmes efficaces arrivent tout juste à démontrer
qu'ils résistent à telle ou telle technique (le minimum est la
cryptanalyse différentielle), et en fait bien peu de gens arrivent à
comprendre complètement de telles démonstrations (je ne me compte pas
dans le nombre).
Ah, et le système n'a aucun intérêt pratique: il est moins efficace qu'un système plus simple et plus sur genre C(n) = M(n) XOR HASH(clé || n)
|| = OU logique ? Je vois pas en quoi c'est plus sûr...
Dans mon esprit, clé || n désigne la concaténation de la clé et de l'expression binaire de n.
C'est plus sur, au sens où avec certaines hypothèses standard sur la fonction de hashage (que la fonction de hashage est assimilable à un oracle qui tire un nombre au hasard chaque fois que l'on lui présente une nouvelle entrée, et sinon ressort la valeur précédente qu'il avait sorti pour l'entrée en question) la sécurité (en bit) est en gros limitée par la taille en bit de la clé et la moitié de la largeur de la sortie du hash; alors que dans le système que vous proposiez, la sécurité est en gros limitée au quart de la taille en bit de la clé, si l'on considère ma seconde attaque.
Ma reflexion était justement d'utiliser du pseudo-aléatoire pour embrouiller le decryptage, mais bon visiblement, ça ne fonctionne pas. Qu'importe c'était juste des refexions en l'air. Merci pour la demonstration en tout cas bravo.
Désolé si mon ton a pu sembler cassant, ce n'était pas le but. Je voulais seulement souligner que créer un cryptosystème en suivant la ligne de pensée "cahotique implique sur", cela ne fonctionne pas du tout. En fait on ne connais pas de technique dont ont sait garantir qu'elle fonctionne, sauf à supposer un autre bloc sur, genre un hash. Les meilleurs systèmes efficaces arrivent tout juste à démontrer qu'ils résistent à telle ou telle technique (le minimum est la cryptanalyse différentielle), et en fait bien peu de gens arrivent à comprendre complètement de telles démonstrations (je ne me compte pas dans le nombre).
