Chiffre de Vernam

Loïc 2.71 · 14-04-2015 19:52:31

Bonjour,
J’ai quelques petites questions concernant le chiffre de Vernam (ou masque jetable) :
Cas de figure :
- on utilise une clef de la même longueur que le message à coder (là on respecte le protocole)
- mais cette clef n’est pas parfaitement aléatoire : par exemple on utilise pour clef « sqrt(2) »
Je m’explique, la clef est constituée les premières décimales la racine de 2 (on peut les obtenir facilement et avec autant de décimale que le message à coder, notamment par la méthode de Newton appliquée à la fonction x -> x²-2).
Je passe les détails sur la conversion en binaire par exemple pour pouvoir appliquer le XOR facilement...
Bien sur, on peut choisir comme clef n’importe quels réels « chaotiques compréssés » c'est-à-dire
• dont la succession des décimales semble aléatoire, 2/3 ne l’est pas, pi oui
• et dont on peut le « synthétisé » : on peut sythétisé 1.41421356237… en sqrt(2) (si les chiffre qui suivent sont bons) on peut de même « synthétiser » e, pi … mais pas 75918745412589…
(j’espère que mon vocabulaire vous convient)
J’ai conscience que la clef réelle « chaotique compressée » n’est pas aléatoire (non respect du protocole) car on ne peut pas compresser l’aléatoire.
Mes questions sont :
• Existe-t-il vraiment une infinité de réels « chaotiques » ? (question mathématique, simple confirmation)
• S’il en existe une infinité, décoder le message codé de cette façon est-il possible ?
• Quels serait ses faiblesses ?
• S’il s’avère très difficile de déchiffrer un tel message, pourquoi semble-t-il si peu utilisé ? (on pourrait imaginer transmettre la clef « compressée » (ici « sqrt(2) ») pas le système RSA gourmand en calculs, puis échanger un fichier lourd par ce protocole simplifié (plus économe en calculs).
En vous remerciant par avance.

Dernière modification par Loïc 2.71 (14-04-2015 19:58:51)

yoshi · 14-04-2015 21:25:19

Bonsoir,

Bienvenue chez nous...

Feu notre doyen et spécialiste de la cryptographie, puisque ex pro, nerosson t'aurait répondu autre chose que des banalités...
Je vais essayer de l'invoquer post mortem :
http://www.bibmath.net/forums/viewtopic.php?id=4382

Fred notre admin a pondu quelque chose là-dessus :
http://www.bibmath.net/crypto/index.php … rne/vernam

Soit le nombre suivant : 61803398874989484820
Hasard ? Succession aléatoire ? Oui et non...
Parce que si tu utilises un code de 1000 chiffres dont je découvre les 20 premiers ci-dessus, j'identifierai alors les 1000 premières décimales de :

[tex]\phi=\frac{1+\sqrt 5}{2} \approx[/tex] 1.618033988749894848204586834365638117720309179805762862135448622705260462818902449707207204189391137484754088075386891752126633862223536931793180060766726354433389086595939582905638322661319928290267880675208766892501711696207032221043216269548626296313614438149758701220340805887954454749246185695364864449241044320771344947049565846788509874339442212544877066478091588460749988712400765217057517978834166256249407589069704000281210427621771117778053153171410117046665991466979873176135600670874807101317952368942752194843530567830022878569978297783478458782289110976250030269615617002504643382437764861028383126833037242926752631165339247316711121158818638513316203840052221657912866752946549068113171599343235973494985090409476213222981017261070596116456299098162905552085247903524060201727997471753427775927786256194320827505131218156285512224809394712341451702237358057727861600868838295230459264787801788992199027077690389532196819861514378031499741106926088674296226757560523172777520353613936

Et avec ma petite machine perso, je peux fournir à la demande 20000 décimales en 1,5 s...

Mieux qu'une longue redite de ma part à propos du chaos et des mathématiques:
http://www-math.univ-poitiers.fr/~laurent/chau.pdf

@+

Dernière modification par yoshi (15-04-2015 10:48:21)

Loïc 2.71 · 16-04-2015 17:45:06

Bonjour,
Merci pour cette réponse rapide.
Je voulais (si possible) connaître le fonctionnement de « la petite machine perso ».

Personnellement je travaille sous Python, et j’utilise la méthode de Newton pour accéder au développement décimal (DD) approché de racines carrées, le module « DECIMAL » de Python permettant d’accéder à la précision.
Exemple pour trouver le DD de sqrt(2) :

(je me passe du formalisme mathématique pour des raisons pratiques)

On s’intéresse à : f(x) = x²-2 fonction qui a pour racine positive sqrt(2)
Newton permet de construire la suite (Un) tel que :
Un+1 = Un – (Un²-2)/(2*Un)
Cette méthode fonctionne assez bien car la convergence de Newton est rapide. De plus il est aisé d’extraire deux suites (vn) et (v’n) telle que :
Un = vn/v’n
Dans notre exemple on prend :
vn+1= vn²+2*v’n
v’n+1=2*vn*v’n
On se donne pour initialisation v0 = 2 et v’0 = 1
La forme fractionnaire de Un permet d’utiliser la puissance du module « DECIMAL » et du typage "int"
Et le tout fonctionne effectivement pas mal puisque on peut majorer l’erreur :
|Un-sqrt(2)|<=3/5^2^n

Pour le reste je suis toujours intéressé si quelqu’un a des idées pour mon message précédent car malgré mes recherches je n'ai rien :
• Décoder le message codé de cette façon est-il possible ?
• Quels serait ses faiblesses ?
• S’il s’avère très difficile de déchiffrer un tel message, pourquoi semble-t-il si peu utilisé ? (on pourrait imaginer transmettre la clef « compressée » (ici « sqrt(2) ») pas le système RSA gourmand en calculs, puis échanger un fichier lourd par ce protocole simplifié (plus économe en calculs).

Bien coordialement.

Dernière modification par Loïc 2.71 (16-04-2015 17:53:26)

yoshi · 16-04-2015 20:22:28

Salut,

Je voulais (si possible) connaître le fonctionnement de « la petite machine perso ».

??? Qu'est-ce que tu entends par "petite machine perso" ?

Personnellement je travaille sous Python, et j’utilise la méthode de Newton pour accéder au développement décimal (DD) approché de racines carrées, le module « DECIMAL » de Python permettant d’accéder à la précision.

Moi aussi...
Pour le "fun", j'ai écrit un calcul de [tex]\sqrt 5[/tex] comme je l'avais appris lorsque j'étais en 4e (il y a longtemps...) et qu'on le faisait avec papier crayon.
Ma machine peut calculer le nombre d'or avec 20000 décimales en 17 s en ne travaillant qu'avec des entiers....
Par contre, pour la rapidité, il lui faut 0,5 s avec la méthode de Newton et 17 itérations seulement pour avoir 20000 décimales...
Voilà ce que j'avais fait lorsque j'ai découvert que getcontext().prec acceptait 20000 (jusqu'alors je m'étais dit - à tort donc - que ce n'était pas possible et que les temps de calculs seraient prohibitifs) comme paramètre :

#!/usr/bin/python
# -*- coding: UTF-8 -*-

from time import process_time

from decimal import *

getcontext().prec = 20000

def nbor(n):

    u=Decimal(n)

    for i in range(1,17):

       u=(u+Decimal(5)/u)/Decimal(2)

    u=(1+Decimal(u))/Decimal(2)

    print("phi =",u)

tp_debut=process_time()

n=5

nbor(n)

print ("Durée du calcul :",process_time()-tp_debut,'s')

Tes questions.
Si tu as lu le topo de Fred et la prose de feu nerosson :
* 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.

* S’il s’avère très difficile de déchiffrer un tel message, pourquoi semble-t-il si peu utilisé ? Parce qu'il faudrait changer de code à chaque fois sinon Fred a expliqué les infos qu'on peut en tirer...

* 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é...
Or, [tex]\sqrt 2[/tex] ou [tex]\frac{1+\sqrt 5}{2}[/tex] sont "transparents"...
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...
Donc même en ne connaissant que les premières décimales on peut en conjecturer la suite...
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...

@+

Loïc 2.71 · 16-04-2015 21:51:52

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.

Dernière modification par Loïc 2.71 (16-04-2015 21:53:57)

yoshi · 17-04-2015 10:11:21

Salut,

Déclaration préalable : je suis un très mauvais décodeur, hélas.

Ce n’est pas le code que je compresse mais la clef (je m’excuse si je me suis mal exprimé).

Non, c'est moi qui me suis mal exprimé, je voulais bien sûr parler de la clef.
Et il faut donc lire :

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

Loïc 2.71 a écrit :

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 ?

Ainsi que je l'ai dit en préambule, je suis un très mauvais décodeur...
Prendre chaque réel chaotique : ça c'est la méthode "brute force". Effectivement vu le nombre potentiellement très élevé de ces réels, ça risque de prendre un temps certain : il faudrait pouvoir restreindre le champ des essais.
Dans ce cas-là, la situation est différente selon que c'est le 1er message intercepté ou le tout premier. Dans le 1er cas, Fred a montré dans son topo qu'on pouvait en tirer des informations si la clé utilisée est la même...
Dans le cas contraire, même en cas de certitude sur une clé à base de réel chaotique, même la force brute risque fort d'être inopérante...
Moi je commencerais par répertorier les réels chaotiques les moins exotiques, comme le nombre d'or, l'exponentielle, [tex]\frac{1}{6\pi^2}[/tex] (rapport du volume de la sphère au cube de sa circonférence : n° 8 de la liste des 10 du post #4), [tex]\sqrt[3]{\frac{\pi}{6}}[/tex] (n° 6 de la liste), etc., voire leur log...
Mais on n'est pas couchés !!!
D'après ce que j'ai vu du travail de mes petits camarades quand ils ont un message avec des lettres, ils commencent par chercher la longueur de la clé (plus elle est longue plus c'est difficile), puis ils font des colonnes et les remplissent... après ils analysent
Je me demande ce qu'ils feraient avec du Vigenère utilisant une clé de 500 lettres pour un message codé de 500 lettres.
Je leyr avais fournu un message codé avec du Vigenère codé avec une clé de 11 lettres : ils m'ont décodé le message, m'ont dit la longueur de la clé et m'ont pourtant fourni une clé fausse...
J'ai aussi vu que plus le message est long, plus ils en tirent d'infos.
Donc, réel chaotique ou pas, le débat est théorique (c'est sur ce plan que je me place) on divise peut-être par 10000 les possibilités, mais si au départ, il y en a 10²⁰, il en reste encore 10¹⁶...

Loïc 2.71 a écrit :

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

Exact, je n'avais pas fait attention...
Tu as donc eu ta réponse...
Voilà, de plus, le script inspiré de ce qu'on fait "à la main" (40 fois plus lent que l'autre).

#!/usr/bin/env python
# -*- coding: UTF8 -*-

from time import process_time

def rac5(prc):

    reste,md,finbcl,L=100,4,prc+1,["2"]

    for j in range(finbcl):

        md=10*md

        md=md*10

        i=9-(md*5>reste)*5

        while (md+i)*i<=reste:

            i+=1

        i-=1

        md+=i

        L.append(str(i))

        reste=(reste-md*i)*100

        md+=i

    L[0]='3'

    return "".join(L)

tp_debut=process_time()

# Précision attendue en nombre de chiffres après la virgule

prc=20000

# *****************************

nb = str(int(rac5(prc))//2)

phi=nb[0]+'.'+nb[1:prc+1]

print ("          Le nombre d'or avec", prc,"décimales est :")

print()

print ("phi =",phi)

print()

print ("Durée du calcul :",process_time()-tp_debut,'s')

Loïc 2.71 a écrit :

là aussi un sujet passionnant sur la génération des nombres aléatoires par une machine informatique :))

Oui, pour le moment, les langages de programmation ne font que s'approcher plus ou moins bien de l'aléatoire...
J'ai toujours lu que le moins mauvais de tous était MatLab...

@+

freddy · 17-04-2015 14:30:42

Salut yoshi,

en réalité, non (générateur aléatoire. En lien l'ensemble des logiciels qui ont implémenté le Mersenne Twister pour générer des nombres pseudo-aléatoires. Tu verras que pyhon en fait partie.
Et ledit Mersenne Twister, avec le tore mélangé, et l'outil qui est le plus performant actuellement !

yoshi · 17-04-2015 15:48:08

Re,

Merci msieu...
Voilà une nouvelle qu'elle est bonne..

@+

PS
[HS] As tu- lu le courrier envoyé sur ton "mail chaud" ? [/HS]

freddy · 17-04-2015 19:32:26

@yoshi,
ma messagerie mail chaud ne fonctionne plus, petit mou l'a bloquée, je ne sais pourquoi. Ecris moi à l'adresse jointe à mon peuso sur le site, merci.

Dernière modification par freddy (17-04-2015 19:32:38)

yoshi · 18-04-2015 16:50:04

@Loïc 2.71
Bon, alors j'ai essayé de comprendre comment programmer cette méthode.
Voilà ce que j'ai fait
Je charge le message, je remplace les lettres accentuées (et ç) puis je vire la ponctuation.
Je prends alors la longueur du message que je divise par 26 (n = quotient +1 si reste >0)
Je constitue alors n alphabets aléatoires de 26 lettres qui composeront ma clé.
Python ne permettant pas de XOR sur des chaînes, ma clé ne comprend pas de lettres, mais les nos d'ordre des lettres dans l'alphabet normal.
J'extrais alors chaque lettre du message et sa position dans le message et je prends son n° d'ordre dans l'alphabet.
Pour chaque lettre, je prends dans la clé le nombre du même index et je fais un XOR sur les 2.
Exemple : si la lettre d'index 77 est un M, elle est à l'index 12 de l'alphabet (en partant de 0)
Si dans ma clé, la valeur à l'index 77 est 23, je fais 12 xor 23 =27 et je stocke le nombre 27.
Le message codé ne sera composé que de nombres à 1 ou 2 chiffres.
Ça fonctionne parce que le décodage fonctionne.

Précision : je ne travaille qu'avec des majuscules.
Je pense qu'il y a trop de failles dans cette méthode, j'aimerais bien l'avis d'un spécialiste.
En attendant je vais essayer de prendre des alphabets mixtes Majuscules/minuscules.
Avec correspondant à des nos de 1 à 26 les majuscules, de 27 à 52 les minuscules...
Puis de coder sur le même principe...

Ça devrait être plus dur à déchiffrer...

@+

yoshi · 19-04-2015 19:22:46

Re,

Je me suis aperçu que les résultats du xor allaient de 0 à 31...
J'ai donc rajouté dans mon alphabet les minuscules de a à f.
J'ai ainsi pu faire apparaître le message codé avec des lettres :
Décodage d'un message codé avec le chiffre de Vernam

          Décodage d'un message codé avec le chiffre de Vernam


Message Codé :

ISYSV RDRRH HCHFA KNDXO KSTME CHUXL KPKbF fccBU eGAba FaCUA BWEYN ZRaEW BYXFX XDGVI 
bUfLY UGKNS GbcIB CXVXU EBDHZ dEGOE GPEQJ NFCKY ecKVA aCVRR UQYKE LOdIe FARTF bEaMZ 
DDEFJ VFYIN KZGCS BJQDW fDUCG EYdce ERKcH UHJdf MbLVe XFFeI IMNPY GYIAX XAUMH cAORc 
dYaWb FGCNM APKJC SCRUQ OYSRD AHbRd KRFSB 


Texte  clair :

MARQU ISESI MONVI SAGEA QUELQ UESTR AITSU NPEUV IEUXS OUVEN EZVOU SQUAM ONAGE VOUSN 
REZGU EREMI EUXLE TEMPS AUXPL USBEL LESCH OSESS EPLAI TAFAI REUNA FFRON TETSA URAFA 
SROSE SCOMM EILAR IDEMO NFRON TLEME MECOU RSDES PLANE TESRE GLENO SJOUR SETNO SNUIT 
VUCEQ UEVOU SETES VOUSS EREZC EQUEJ ESUIS

Mais le remplacement des lettres accentuées en codage de caractères UTF-8 ne marche pas :

Je vire donc ces lettres avec OpenOffice Writer via la commande Rechercher/Remplacer.
Je stocke sur disque ce message clair, ainsi que mes alphabets incohérents pour mes tests : d'ailleurs je vois qu'il y a un pb fin 1ere ligne/ début 2e, je vais chercher pourquoi ; il manque 5 lettres. C'est le codage qui est en cause.

@+

yoshi · 19-04-2015 22:47:48

Re,

Fausse alerte : juste un problème de gestion du nombre de blocs de 5 par ligne. C'est réglé :

     Décodage d'un message codé avec le chiffre de Vernam


Message Codé :

ISYSV RDRRH HCHFA KNDXO KSTME CHUXL KPKbF fccBU eGAba FaCUA BWEYN ZRaEW BYXFX XDGVI 
cdJAP bUfLY UGKNS GbcIB CXVXU EBDHZ dEGOE GPEQJ NFCKY ecKVA aCVRR UQYKE LOdIe FARTF 
bEaMZ ZHJFG DDEFJ VFYIN KZGCS BJQDW fDUCG EYdce ERKcH UHJdf MbLVe XFFeI IMNPY GYIAX 
XAUMH cAORc HeeGW dYaWb FGCNM APKJC SCRUQ OYSRD AHbRd KRFSB 



Texte  clair :

MARQU ISESI MONVI SAGEA QUELQ UESTR AITSU NPEUV IEUXS OUVEN EZVOU SQUAM ONAGE VOUSN 
EVAUD REZGU EREMI EUXLE TEMPS AUXPL USBEL LESCH OSESS EPLAI TAFAI REUNA FFRON TETSA 
URAFA NERVO SROSE SCOMM EILAR IDEMO NFRON TLEME MECOU RSDES PLANE TESRE GLENO SJOUR 
SETNO SNUIT SONMA VUCEQ UEVOU SETES VOUSS EREZC EQUEJ ESUIS

@+

Forum de mathématiques - Bibm@th.net

#1 14-04-2015 19:52:31

Chiffre de Vernam

#2 14-04-2015 21:25:19

Re : Chiffre de Vernam

#3 16-04-2015 17:45:06

Re : Chiffre de Vernam

#4 16-04-2015 20:22:28

Re : Chiffre de Vernam

#5 16-04-2015 21:51:52

Re : Chiffre de Vernam

#6 17-04-2015 10:11:21

Re : Chiffre de Vernam

#7 17-04-2015 14:30:42

Re : Chiffre de Vernam

#8 17-04-2015 15:48:08

Re : Chiffre de Vernam

#9 17-04-2015 19:32:26

Re : Chiffre de Vernam

#10 18-04-2015 16:50:04

Re : Chiffre de Vernam

#11 19-04-2015 19:22:46

Re : Chiffre de Vernam

#12 19-04-2015 22:47:48

Re : Chiffre de Vernam

Réponse rapide

Pied de page des forums