Forum de mathématiques - Bibm@th.net

Bonsoir,

* J’avais juste repris l’expression  « Et avec ma petite machine perso, je peux fournir à la demande 20000 décimales en 1,5 s... » :)

* «Décoder le message codé de cette façon est-il possible ? nerosson avait écrit "code-aléatoire-une-fois" et tout comme Fred avait dit qu'en cas de code aussi long que le texte et utilisé une seule fois, la réponse est non »

D’accord, mais mon doute était surtout sur le fait d’utiliser une clef non parfaitement aléatoire : je ne pense pas que l’utilisation du développement décimal de pi ou de sqrt(2)… puisse être considérée comme une clef aléatoire tout simplement parce que l’on peut « compresser » cette clef et que l’aléatoire quant-à lui est incompressible. Ma question porte d’avantage sur l’impact sur la sureté du codage de l’utilisation d’une clef qui n’est pas aléatoire au sens stricte (mais elle a certes la même longueur que le message à coder). Je m’intéresse aux alternatives au protocole (à la théorie) car celui-ci est très (trop) contraignant et j’ai du mal à saisir, à quantifier les effets (néfastes) de l’utilisation d’une clef que je qualifierais de réelle (j’entends par là, clef qui est le développement décimal d’un réel quelconque convenue entre l’émetteur et le récepteur du message).

Comment pourrait-on déchiffré un code codé de cette manière ? Quelles serait les pistes d’attaques ?

Bien sûr on peut imaginer d’autres clefs que l’on pourrait qualifier de « clef chaotique compressible» (je m’excuse pour l’imprécision de mon vocabulaire) par exemple une partie seulement du développement décimal d’un réel, des portions de celui-ci… ou bien la succession des termes d’une suite (la clef serait donc la suite)…

En fait, ce que j’ai du mal à comprendre, c’est la frontière entre :
- le code Vernam « pur » où la clef et parfaitement aléatoire (c’est-à-dire que même un ordinateur quelconque ne peut la créer car son mode de génération n’est pas aléatoire mais déterministe, là aussi un sujet passionnant sur la génération des nombres aléatoires par une machine informatique :))
- et le code où la clef est de la même longueur de que le message à crypter (et non périodique bien sûr) et est du type développement décimal, suite …

L’avantage de cette alternative est plutôt considérable car on réduit la taille de la clef qui est dès lors plus facile à transmettre (même si il est nécessaire de la changer à chaque nouveau message).

* Quelles seraient ses faiblesses ? Un code aléatoire est non seulement composé d'une succession de chiffres choisis aléatoirement mais, pour moi, aussi ne pas pouvoir être conjecturé...

Oui, parfaitement d’accord, mais à la place de celui qui intercepte le message, il ne connait pas nom plus la clef.

La seule solution que j’envisage, en me plaçant à la place de l’intercepteur, est la suivante : je sais que le message a été codé par Vernam, je sais aussi que la clef est le développement décimal (DD) d’un réel « chaotique » (comme pi mais pas 2 par exemple), qu’est ce qui me reste à faire ? Essayer en prenant chaque réel chaotique (donc une infinité) appliquer avec le code le XOR et voir si ça donne des mots qui existent ? Je ne vois pas autrement ?

Encore pire, si je ne sais pas si la clef utilisée est un DD ou bien d’une portion de celui-ci, ou bien si il s’agit d’une suite.

* « Exemple, un de nos membres, nous a proposé 10 débuts de nombres réels :
1)    1,57079...
2)    2,718...
3)    2,4142...
4)    1,6180...
5)    0,0000048481...
6)    0,8059959...
7)    0,079577...
8)    0,016887...
9)    1296000,00...
10)   23,14069...
Ils ont tous été identifiés... »

Impressionnant ! Certains sont assez courants, mais d’autres ?? J’aimerais bien connaître leurs méthodes :)

* "Ta solution de transmettre le code sous forme compressée pose le même problème d'interception que s'il ne l'était pas, ça ne change pas le problème..."

Ce n’est pas le code que je compresse mais la clef (je m’excuse si je me suis mal exprimé).
Et je trouve qu’il est particulièrement intéressant de comprimer cette clef (même si en faisant cela il semble que l’on ne respecte pas le protocole de Vernam).

* Juste pour finir, petite question :
Imaginons, l’intercepteur a le code (en entier comme c'est souvent le cas :)) et le début de la clef (il peut donc très facilement décoder autant de caractères qu’en comporte la clef) mais il en veut plus. Il sait aussi que la clef n’est pas aléatoire au sens stricte, et qu’elle a été générée grâce à une suite (la clef est donc la succession des termes d’une suite mis bout à bout).

Comment faire pour en déduire la suite ? (je n’ai pas la réponse :))

Exemple :
Le début de la clef est :
228104210951481199358998242…
Comment deviner la suite (là je connais la suite (ou du moins une suite possible, question : y’en a-t-il plusieurs ? comment le savoir ? :)) mais je ne saurais pas comment faire).

Merci encore pour les réponses et pour le temps consacré !
Bonne soirée.