J'essaye de développer un petit algorithme pour crypter/décrypter un
fichier de n'importe quel type. C'est plus ou moins clair dans ma tête (une
partie oui, une partie non). J'essaye de mettre ça en forme avec TURBO
PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la
compatibilité des fichiers entre MS-DOS et WINDOWS).
En gros, je voulais vous expliquer un peu mon idée, et voir votre avis
là-dessus.
Ce que je veux faire : un programme (et donc un algo :) qui permette de
crypter un fichier de n'importe quel nature, s'il n'est pas trop gros
(maximum 1 à 5 Mo). En raison des contraintes imposées par le langage, on ne
peut crypter qu'un fichier à la fois. J'ai déjà fait des petits programmes
de cryptage, mais c'était des petits trucs de bricolage. Là, sans avoir
envie de pondre du DES ou quoi, j'ai quand même envie de faire quelque chose
de 'sérieux', je veux dire quelque chose qui soit vraiment dur à casser.
Il y a deux parties dans l'algorithme.
1. L'encodage.
On décompose le fichier en blocs de 8 octets (ça tombe toujours juste,
c'est arrangé...), ça nous donne un tableau 8x8 rempli de 0 ou de 1 (plus
précisément, chaque ligne comporte le code binaire d'un octet). On répète 10
fois l'ensemble suivant :
- on retourne chaque tableau individuellement ;
- on déplace les octets d'un tableau à un autre. Le résultat est assez
complexe (si on cherche à voir où les octets atterrissent).
Après l'encodage, les bits sont complètement mélangés, et on a reformé
un fichier de caractères.
2. Le cryptage.
Là, c'est un peu moins clair dans mon esprit. Je pense prendre une clef
de 16 caractères (donc en gros 255 possibilités par caractère de la clef,
moins une vingtaine (entrée, supprimer, etc.) inutilisables, donc en gros
220^16 clefs possibles). Avec cette clef, on génère une liste de nombre
pseudo-aléatoires longue (probablement 1024 octets). On code le résultat de
l'encodage avec cette clef au moyen d'un XOR. Certes, il y a répétition,
mais d'une part, la chaîne est très longue, et d'autre part, l'encodage a
complètement brouillé les bits. Je ne pense pas qu'une telle répétition
porte préjudice à la sécurité du code.
Voilà. Le principe de cryptage est très simple, en lui-même, mais il est
assez solide, je pense, du fait que la chaîne avec laquelle on code est
longue (on peut encore la rallonger), et d'autre part du fait du grand
nombre de clefs possibles qui rend très difficile le cassage par force
brute. D'autre part, l'extrême simplicité de ce procédé garantit au moins
une chose : il n'y a pas de trappe dans l'algorithme (volontaire ou
involontaire).
Alors, deux questions :
1. Est-ce que l'encodage est absolument nécessaire ? S'il est là, après
avoir testé X clefs (attaque par force brute), on reste obligé de décoder,
ça fait perdre du temps.
2. Quelle sécurité offre un algorithme de ce genre ? Les calculs ne sont
pas compliqués (donc pas longs), mais il y a un grand nombre de clefs
possibles. C'est un cryptage à combien de bits, il faudrait combien de temps
à un ordinateur classique pour casser ça par la force brute (une idée ?) ?
3. Est-ce qu'il ne vaudrait pas mieux mêler l'encodage et le cryptage,
c'est-à-dire crypter au fur et à mesure qu'on encode. Je pense que la
sécurité en serait améliorée (plus de calculs à effectuer pour un cassage
par force brute).
Merci à vous si vous prenez un peu de votre temps pour me répondre...
Je pense qu'il veut faire cela afin de d'empecher les attaques sur la forme du clair (frequences, entetes ...). Je doute également que ça ait une quelquonque utilité, mais je ne suis pas capable de le prouver.
Oui, c'est bien ça ce que je recherche. Mais je ne comprends pas pourquoi ce serait inutile, dans la mesure où ce ne sont même pas les caractères qu'on échange, mais les bits qui leurs correspondent. Enfin, si vous pouviez expliquer tout ça...
Le but recherché, c'est peut-être comme bien d'autres il s'ennuie à la plage et préfère rester chez lui à codouiller des trucs pour passer le temps.
... gagné !
Bien à vous, Christophe
Merci, Marc...
1. L'encodage.
Phase totalement inutile, AMHA.
Je pense qu'il veut faire cela afin de d'empecher les attaques sur
la forme du clair (frequences, entetes ...). Je doute également que
ça ait une quelquonque utilité, mais je ne suis pas capable de le
prouver.
Oui, c'est bien ça ce que je recherche. Mais je ne comprends pas
pourquoi ce serait inutile, dans la mesure où ce ne sont même pas les
caractères qu'on échange, mais les bits qui leurs correspondent. Enfin, si
vous pouviez expliquer tout ça...
Le but recherché, c'est peut-être comme bien d'autres il s'ennuie à la
plage et préfère rester chez lui à codouiller des trucs pour passer le
temps.
Je pense qu'il veut faire cela afin de d'empecher les attaques sur la forme du clair (frequences, entetes ...). Je doute également que ça ait une quelquonque utilité, mais je ne suis pas capable de le prouver.
Oui, c'est bien ça ce que je recherche. Mais je ne comprends pas pourquoi ce serait inutile, dans la mesure où ce ne sont même pas les caractères qu'on échange, mais les bits qui leurs correspondent. Enfin, si vous pouviez expliquer tout ça...
Le but recherché, c'est peut-être comme bien d'autres il s'ennuie à la plage et préfère rester chez lui à codouiller des trucs pour passer le temps.
... gagné !
Bien à vous, Christophe
Horace
Michel :
Et si vous reveniez quand ce sera clair ?
A moins que je ne sois venu dans l'idée de clarifier mes idées, justement. C'est vrai, pourquoi être désagréable ?
J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
En principe, la programmation n'est pas la partie la plus difficile dans la mise au point d'un algo de chiffrement.
Non, ce n'est pas difficile, il n'est pas question de ça. Mais je précise bien : "en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS."
1. L'encodage.
Phase totalement inutile, AMHA.
Je n'ai rien contre le fait qu'on me dise que c'est inutile, mais que quelqu'un me dise que c'est inutile sans me dire pourquoi, franchement, je ne trouve pas cela très constructif.
Je ne pense pas qu'une telle répétition porte préjudice à la sécurité du code.
Si. Mais là n'est pas le plus gros problème.
Donc, même si on a une clef très longue (1024) et qu'on la répète sur un texte complètement brouillé, cela porte préjudice à la sécurité... ? Pourriez-vous expliciter ??
Voilà. Le principe de cryptage est très simple
Ah ? Je n'ai pas vu le principe.
Ben on prend une clef de 16 caractères, on génère une clef de 1024 (peu importe l'algo, c'est une génération de nombre pseudo aléatoire) et on code avec un XOR le message en répétant la clef. Mais je suis d'accord avec vous, l'histoire du codage reste à améliorer. Je voulais surtout parler de l'encodage (mais personne n'en a rien dit...).
Question idiote : quel est le but recherché ?
Marc aura très bien répondu à cette question...
Bien à vous, Christophe
Michel :
Et si vous reveniez quand ce sera clair ?
A moins que je ne sois venu dans l'idée de clarifier mes idées,
justement. C'est vrai, pourquoi être désagréable ?
J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros
problèmes pour programmer (en raison de la compatibilité des
fichiers entre MS-DOS et WINDOWS).
En principe, la programmation n'est pas la partie la plus difficile
dans la mise au point d'un algo de chiffrement.
Non, ce n'est pas difficile, il n'est pas question de ça. Mais je
précise bien : "en raison de la compatibilité des fichiers entre MS-DOS et
WINDOWS."
1. L'encodage.
Phase totalement inutile, AMHA.
Je n'ai rien contre le fait qu'on me dise que c'est inutile, mais que
quelqu'un me dise que c'est inutile sans me dire pourquoi, franchement, je
ne trouve pas cela très constructif.
Je ne pense pas qu'une telle répétition porte préjudice à la
sécurité du code.
Si. Mais là n'est pas le plus gros problème.
Donc, même si on a une clef très longue (1024) et qu'on la répète sur un
texte complètement brouillé, cela porte préjudice à la sécurité... ?
Pourriez-vous expliciter ??
Voilà. Le principe de cryptage est très simple
Ah ? Je n'ai pas vu le principe.
Ben on prend une clef de 16 caractères, on génère une clef de 1024 (peu
importe l'algo, c'est une génération de nombre pseudo aléatoire) et on code
avec un XOR le message en répétant la clef.
Mais je suis d'accord avec vous, l'histoire du codage reste à améliorer.
Je voulais surtout parler de l'encodage (mais personne n'en a rien dit...).
A moins que je ne sois venu dans l'idée de clarifier mes idées, justement. C'est vrai, pourquoi être désagréable ?
J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
En principe, la programmation n'est pas la partie la plus difficile dans la mise au point d'un algo de chiffrement.
Non, ce n'est pas difficile, il n'est pas question de ça. Mais je précise bien : "en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS."
1. L'encodage.
Phase totalement inutile, AMHA.
Je n'ai rien contre le fait qu'on me dise que c'est inutile, mais que quelqu'un me dise que c'est inutile sans me dire pourquoi, franchement, je ne trouve pas cela très constructif.
Je ne pense pas qu'une telle répétition porte préjudice à la sécurité du code.
Si. Mais là n'est pas le plus gros problème.
Donc, même si on a une clef très longue (1024) et qu'on la répète sur un texte complètement brouillé, cela porte préjudice à la sécurité... ? Pourriez-vous expliciter ??
Voilà. Le principe de cryptage est très simple
Ah ? Je n'ai pas vu le principe.
Ben on prend une clef de 16 caractères, on génère une clef de 1024 (peu importe l'algo, c'est une génération de nombre pseudo aléatoire) et on code avec un XOR le message en répétant la clef. Mais je suis d'accord avec vous, l'histoire du codage reste à améliorer. Je voulais surtout parler de l'encodage (mais personne n'en a rien dit...).
Question idiote : quel est le but recherché ?
Marc aura très bien répondu à cette question...
Bien à vous, Christophe
Horace
Michel :
Zappy n'est pas une référence.
Zappy ?
Ils ne sont pas tous aussi bêtes et aussi méchants que moi. Il ne fallait pas m'invoquer.
Je l'ai fait ?
~~ Christophe
Michel :
Zappy n'est pas une référence.
Zappy ?
Ils ne sont pas tous aussi bêtes et aussi méchants que moi. Il ne
fallait pas m'invoquer.
Ils ne sont pas tous aussi bêtes et aussi méchants que moi. Il ne fallait pas m'invoquer.
Je l'ai fait ?
~~ Christophe
Horace
Michel :
220^16 ~ 2^124 C'est presque beaucoup. On peut discuter le 220. Je viserais plutôt 64 au grand maxi. Ce qui amène quand même à 96 bits d'entropie, encore beaucoup.
C'est bizarre, mais le SEUL point qui me paraîsse difficilement attaquable, c'est justement la longueur de la clé. Tout le reste est à jeter :-]
Oui, oui, pour le cryptage, je sais, c'est pour ça que j'ai pris des précautions en en parlant (mais tout le monde n'a pas compris ça). Je ne comprends pas en quoi mon encodage est bon à jeter, et c'est à vrai dire la seule chose qui m'intéresse. J'ai eu tort de parler du cryptage dans le post, je n'aurais du parler que de cet encodage.
Bien à vous, Christophe
Michel :
220^16 ~ 2^124
C'est presque beaucoup.
On peut discuter le 220. Je viserais plutôt 64 au grand maxi. Ce
qui amène quand même à 96 bits d'entropie, encore beaucoup.
C'est bizarre, mais le SEUL point qui me paraîsse difficilement
attaquable, c'est justement la longueur de la clé. Tout le reste est à
jeter :-]
Oui, oui, pour le cryptage, je sais, c'est pour ça que j'ai pris des
précautions en en parlant (mais tout le monde n'a pas compris ça). Je ne
comprends pas en quoi mon encodage est bon à jeter, et c'est à vrai dire la
seule chose qui m'intéresse.
J'ai eu tort de parler du cryptage dans le post, je n'aurais du parler
que de cet encodage.
220^16 ~ 2^124 C'est presque beaucoup. On peut discuter le 220. Je viserais plutôt 64 au grand maxi. Ce qui amène quand même à 96 bits d'entropie, encore beaucoup.
C'est bizarre, mais le SEUL point qui me paraîsse difficilement attaquable, c'est justement la longueur de la clé. Tout le reste est à jeter :-]
Oui, oui, pour le cryptage, je sais, c'est pour ça que j'ai pris des précautions en en parlant (mais tout le monde n'a pas compris ça). Je ne comprends pas en quoi mon encodage est bon à jeter, et c'est à vrai dire la seule chose qui m'intéresse. J'ai eu tort de parler du cryptage dans le post, je n'aurais du parler que de cet encodage.
Bien à vous, Christophe
JYP
Manifestement, il ne fait pas bon être candide, par ici. Les ego s'expriment pleinement. Pourtant, à voir les sites de certains de ces cadors bouffis de suffisance, il y a de quoi se marrer.
Bon courage Horace !
Manifestement, il ne fait pas bon être candide, par ici. Les ego s'expriment
pleinement.
Pourtant, à voir les sites de certains de ces cadors bouffis de suffisance,
il y a de quoi se marrer.
Manifestement, il ne fait pas bon être candide, par ici. Les ego s'expriment pleinement. Pourtant, à voir les sites de certains de ces cadors bouffis de suffisance, il y a de quoi se marrer.
Bon courage Horace !
Horace
JYP :
Manifestement, il ne fait pas bon être candide, par ici. Les ego s'expriment
pleinement.
Comme partout, peut-être. Mais ici un peu plus qu'ailleurs, c'est vrai, mais j'ignore pourquoi...
Pourtant, à voir les sites de certains de ces cadors bouffis de suffisance,
il y a de quoi se marrer.
Bon courage Horace !
Merci... mais vous savez, une des raisons pour lesquelles mon pseudonyme est Horace, c'est justement parce que ce personnage est plein de courage...
Bien à vous, Christophe
JYP :
Manifestement, il ne fait pas bon être candide, par ici. Les ego
s'expriment
pleinement.
Comme partout, peut-être. Mais ici un peu plus qu'ailleurs, c'est vrai,
mais j'ignore pourquoi...
Pourtant, à voir les sites de certains de ces cadors bouffis de
suffisance,
il y a de quoi se marrer.
Bon courage Horace !
Merci... mais vous savez, une des raisons pour lesquelles mon pseudonyme
est Horace, c'est justement parce que ce personnage est plein de courage...
Je ne comprends pas la nécéssité d'être désagréable.
"C'est dans ma nature" a dit le scorpion.
Bien je pense qu'il veut que la clef reste suffisament grande par rapport à la taille des données à crypter.
La clé fait 16 octets. Point barre. Si c'est ça, il ne va pas aller loin.
Olivier D.
On 2004-08-10, Horace wrote:
[...] J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
Je ne comprends pas bien cette incompatibilité. Est le problème du CR/LF à la fin de chaque ligne de texte ? ou est-ce le Turbo Pascal qui est incapable d'ouvrir les fichiers en mode binaire ?
Pourquoi ne pas changer de language de programmation, comme le C ou le Python qui sont moins dépendants du système utilisé ? (je ne fais pas de Python mais son apprentissage serait facilité par l'absence de pointeurs comme en C, ce qui est bon pour un débutant)
-- Olivier D.
On 2004-08-10, Horace <ERROR@ERROR.fr> wrote:
[...] J'essaye de mettre ça en forme avec TURBO
PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la
compatibilité des fichiers entre MS-DOS et WINDOWS).
Je ne comprends pas bien cette incompatibilité. Est le problème du CR/LF
à la fin de chaque ligne de texte ? ou est-ce le Turbo Pascal qui est
incapable d'ouvrir les fichiers en mode binaire ?
Pourquoi ne pas changer de language de programmation, comme le C ou le
Python qui sont moins dépendants du système utilisé ? (je ne fais pas de
Python mais son apprentissage serait facilité par l'absence de
pointeurs comme en C, ce qui est bon pour un débutant)
[...] J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
Je ne comprends pas bien cette incompatibilité. Est le problème du CR/LF à la fin de chaque ligne de texte ? ou est-ce le Turbo Pascal qui est incapable d'ouvrir les fichiers en mode binaire ?
Pourquoi ne pas changer de language de programmation, comme le C ou le Python qui sont moins dépendants du système utilisé ? (je ne fais pas de Python mais son apprentissage serait facilité par l'absence de pointeurs comme en C, ce qui est bon pour un débutant)
-- Olivier D.
Horace
Olivier D. :
[...] J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
Je ne comprends pas bien cette incompatibilité.
Je vous rassure : moi non plus !
Est le problème du CR/LF à la fin de chaque ligne de texte ? ou est-ce le Turbo Pascal qui est incapable d'ouvrir les fichiers en mode binaire ?
J'ouvre en FILE OF BYTE. J'explique en détail le problème sur fr.comp.lang.pascal sous le post Gros problème (qui résume bien la situation)... Voyez là-bas pour plus de détails, le forum est plus adapté.
Pourquoi ne pas changer de language de programmation, comme le C ou le Python qui sont moins dépendants du système utilisé ? (je ne fais pas de Python mais son apprentissage serait facilité par l'absence de pointeurs comme en C, ce qui est bon pour un débutant)
Ben oui, c'est une bonne idée. Mais je me débrouille un peu en Pascal, alors je préfèrerais rester là-dessus. Mais je commence à me mettre au C, donc je verrais. Mais comme je n'ai absolument aucune notion, c'est plus pénible (vu que je commencerais d'entrée de jeu avec un programme complexe).
Bien à vous, Christophe
Olivier D. :
[...] J'essaye de mettre ça en forme avec TURBO
PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la
compatibilité des fichiers entre MS-DOS et WINDOWS).
Je ne comprends pas bien cette incompatibilité.
Je vous rassure : moi non plus !
Est le problème du CR/LF
à la fin de chaque ligne de texte ? ou est-ce le Turbo Pascal qui est
incapable d'ouvrir les fichiers en mode binaire ?
J'ouvre en FILE OF BYTE. J'explique en détail le problème sur
fr.comp.lang.pascal sous le post Gros problème (qui résume bien la
situation)... Voyez là-bas pour plus de détails, le forum est plus adapté.
Pourquoi ne pas changer de language de programmation, comme le C ou le
Python qui sont moins dépendants du système utilisé ? (je ne fais pas de
Python mais son apprentissage serait facilité par l'absence de
pointeurs comme en C, ce qui est bon pour un débutant)
Ben oui, c'est une bonne idée. Mais je me débrouille un peu en Pascal,
alors je préfèrerais rester là-dessus. Mais je commence à me mettre au C,
donc je verrais. Mais comme je n'ai absolument aucune notion, c'est plus
pénible (vu que je commencerais d'entrée de jeu avec un programme complexe).
[...] J'essaye de mettre ça en forme avec TURBO PASCAL, mais j'ai des gros problèmes pour programmer (en raison de la compatibilité des fichiers entre MS-DOS et WINDOWS).
Je ne comprends pas bien cette incompatibilité.
Je vous rassure : moi non plus !
Est le problème du CR/LF à la fin de chaque ligne de texte ? ou est-ce le Turbo Pascal qui est incapable d'ouvrir les fichiers en mode binaire ?
J'ouvre en FILE OF BYTE. J'explique en détail le problème sur fr.comp.lang.pascal sous le post Gros problème (qui résume bien la situation)... Voyez là-bas pour plus de détails, le forum est plus adapté.
Pourquoi ne pas changer de language de programmation, comme le C ou le Python qui sont moins dépendants du système utilisé ? (je ne fais pas de Python mais son apprentissage serait facilité par l'absence de pointeurs comme en C, ce qui est bon pour un débutant)
Ben oui, c'est une bonne idée. Mais je me débrouille un peu en Pascal, alors je préfèrerais rester là-dessus. Mais je commence à me mettre au C, donc je verrais. Mais comme je n'ai absolument aucune notion, c'est plus pénible (vu que je commencerais d'entrée de jeu avec un programme complexe).
Bien à vous, Christophe
Michel Arboi
On Thu Aug 12 2004 at 12:18, Horace wrote:
Je n'ai rien contre le fait qu'on me dise que c'est inutile, mais que quelqu'un me dise que c'est inutile sans me dire pourquoi, franchement, je ne trouve pas cela très constructif.
Parce que c'est une opération qui ne change pas, qui est connue, donc que tout le monde peut appliquer.
Donc, même si on a une clef très longue (1024) et qu'on la répète sur un texte complètement brouillé, cela porte préjudice à la sécurité... ?
Oui.
Pourriez-vous expliciter ??
Parce que ça revient grosso modo à un chiffre de Vigenère, qui est cassable assez facilement. Cf. la littérature sur le sujet, par exemple Stinson.
Ben on prend une clef de 16 caractères, on génère une clef de 1024 (peu importe l'algo, c'est une génération de nombre pseudo aléatoire)
Si justement, l'algo importe. Car s'il n'est pas "cryptographiquement sur", on retrouve la "graine" du générateur aléatoire.
Marc aura très bien répondu à cette question...
Alors si c'est pour passer le temps, commencez plutôt par des bons bouquins sur le sujet. Par exemple : "The codebreakers" de Davin Kahn (historique) "Cryptography: theory & practice" de Stinson.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
On Thu Aug 12 2004 at 12:18, Horace wrote:
Je n'ai rien contre le fait qu'on me dise que c'est inutile, mais que
quelqu'un me dise que c'est inutile sans me dire pourquoi, franchement, je
ne trouve pas cela très constructif.
Parce que c'est une opération qui ne change pas, qui est connue, donc
que tout le monde peut appliquer.
Donc, même si on a une clef très longue (1024) et qu'on la répète sur un
texte complètement brouillé, cela porte préjudice à la sécurité... ?
Oui.
Pourriez-vous expliciter ??
Parce que ça revient grosso modo à un chiffre de Vigenère, qui est
cassable assez facilement. Cf. la littérature sur le sujet, par
exemple Stinson.
Ben on prend une clef de 16 caractères, on génère une clef de 1024 (peu
importe l'algo, c'est une génération de nombre pseudo aléatoire)
Si justement, l'algo importe. Car s'il n'est pas "cryptographiquement
sur", on retrouve la "graine" du générateur aléatoire.
Marc aura très bien répondu à cette question...
Alors si c'est pour passer le temps, commencez plutôt par des bons
bouquins sur le sujet. Par exemple :
"The codebreakers" de Davin Kahn (historique)
"Cryptography: theory & practice" de Stinson.
Je n'ai rien contre le fait qu'on me dise que c'est inutile, mais que quelqu'un me dise que c'est inutile sans me dire pourquoi, franchement, je ne trouve pas cela très constructif.
Parce que c'est une opération qui ne change pas, qui est connue, donc que tout le monde peut appliquer.
Donc, même si on a une clef très longue (1024) et qu'on la répète sur un texte complètement brouillé, cela porte préjudice à la sécurité... ?
Oui.
Pourriez-vous expliciter ??
Parce que ça revient grosso modo à un chiffre de Vigenère, qui est cassable assez facilement. Cf. la littérature sur le sujet, par exemple Stinson.
Ben on prend une clef de 16 caractères, on génère une clef de 1024 (peu importe l'algo, c'est une génération de nombre pseudo aléatoire)
Si justement, l'algo importe. Car s'il n'est pas "cryptographiquement sur", on retrouve la "graine" du générateur aléatoire.
Marc aura très bien répondu à cette question...
Alors si c'est pour passer le temps, commencez plutôt par des bons bouquins sur le sujet. Par exemple : "The codebreakers" de Davin Kahn (historique) "Cryptography: theory & practice" de Stinson.
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/
