The world will now reboot. don't bother saving your artefacts.
lheureuxph
Ca c'est un travail que CDP fait très bien voir http://www.superlutin.net/crypto.html Avec CDP , tu peux crypter 1234 des milliers de fois sans obtenir le meme résultat. -- Lheureux Philippe Définition de l'amour : L'amour c'est partager sa joie de vivre avec les autres. http://www.gourou.biz
"Phil l'ancien" a écrit dans le message de news:455e03c6$0$25914$
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié (exemple : 3 valeurs possibles).
Disons par exemple que le texte clair peut seulement être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré, idem pour '2' et '3'.
Il faudrait quelque-chose comme : '1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes du texte chiffré pour un même texte clair.
Connaissez-vous une bonne technique pour faire ça ?
Phil l'ancien-
Ca c'est un travail que CDP fait très bien
voir http://www.superlutin.net/crypto.html
Avec CDP , tu peux crypter 1234 des milliers de fois sans obtenir le meme
résultat.
--
Lheureux Philippe
Définition de l'amour : L'amour c'est partager sa joie de vivre avec les
autres.
http://www.gourou.biz
"Phil l'ancien" <nicetry@noway.com> a écrit dans le message de
news:455e03c6$0$25914$ba4acef3@news.orange.fr...
Je dois chiffrer un texte court (exemple : 1 caractère) et peu
varié (exemple : 3 valeurs possibles).
Disons par exemple que le texte clair peut seulement
être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte
chiffré, idem pour '2' et '3'.
Il faudrait quelque-chose comme :
'1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup
de variantes du texte chiffré pour un même texte clair.
Connaissez-vous une bonne technique pour faire ça ?
Ca c'est un travail que CDP fait très bien voir http://www.superlutin.net/crypto.html Avec CDP , tu peux crypter 1234 des milliers de fois sans obtenir le meme résultat. -- Lheureux Philippe Définition de l'amour : L'amour c'est partager sa joie de vivre avec les autres. http://www.gourou.biz
"Phil l'ancien" a écrit dans le message de news:455e03c6$0$25914$
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié (exemple : 3 valeurs possibles).
Disons par exemple que le texte clair peut seulement être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré, idem pour '2' et '3'.
Il faudrait quelque-chose comme : '1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes du texte chiffré pour un même texte clair.
Connaissez-vous une bonne technique pour faire ça ?
Phil l'ancien-
Christophe HENRY
Le Fri, 17 Nov 2006 19:47:39 +0100, Phil l'ancien a écrit:
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié (exemple : 3 valeurs possibles). Disons par exemple que le texte clair peut seulement être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré, idem pour '2' et '3'.
Il faudrait quelque-chose comme : '1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes du texte chiffré pour un même texte clair.
Tirer un très grand nombre au hasard. Calculer le reste de la division entière par 3 (donc 0, 1 ou 2). Si le reste ne convient pas, ajouter 1 ou 2 au nombre pour arriver au bon modulo. Exemple : 46464647 MOD 3 = 1. Si on avait voulu coder '1', indiqué par un modulo à 0, alors il faut prendre 4646466, soit le même nombre diminué de un.
D'une manière générale, tu peux partir de nombres aléatoires légèrement altérés de sorte à ce qu'une propriété intéressante (précédemment le reste de la division euclidienne) puisse être trouvée par le récepteur. C'est à la mi-chemin entre la stéganographie et la cryptographie. Ça reste artisanal et faible comme chiffrement.
Pourquoi ne pas chiffrer tes messages avec gnupg ou tout autre solution de chiffrement *éprouvé* ? Parce que l'attaquant verrait que les mêmes messages transitent ? Une solution facile est d'ajouter un texte aléatoire au message. À chaque communication le message chiffré est totalement différent. Par contre, le déchiffrement laissera voir la partie aléatoire et la partie pertinente.
a++
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Le Fri, 17 Nov 2006 19:47:39 +0100, Phil l'ancien a écrit:
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié
(exemple : 3 valeurs possibles). Disons par exemple que le texte clair
peut seulement être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré,
idem pour '2' et '3'.
Il faudrait quelque-chose comme :
'1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes
du texte chiffré pour un même texte clair.
Tirer un très grand nombre au hasard. Calculer le reste de la division
entière par 3 (donc 0, 1 ou 2). Si le reste ne convient pas, ajouter 1 ou
2 au nombre pour arriver au bon modulo. Exemple : 46464647 MOD 3 = 1. Si
on avait voulu coder '1', indiqué par un modulo à 0, alors il faut prendre
4646466, soit le même nombre diminué de un.
D'une manière générale, tu peux partir de nombres aléatoires légèrement
altérés de sorte à ce qu'une propriété intéressante (précédemment le reste
de la division euclidienne) puisse être trouvée par le récepteur. C'est à
la mi-chemin entre la stéganographie et la cryptographie. Ça reste
artisanal et faible comme chiffrement.
Pourquoi ne pas chiffrer tes messages avec gnupg ou tout autre solution de
chiffrement *éprouvé* ? Parce que l'attaquant verrait que les mêmes
messages transitent ?
Une solution facile est d'ajouter un texte aléatoire au message. À chaque
communication le message chiffré est totalement différent. Par contre, le
déchiffrement laissera voir la partie aléatoire et la partie pertinente.
a++
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
Le Fri, 17 Nov 2006 19:47:39 +0100, Phil l'ancien a écrit:
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié (exemple : 3 valeurs possibles). Disons par exemple que le texte clair peut seulement être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré, idem pour '2' et '3'.
Il faudrait quelque-chose comme : '1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes du texte chiffré pour un même texte clair.
Tirer un très grand nombre au hasard. Calculer le reste de la division entière par 3 (donc 0, 1 ou 2). Si le reste ne convient pas, ajouter 1 ou 2 au nombre pour arriver au bon modulo. Exemple : 46464647 MOD 3 = 1. Si on avait voulu coder '1', indiqué par un modulo à 0, alors il faut prendre 4646466, soit le même nombre diminué de un.
D'une manière générale, tu peux partir de nombres aléatoires légèrement altérés de sorte à ce qu'une propriété intéressante (précédemment le reste de la division euclidienne) puisse être trouvée par le récepteur. C'est à la mi-chemin entre la stéganographie et la cryptographie. Ça reste artisanal et faible comme chiffrement.
Pourquoi ne pas chiffrer tes messages avec gnupg ou tout autre solution de chiffrement *éprouvé* ? Parce que l'attaquant verrait que les mêmes messages transitent ? Une solution facile est d'ajouter un texte aléatoire au message. À chaque communication le message chiffré est totalement différent. Par contre, le déchiffrement laissera voir la partie aléatoire et la partie pertinente.
a++
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Phil l'ancien
Christophe HENRY
Phil l'ancien
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié (exemple : 3 valeurs possibles). Disons par exemple que le texte clair peut seulement être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré, idem pour '2' et '3'.
Il faudrait quelque-chose comme : '1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes du texte chiffré pour un même texte clair.
Tirer un très grand nombre au hasard. Calculer le reste de la division entière par 3 (donc 0, 1 ou 2). Si le reste ne convient pas, ajouter 1 ou 2 au nombre pour arriver au bon modulo. Exemple : 46464647 MOD 3 = 1. Si on avait voulu coder '1', indiqué par un modulo à 0, alors il faut prendre 4646466, soit le même nombre diminué de un.
D'une manière générale, tu peux partir de nombres aléatoires légèrement altérés de sorte à ce qu'une propriété intéressante (précédemment le reste de la division euclidienne) puisse être trouvée par le récepteur. C'est à la mi-chemin entre la stéganographie et la cryptographie. Ça reste artisanal et faible comme chiffrement.
Oui, comme les textes clairs sont peu variés, un attaquant qui disposerait de suffisemment de textes chiffrés découvrirait la régularité arithmétique (d'autant plus que c'est une application où on peut assez facilement obtenir l'information par ailleurs.)
Pourquoi ne pas chiffrer tes messages avec gnupg ou tout autre solution de chiffrement *éprouvé* ? Parce que l'attaquant verrait que les mêmes messages transitent ? Une solution facile est d'ajouter un texte aléatoire au message. À chaque communication le message chiffré est totalement différent. Par contre, le déchiffrement laissera voir la partie aléatoire et la partie pertinente.
D'accord avec toi, c'est ça qu'il faut faire. Il me semble que les algorithmes éprouvés (DES et 'au dessus') produisent un texte chiffré d'au moins 64 bits. C'est juste ?
Phil l'ancien-
Christophe HENRY
Phil l'ancien
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié
(exemple : 3 valeurs possibles). Disons par exemple que le texte clair
peut seulement être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré,
idem pour '2' et '3'.
Il faudrait quelque-chose comme :
'1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes
du texte chiffré pour un même texte clair.
Tirer un très grand nombre au hasard. Calculer le reste de la division
entière par 3 (donc 0, 1 ou 2). Si le reste ne convient pas, ajouter 1 ou
2 au nombre pour arriver au bon modulo. Exemple : 46464647 MOD 3 = 1. Si
on avait voulu coder '1', indiqué par un modulo à 0, alors il faut prendre
4646466, soit le même nombre diminué de un.
D'une manière générale, tu peux partir de nombres aléatoires légèrement
altérés de sorte à ce qu'une propriété intéressante (précédemment le reste
de la division euclidienne) puisse être trouvée par le récepteur. C'est à
la mi-chemin entre la stéganographie et la cryptographie. Ça reste
artisanal et faible comme chiffrement.
Oui, comme les textes clairs sont peu variés, un attaquant
qui disposerait de suffisemment de textes chiffrés découvrirait
la régularité arithmétique (d'autant plus que c'est une application
où on peut assez facilement obtenir l'information par ailleurs.)
Pourquoi ne pas chiffrer tes messages avec gnupg ou tout autre solution de
chiffrement *éprouvé* ? Parce que l'attaquant verrait que les mêmes
messages transitent ?
Une solution facile est d'ajouter un texte aléatoire au message. À chaque
communication le message chiffré est totalement différent. Par contre, le
déchiffrement laissera voir la partie aléatoire et la partie pertinente.
D'accord avec toi, c'est ça qu'il faut faire.
Il me semble que les algorithmes éprouvés (DES et 'au dessus')
produisent un texte chiffré d'au moins 64 bits. C'est juste ?
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié (exemple : 3 valeurs possibles). Disons par exemple que le texte clair peut seulement être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré, idem pour '2' et '3'.
Il faudrait quelque-chose comme : '1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes du texte chiffré pour un même texte clair.
Tirer un très grand nombre au hasard. Calculer le reste de la division entière par 3 (donc 0, 1 ou 2). Si le reste ne convient pas, ajouter 1 ou 2 au nombre pour arriver au bon modulo. Exemple : 46464647 MOD 3 = 1. Si on avait voulu coder '1', indiqué par un modulo à 0, alors il faut prendre 4646466, soit le même nombre diminué de un.
D'une manière générale, tu peux partir de nombres aléatoires légèrement altérés de sorte à ce qu'une propriété intéressante (précédemment le reste de la division euclidienne) puisse être trouvée par le récepteur. C'est à la mi-chemin entre la stéganographie et la cryptographie. Ça reste artisanal et faible comme chiffrement.
Oui, comme les textes clairs sont peu variés, un attaquant qui disposerait de suffisemment de textes chiffrés découvrirait la régularité arithmétique (d'autant plus que c'est une application où on peut assez facilement obtenir l'information par ailleurs.)
Pourquoi ne pas chiffrer tes messages avec gnupg ou tout autre solution de chiffrement *éprouvé* ? Parce que l'attaquant verrait que les mêmes messages transitent ? Une solution facile est d'ajouter un texte aléatoire au message. À chaque communication le message chiffré est totalement différent. Par contre, le déchiffrement laissera voir la partie aléatoire et la partie pertinente.
D'accord avec toi, c'est ça qu'il faut faire. Il me semble que les algorithmes éprouvés (DES et 'au dessus') produisent un texte chiffré d'au moins 64 bits. C'est juste ?
Phil l'ancien-
Phil l'ancien
lheureuxph
Phil l'ancien
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié (exemple : 3 valeurs possibles). Disons par exemple que le texte clair peut seulement être : '1' , '2' ou '3'. Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré, idem pour '2' et '3'. Il faudrait quelque-chose comme : '1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes du texte chiffré pour un même texte clair.
Connaissez-vous une bonne technique pour faire ça ?
Ca c'est un travail que CDP fait très bien voir http://www.superlutin.net/crypto.html Avec CDP , tu peux crypter 1234 des milliers de fois sans obtenir le meme résultat.
Joli ton algorithme, et on pourrait l'utiliser même pour des clairs peu variés et courts, en ajoutant du texte aléatoire. Est-ce qu'il a été mis à "l'épreuve du feu" ?
Phil l'ancien-
lheureuxph
Phil l'ancien
Je dois chiffrer un texte court (exemple : 1 caractère) et peu
varié (exemple : 3 valeurs possibles).
Disons par exemple que le texte clair peut seulement
être : '1' , '2' ou '3'.
Bien sûr, il ne faut pas que '1' donne toujours le même texte
chiffré, idem pour '2' et '3'.
Il faudrait quelque-chose comme :
'1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup
de variantes du texte chiffré pour un même texte clair.
Connaissez-vous une bonne technique pour faire ça ?
Ca c'est un travail que CDP fait très bien
voir http://www.superlutin.net/crypto.html
Avec CDP , tu peux crypter 1234 des milliers de fois sans obtenir
le meme résultat.
Joli ton algorithme, et on pourrait l'utiliser même
pour des clairs peu variés et courts, en ajoutant
du texte aléatoire.
Est-ce qu'il a été mis à "l'épreuve du feu" ?
Je dois chiffrer un texte court (exemple : 1 caractère) et peu varié (exemple : 3 valeurs possibles). Disons par exemple que le texte clair peut seulement être : '1' , '2' ou '3'. Bien sûr, il ne faut pas que '1' donne toujours le même texte chiffré, idem pour '2' et '3'. Il faudrait quelque-chose comme : '1' -> 'AZ23' ou 'SQF1' ou 'LKS9' ou.... etc, avec beaucoup de variantes du texte chiffré pour un même texte clair.
Connaissez-vous une bonne technique pour faire ça ?
Ca c'est un travail que CDP fait très bien voir http://www.superlutin.net/crypto.html Avec CDP , tu peux crypter 1234 des milliers de fois sans obtenir le meme résultat.
Joli ton algorithme, et on pourrait l'utiliser même pour des clairs peu variés et courts, en ajoutant du texte aléatoire. Est-ce qu'il a été mis à "l'épreuve du feu" ?
Phil l'ancien-
Christophe HENRY
Le Wed, 22 Nov 2006 01:37:44 +0100, Phil l'ancien a écrit:
Pourquoi ne pas chiffrer tes messages avec gnupg ou tout autre solution de chiffrement *éprouvé* ? Parce que l'attaquant verrait que les mêmes messages transitent ? Une solution facile est d'ajouter un texte aléatoire au message. À chaque communication le message chiffré est totalement différent. Par contre, le déchiffrement laissera voir la partie aléatoire et la partie pertinente.
D'accord avec toi, c'est ça qu'il faut faire. Il me semble que les algorithmes éprouvés (DES et 'au dessus') produisent un texte chiffré d'au moins 64 bits. C'est juste ?
Peu importe la taille puisqu'elle dépendra aussi de la taille de l'élément aléatoire.
Des algorithmes forts et éprouvés sont disponibles gratuitement et, surtout, librement. Préfère ceux dont l'algorithme est connu et dont il existe une implémentation libre. Gnupg est capable d'utiliser du triple des, entre autres.
Fuit comme la peste les programmes propriétaires ou les algorithmes déjà cassés. Certains l'ont même été ici, il suffit de regarder les archives de ce groupe.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Le Wed, 22 Nov 2006 01:37:44 +0100, Phil l'ancien a écrit:
Pourquoi ne pas chiffrer tes messages avec gnupg ou tout autre solution de
chiffrement *éprouvé* ? Parce que l'attaquant verrait que les mêmes
messages transitent ?
Une solution facile est d'ajouter un texte aléatoire au message. À chaque
communication le message chiffré est totalement différent. Par contre, le
déchiffrement laissera voir la partie aléatoire et la partie pertinente.
D'accord avec toi, c'est ça qu'il faut faire.
Il me semble que les algorithmes éprouvés (DES et 'au dessus')
produisent un texte chiffré d'au moins 64 bits. C'est juste ?
Peu importe la taille puisqu'elle dépendra aussi de la taille de l'élément
aléatoire.
Des algorithmes forts et éprouvés sont disponibles gratuitement et,
surtout, librement. Préfère ceux dont l'algorithme est connu et dont il
existe une implémentation libre.
Gnupg est capable d'utiliser du triple des, entre autres.
Fuit comme la peste les programmes propriétaires ou les algorithmes déjà
cassés. Certains l'ont même été ici, il suffit de regarder les archives de
ce groupe.
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
Le Wed, 22 Nov 2006 01:37:44 +0100, Phil l'ancien a écrit:
Pourquoi ne pas chiffrer tes messages avec gnupg ou tout autre solution de chiffrement *éprouvé* ? Parce que l'attaquant verrait que les mêmes messages transitent ? Une solution facile est d'ajouter un texte aléatoire au message. À chaque communication le message chiffré est totalement différent. Par contre, le déchiffrement laissera voir la partie aléatoire et la partie pertinente.
D'accord avec toi, c'est ça qu'il faut faire. Il me semble que les algorithmes éprouvés (DES et 'au dessus') produisent un texte chiffré d'au moins 64 bits. C'est juste ?
Peu importe la taille puisqu'elle dépendra aussi de la taille de l'élément aléatoire.
Des algorithmes forts et éprouvés sont disponibles gratuitement et, surtout, librement. Préfère ceux dont l'algorithme est connu et dont il existe une implémentation libre. Gnupg est capable d'utiliser du triple des, entre autres.
Fuit comme la peste les programmes propriétaires ou les algorithmes déjà cassés. Certains l'ont même été ici, il suffit de regarder les archives de ce groupe.
-- Christophe HENRY http://www.sbgodin.fr - Site perso
lheureuxph
Joli ton algorithme, et on pourrait l'utiliser même pour des clairs peu variés et courts, en ajoutant du texte aléatoire. Est-ce qu'il a été mis à "l'épreuve du feu" ?
Phil l'ancien-
Disons que CDP a fait parler de lui :-) si tu fais une recherche sur CDP+lheureux tu pourras constater qu'il y aurait eu de quoi écrire 10 livres !
Joli ton algorithme, et on pourrait l'utiliser même
pour des clairs peu variés et courts, en ajoutant
du texte aléatoire.
Est-ce qu'il a été mis à "l'épreuve du feu" ?
Phil l'ancien-
Disons que CDP a fait parler de lui :-) si tu fais une recherche sur
CDP+lheureux tu pourras constater qu'il y aurait eu de quoi écrire 10 livres
!
Joli ton algorithme, et on pourrait l'utiliser même pour des clairs peu variés et courts, en ajoutant du texte aléatoire. Est-ce qu'il a été mis à "l'épreuve du feu" ?
Phil l'ancien-
Disons que CDP a fait parler de lui :-) si tu fais une recherche sur CDP+lheureux tu pourras constater qu'il y aurait eu de quoi écrire 10 livres !
Christophe HENRY
Le Wed, 22 Nov 2006 21:23:16 +0100, Phil l'ancien a écrit:
Peu importe la taille puisqu'elle dépendra aussi de la taille de l'élément aléatoire.
Non, car dans l'application le texte chiffré doit pouvoir être saisi facilement. Un algorithme qui impose que le texte chiffré soit d'au moins 64 bits conduirait à la saisie d'environ 13 caractères (si on se cantonne aux lettres et chiffres en ignorant les majuscules/minuscules, on arrive à 5 bits par caractère saisi).
Ah d'accord. Forcément :-o
Dans ce cas, tire aléatoirement plein de textes chiffrés et stocke un gros tableau associant aléatoirement le texte chiffré vers le texte clair.
L'idéal serait de pouvoir connaître pour chaque texte chiffré le nombre correspondant sans devoir stocker ce tableau. Le tableau, ou l'algorithme de correspondance, est en fait la clé de chiffrement. Il faut la transmettre d'une manière ou d'une autre.
Ce ne serait pas pour une clé d'activation de logiciel, par hasard ?
-- Christophe HENRY http://www.sbgodin.fr - Site perso
Le Wed, 22 Nov 2006 21:23:16 +0100, Phil l'ancien a écrit:
Peu importe la taille puisqu'elle dépendra aussi de la taille de l'élément
aléatoire.
Non, car dans l'application le texte chiffré doit pouvoir
être saisi facilement.
Un algorithme qui impose que le texte chiffré soit d'au moins
64 bits conduirait à la saisie d'environ 13 caractères
(si on se cantonne aux lettres et chiffres en ignorant
les majuscules/minuscules, on arrive à 5 bits par
caractère saisi).
Ah d'accord. Forcément :-o
Dans ce cas, tire aléatoirement plein de textes chiffrés et stocke un gros
tableau associant aléatoirement le texte chiffré vers le texte clair.
L'idéal serait de pouvoir connaître pour chaque texte chiffré le nombre
correspondant sans devoir stocker ce tableau. Le tableau, ou l'algorithme
de correspondance, est en fait la clé de chiffrement. Il faut la
transmettre d'une manière ou d'une autre.
Ce ne serait pas pour une clé d'activation de logiciel, par hasard ?
--
Christophe HENRY
http://www.sbgodin.fr - Site perso
Le Wed, 22 Nov 2006 21:23:16 +0100, Phil l'ancien a écrit:
Peu importe la taille puisqu'elle dépendra aussi de la taille de l'élément aléatoire.
Non, car dans l'application le texte chiffré doit pouvoir être saisi facilement. Un algorithme qui impose que le texte chiffré soit d'au moins 64 bits conduirait à la saisie d'environ 13 caractères (si on se cantonne aux lettres et chiffres en ignorant les majuscules/minuscules, on arrive à 5 bits par caractère saisi).
Ah d'accord. Forcément :-o
Dans ce cas, tire aléatoirement plein de textes chiffrés et stocke un gros tableau associant aléatoirement le texte chiffré vers le texte clair.
L'idéal serait de pouvoir connaître pour chaque texte chiffré le nombre correspondant sans devoir stocker ce tableau. Le tableau, ou l'algorithme de correspondance, est en fait la clé de chiffrement. Il faut la transmettre d'une manière ou d'une autre.
Ce ne serait pas pour une clé d'activation de logiciel, par hasard ?
-- Christophe HENRY http://www.sbgodin.fr - Site perso
