On prend un exemple. Une main innocente, a codé avec AllCrypter un court
texte. Un mot. Le fichier fait 38 octets de
long. Le bandeau publicitaire fait 21 octets. 38-21 = 17. Nous avons le
séparateur 31 31. Reste 15. Je lui ai demandé
d'utiliser une clé de 4 caractères. Cela nous fait 8 octets. Reste 7. Le mot
fait 7 caractères de long.
Après le séparateur 31 31, nous avon les 8 octets suivants : D8 AD B4 8F 9E
C1 C2 DF
Entrons cette clé (en fait, si vous lisez le fichier ouch ci-dessus, on ne
fournit que les 7 premiers octets) dans le logiciel somptueusement écrit
suivant :
if ( 0 == strcmp(keyTemp,keyToFind) )
{
printf("\ntatatata tataaaaa! found! key = %s",key);
i = j = k = p = 'z';
}
}
}
}
}
while ( !_kbhit() ) ;
}
[ fin code crado ]
Le programme affiche alors : "tatatata tataaaaa! found! key = zobi".
L'angoisse et l'émotion aux tripes je saisi "zobi" dans AllCrypter et des
congratulations sincères me sont données. J'ouvre le fichier décrypté et
apparaît le mot "bonjour". Renseignement pris auprès de l'innocente main,
c'est bon.
Alors voilà, si quelqu'un d'autre veux bien insister auprès de notre ami,
parce que j'ai l'impression qu'il ne comprends pas :-(.
La prochaine fois, je parierai 1.000 USD...
Voilà, fin du tribute à Guillermito. On est avec toi gars !
Si on est déjà à un niveau 100% "sécuritaire" avec la version actuelle, pourquoi changer l'algo et créer une version 3 ? Pour atteindre un niveau "sécuritaire" de 120% ?
C'est comme la lessive qui lave plus blanc que blanc. Il va nous inventer le code indéchiffrable, même avec la clé.
-- Le Vengeur Masqué se vengera ! http://vm666.dotnode.com/ http://vm666.free.fr/
On Sun Dec 05 2004 at 12:09, Nicob wrote:
Si on est déjà à un niveau 100% "sécuritaire" avec la version actuelle,
pourquoi changer l'algo et créer une version 3 ? Pour atteindre un
niveau "sécuritaire" de 120% ?
C'est comme la lessive qui lave plus blanc que blanc. Il va nous
inventer le code indéchiffrable, même avec la clé.
--
Le Vengeur Masqué se vengera !
http://vm666.dotnode.com/ http://vm666.free.fr/
Si on est déjà à un niveau 100% "sécuritaire" avec la version actuelle, pourquoi changer l'algo et créer une version 3 ? Pour atteindre un niveau "sécuritaire" de 120% ?
C'est comme la lessive qui lave plus blanc que blanc. Il va nous inventer le code indéchiffrable, même avec la clé.
-- Le Vengeur Masqué se vengera ! http://vm666.dotnode.com/ http://vm666.free.fr/
Apokrif
Vengeur Masqué :
Allez donc lire divers grimoires comme "The code breaker"
Vous devez parler de _Codebreakers_ de Kahn, paru en français (dans une version largement expurgée, m'a-t-on dit) sous les titre _La guerre des codes secrets_. Le Que sais-je ? sur le décryptement est intéressant mais, par rapport aux méthodes actuelles, aussi dépassé que celui sur "les écritures secrètes".
-- `cat ~/.signature`
Vengeur Masqué :
Allez donc lire divers grimoires comme "The code breaker"
Vous devez parler de _Codebreakers_ de Kahn, paru en français (dans
une version largement expurgée, m'a-t-on dit) sous les titre _La
guerre des codes secrets_. Le Que sais-je ? sur le décryptement est
intéressant mais, par rapport aux méthodes actuelles, aussi dépassé
que celui sur "les écritures secrètes".
Allez donc lire divers grimoires comme "The code breaker"
Vous devez parler de _Codebreakers_ de Kahn, paru en français (dans une version largement expurgée, m'a-t-on dit) sous les titre _La guerre des codes secrets_. Le Que sais-je ? sur le décryptement est intéressant mais, par rapport aux méthodes actuelles, aussi dépassé que celui sur "les écritures secrètes".
-- `cat ~/.signature`
Apokrif
Raymond H. :
Présentement le calcul effectué pour crypter la clef est assez simple. Mais on sait que ce n'est pas la quantité de calcul qui fait qu'un cryptage est d'une bonne qualité mais la logique utilisée. Et j'en convient qu'en regardant les changements d'octets effectués lors d'un cryptage ne sont pas toujours important à l'oeil. Cela dépend de la clef: si elle contient des caractères semblables on y voit moins de changements au niveau des octets que si les caractères sont tous différents. Mais dans la version 3.0, ces changements au niveau visuel seront complètement différents puisque ce ne sera pas la clef elle-même qui sera intégrée dans le cryptogramme.
Les résultats du chiffrement devraient être *complètement* différents (c'est une condition nécessaire, pas suffisante).
http://en.wikipedia.org/wiki/Avalanche_effect
-- `cat ~/.signature`
Raymond H. :
Présentement le calcul effectué pour crypter la clef est assez
simple. Mais on sait que ce n'est pas la quantité de calcul qui
fait qu'un cryptage est d'une bonne qualité mais la logique
utilisée. Et j'en convient qu'en regardant les changements d'octets
effectués lors d'un cryptage ne sont pas toujours important à
l'oeil. Cela dépend de la clef: si elle contient des caractères
semblables on y voit moins de changements au niveau des octets que
si les caractères sont tous différents. Mais dans la version 3.0,
ces changements au niveau visuel seront complètement différents
puisque ce ne sera pas la clef elle-même qui sera intégrée dans le
cryptogramme.
Les résultats du chiffrement devraient être *complètement* différents
(c'est une condition nécessaire, pas suffisante).
Présentement le calcul effectué pour crypter la clef est assez simple. Mais on sait que ce n'est pas la quantité de calcul qui fait qu'un cryptage est d'une bonne qualité mais la logique utilisée. Et j'en convient qu'en regardant les changements d'octets effectués lors d'un cryptage ne sont pas toujours important à l'oeil. Cela dépend de la clef: si elle contient des caractères semblables on y voit moins de changements au niveau des octets que si les caractères sont tous différents. Mais dans la version 3.0, ces changements au niveau visuel seront complètement différents puisque ce ne sera pas la clef elle-même qui sera intégrée dans le cryptogramme.
Les résultats du chiffrement devraient être *complètement* différents (c'est une condition nécessaire, pas suffisante).
http://en.wikipedia.org/wiki/Avalanche_effect
-- `cat ~/.signature`
Erwann ABALEA
Bonjour,
On Sun, 5 Dec 2004, Raymond H. wrote:
"Erwann ABALEA" a écrit dans le message de news:
Bonsoir,
On Sat, 4 Dec 2004, Raymond H. wrote:
Il n'y a pas de problème là-dessus, car une des raisons de ce forum est de donner son appréciation sur des logiciels de cryptage. Je vous remercie donc de prendre du temps pour éprouver mon logiciel. Je remercie également tous ceux et celles qui ont fait de même. Et je tiens quand même compte de vos analyses et de vos commentaires et je suis prêt à faire des changements si cela s'avérerait nécessaire (exemple dans la version 3.0).
En chiffrant un clair d'une certaine taille ne contenant par exemple que des '0', je me suis rendu compte que quelle que soit la taille de la clé, il apparaissait dans le chiffré des patterns de 256 octets.
Bonjour, j'ai essayé aussi avec d'autres clefs mais n'ayant que des zéro (0) à chiffrer, et effectivement on voit souvent certains patterns revenir même si quelques fois il sont légèrement différents.
J'ai chiffré un fichier de 10M rempli de 0x00 avec une clé composée de 128 '0' (0x30), j'obtiens après 5 mn un fichier qui contient des blocs de 4k identiques (strictement identiques, à moins que vous n'ayez réussi à produire des collisions MD5). J'ai 816 blocs de 4k qui apparaissent en double, et 309 blocs qui apparaissent en triple (et un dernier bloc tout seul, le dernier, parce que le dernier caractère du clair semble être chiffré légèrement diféremment des autres). Je n'ai pas encore compté les distances qui séparent 2 blocs identiques, mais je suis presque sûr que cette distance est constante. Ces redondances ne vous gènent pas? Vraiment pas?
L'hypothèse selon laquelle la clé qui est saisie est transformée en interne en un bloc de 256 octets, et que c'est ce bloc de 256 octets dérivé de la clé qui servira à faire le chiffrement est-elle vraie?
Non, la clef n'est pas transformée en bloc de 256 octets avant le cryptage mais ses caractères sont permutés, doublés puis permutés de nouveau; ensuite le cryptage/décryptage se fait à partir de là. Mais la
Et j'ai écrit quoi de différent?
lecture d'un fichier se fait par paquet de 2250000 octets à la fois et ces 2250000 octets sont cryptés ou décrypté par sous paquet qui font plus d'un Ko chacun.
On pourrait croire que ça va plus vite d'utiliser de gros buffers, mais non. Est-ce la faute du langage choisi (VB), ou de la qualité du programmeur? Sur la machine d'à côté, le même fichier chiffré en AES128 n'a demandé que 2,4 seconde de traitement, sur une machine plus lente.
Par contre l'idée que vous amenez ressemble à ce que je prévois faire dans la version 3.0. et que l'on peut lire dans l'historique des versions
Hopopopop! Avant de se jeter sur son clavier, il *faut* prendre un bout de papier et un crayon, et s'équiper de neurones en état de fonctionnement. Voudriez-vous aller voir sur http://www.cacr.math.uwaterloo.ca/hac/ et télécharger le chapitre 6 et le lire, *avant* de pondre votre version 3.0 qui ne sera certainement pas plus robuste?
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Manuals out, after all possible keystrokes have failed.
Bonjour,
On Sun, 5 Dec 2004, Raymond H. wrote:
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
Pine.LNX.4.58.0412050245050.17170@shining.seclogd.org...
Bonsoir,
On Sat, 4 Dec 2004, Raymond H. wrote:
Il n'y a pas de problème là-dessus, car une des raisons de ce forum
est
de donner son appréciation sur des logiciels de cryptage. Je vous
remercie
donc de prendre du temps pour éprouver mon logiciel. Je remercie
également
tous ceux et celles qui ont fait de même. Et je tiens quand même compte
de
vos analyses et de vos commentaires et je suis prêt à faire des
changements
si cela s'avérerait nécessaire (exemple dans la version 3.0).
En chiffrant un clair d'une certaine taille ne contenant par exemple que
des '0', je me suis rendu compte que quelle que soit la taille de la clé,
il apparaissait dans le chiffré des patterns de 256 octets.
Bonjour,
j'ai essayé aussi avec d'autres clefs mais n'ayant que des zéro (0) à
chiffrer, et effectivement on voit souvent certains patterns revenir même si
quelques fois il sont légèrement différents.
J'ai chiffré un fichier de 10M rempli de 0x00 avec une clé composée de 128
'0' (0x30), j'obtiens après 5 mn un fichier qui contient des blocs de 4k
identiques (strictement identiques, à moins que vous n'ayez réussi à
produire des collisions MD5). J'ai 816 blocs de 4k qui apparaissent en
double, et 309 blocs qui apparaissent en triple (et un dernier bloc tout
seul, le dernier, parce que le dernier caractère du clair semble être
chiffré légèrement diféremment des autres). Je n'ai pas encore compté les
distances qui séparent 2 blocs identiques, mais je suis presque sûr que
cette distance est constante. Ces redondances ne vous gènent pas? Vraiment
pas?
L'hypothèse selon laquelle la clé qui est saisie est transformée en
interne en un bloc de 256 octets, et que c'est ce bloc de 256 octets
dérivé de la clé qui servira à faire le chiffrement est-elle vraie?
Non, la clef n'est pas transformée en bloc de 256 octets avant le
cryptage mais ses caractères sont permutés, doublés puis permutés de
nouveau; ensuite le cryptage/décryptage se fait à partir de là. Mais la
Et j'ai écrit quoi de différent?
lecture d'un fichier se fait par paquet de 2250000 octets à la fois et ces
2250000 octets sont cryptés ou décrypté par sous paquet qui font plus d'un
Ko chacun.
On pourrait croire que ça va plus vite d'utiliser de gros buffers, mais
non. Est-ce la faute du langage choisi (VB), ou de la qualité du
programmeur? Sur la machine d'à côté, le même fichier chiffré en AES128
n'a demandé que 2,4 seconde de traitement, sur une machine plus lente.
Par contre l'idée que vous amenez ressemble à ce que je prévois faire
dans la version 3.0. et que l'on peut lire dans l'historique des versions
Hopopopop! Avant de se jeter sur son clavier, il *faut* prendre un bout de
papier et un crayon, et s'équiper de neurones en état de fonctionnement.
Voudriez-vous aller voir sur http://www.cacr.math.uwaterloo.ca/hac/ et
télécharger le chapitre 6 et le lire, *avant* de pondre votre version 3.0
qui ne sera certainement pas plus robuste?
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Manuals out, after all possible keystrokes have failed.
Il n'y a pas de problème là-dessus, car une des raisons de ce forum est de donner son appréciation sur des logiciels de cryptage. Je vous remercie donc de prendre du temps pour éprouver mon logiciel. Je remercie également tous ceux et celles qui ont fait de même. Et je tiens quand même compte de vos analyses et de vos commentaires et je suis prêt à faire des changements si cela s'avérerait nécessaire (exemple dans la version 3.0).
En chiffrant un clair d'une certaine taille ne contenant par exemple que des '0', je me suis rendu compte que quelle que soit la taille de la clé, il apparaissait dans le chiffré des patterns de 256 octets.
Bonjour, j'ai essayé aussi avec d'autres clefs mais n'ayant que des zéro (0) à chiffrer, et effectivement on voit souvent certains patterns revenir même si quelques fois il sont légèrement différents.
J'ai chiffré un fichier de 10M rempli de 0x00 avec une clé composée de 128 '0' (0x30), j'obtiens après 5 mn un fichier qui contient des blocs de 4k identiques (strictement identiques, à moins que vous n'ayez réussi à produire des collisions MD5). J'ai 816 blocs de 4k qui apparaissent en double, et 309 blocs qui apparaissent en triple (et un dernier bloc tout seul, le dernier, parce que le dernier caractère du clair semble être chiffré légèrement diféremment des autres). Je n'ai pas encore compté les distances qui séparent 2 blocs identiques, mais je suis presque sûr que cette distance est constante. Ces redondances ne vous gènent pas? Vraiment pas?
L'hypothèse selon laquelle la clé qui est saisie est transformée en interne en un bloc de 256 octets, et que c'est ce bloc de 256 octets dérivé de la clé qui servira à faire le chiffrement est-elle vraie?
Non, la clef n'est pas transformée en bloc de 256 octets avant le cryptage mais ses caractères sont permutés, doublés puis permutés de nouveau; ensuite le cryptage/décryptage se fait à partir de là. Mais la
Et j'ai écrit quoi de différent?
lecture d'un fichier se fait par paquet de 2250000 octets à la fois et ces 2250000 octets sont cryptés ou décrypté par sous paquet qui font plus d'un Ko chacun.
On pourrait croire que ça va plus vite d'utiliser de gros buffers, mais non. Est-ce la faute du langage choisi (VB), ou de la qualité du programmeur? Sur la machine d'à côté, le même fichier chiffré en AES128 n'a demandé que 2,4 seconde de traitement, sur une machine plus lente.
Par contre l'idée que vous amenez ressemble à ce que je prévois faire dans la version 3.0. et que l'on peut lire dans l'historique des versions
Hopopopop! Avant de se jeter sur son clavier, il *faut* prendre un bout de papier et un crayon, et s'équiper de neurones en état de fonctionnement. Voudriez-vous aller voir sur http://www.cacr.math.uwaterloo.ca/hac/ et télécharger le chapitre 6 et le lire, *avant* de pondre votre version 3.0 qui ne sera certainement pas plus robuste?
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Manuals out, after all possible keystrokes have failed.
Raymond H.
"Erwann ABALEA" a écrit dans le message de news:
Bonjour,
On Sun, 5 Dec 2004, Raymond H. wrote:
"Erwann ABALEA" a écrit dans le message de news:
Bonsoir,
On Sat, 4 Dec 2004, Raymond H. wrote:
Il n'y a pas de problème là-dessus, car une des raisons de ce forum est de donner son appréciation sur des logiciels de cryptage. Je vous remercie donc de prendre du temps pour éprouver mon logiciel. Je remercie également tous ceux et celles qui ont fait de même. Et je tiens quand même compte de vos analyses et de vos commentaires et je suis prêt à faire des changements si cela s'avérerait nécessaire (exemple dans la version 3.0).
En chiffrant un clair d'une certaine taille ne contenant par exemple que des '0', je me suis rendu compte que quelle que soit la taille de la clé, il apparaissait dans le chiffré des patterns de 256 octets.
Bonjour, j'ai essayé aussi avec d'autres clefs mais n'ayant que des zéro (0) à chiffrer, et effectivement on voit souvent certains patterns revenir même si quelques fois il sont légèrement différents.
J'ai chiffré un fichier de 10M rempli de 0x00 avec une clé composée de 128 '0' (0x30), j'obtiens après 5 mn un fichier qui contient des blocs de 4k identiques (strictement identiques, à moins que vous n'ayez réussi à produire des collisions MD5).
Bonjour,
sur ma machine P4 (Pentium 2.4Go) le cryptage/décryptage prend environ 6 à 7 secondes pour chaque Mo, donc environ 1 minutes pour un fichier de 10Mo. AllCrypter ne crypte pas des block de 4 ko même s'il semble que les patterns se répète à cet intervalle; cela est dû aux calculs effectués qui, dépendant des valeurs de chaque caractère calculé, fait qu'un même cycle recommence vu que les octets que vous mettez pour être chiffré sont tous identiques. Mais les blocks se font toujours avec un certain maximum de caractères: autour de 2ko.
J'ai 816 blocs de 4k qui apparaissent en double, et 309 blocs qui apparaissent en triple (et un dernier bloc tout seul, le dernier, parce que le dernier caractère du clair semble être chiffré légèrement diféremment des autres). Je n'ai pas encore compté les distances qui séparent 2 blocs identiques, mais je suis presque sûr que cette distance est constante. Ces redondances ne vous gènent pas? Vraiment pas?
Absolument pas puisque cela ne correspond pas à la taille des blocks traités :)
L'hypothèse selon laquelle la clé qui est saisie est transformée en interne en un bloc de 256 octets, et que c'est ce bloc de 256 octets dérivé de la clé qui servira à faire le chiffrement est-elle vraie?
Non, la clef n'est pas transformée en bloc de 256 octets avant le cryptage mais ses caractères sont permutés, doublés puis permutés de nouveau; ensuite le cryptage/décryptage se fait à partir de là. Mais la
Et j'ai écrit quoi de différent?
Dépendant des valeurs utilisées dans les calculs cela peut donner des intervalles de répétition différents, non que la taille des blocks change mais que le cycle du résultat de calcul change, et cela dépend des valeurs traitées.
lecture d'un fichier se fait par paquet de 2250000 octets à la fois et ces 2250000 octets sont cryptés ou décrypté par sous paquet qui font plus d'un Ko chacun.
On pourrait croire que ça va plus vite d'utiliser de gros buffers, mais non. Est-ce la faute du langage choisi (VB), ou de la qualité du programmeur? Sur la machine d'à côté, le même fichier chiffré en AES128 n'a demandé que 2,4 seconde de traitement, sur une machine plus lente.
Disons que le langage de programmation est différent. Ici on est en vb. Mais un des objectifs futur est d'y créer un dll écrite en C afin qu'AllCrypter y fasse appel afin que la procédure d'encryptage/décryptage se fasse de cette manière plutôt, afin d'augmenter sa vitesse de traitement. Et concernant la taille des blocks à utiliser cela dépend du langage. Ici j'ai choisi une taille qui donne le meilleur rendement de vitesse au sein de la procédure qui exécute le cryptage/décryptage. Des tests ont été faits pour prendre la taille qui donne le meilleur rendement de vitesse.
Par contre l'idée que vous amenez ressemble à ce que je prévois faire dans la version 3.0. et que l'on peut lire dans l'historique des versions
Hopopopop! Avant de se jeter sur son clavier, il *faut* prendre un bout de papier et un crayon, et s'équiper de neurones en état de fonctionnement. Voudriez-vous aller voir sur http://www.cacr.math.uwaterloo.ca/hac/ et télécharger le chapitre 6 et le lire, *avant* de pondre votre version 3.0 qui ne sera certainement pas plus robuste?
Réponse plus haut. a+ r.h.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Manuals out, after all possible keystrokes have failed.
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
Pine.LNX.4.58.0412051516240.21931@shining.seclogd.org...
Bonjour,
On Sun, 5 Dec 2004, Raymond H. wrote:
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
Pine.LNX.4.58.0412050245050.17170@shining.seclogd.org...
Bonsoir,
On Sat, 4 Dec 2004, Raymond H. wrote:
Il n'y a pas de problème là-dessus, car une des raisons de ce
forum
est
de donner son appréciation sur des logiciels de cryptage. Je vous
remercie
donc de prendre du temps pour éprouver mon logiciel. Je remercie
également
tous ceux et celles qui ont fait de même. Et je tiens quand même
compte
de
vos analyses et de vos commentaires et je suis prêt à faire des
changements
si cela s'avérerait nécessaire (exemple dans la version 3.0).
En chiffrant un clair d'une certaine taille ne contenant par exemple
que
des '0', je me suis rendu compte que quelle que soit la taille de la
clé,
il apparaissait dans le chiffré des patterns de 256 octets.
Bonjour,
j'ai essayé aussi avec d'autres clefs mais n'ayant que des zéro (0)
à
chiffrer, et effectivement on voit souvent certains patterns revenir même
si
quelques fois il sont légèrement différents.
J'ai chiffré un fichier de 10M rempli de 0x00 avec une clé composée de 128
'0' (0x30), j'obtiens après 5 mn un fichier qui contient des blocs de 4k
identiques (strictement identiques, à moins que vous n'ayez réussi à
produire des collisions MD5).
Bonjour,
sur ma machine P4 (Pentium 2.4Go) le cryptage/décryptage prend environ
6 à 7 secondes pour chaque Mo, donc environ 1 minutes pour un fichier de
10Mo. AllCrypter ne crypte pas des block de 4 ko même s'il semble que les
patterns se répète à cet intervalle; cela est dû aux calculs effectués qui,
dépendant des valeurs de chaque caractère calculé, fait qu'un même cycle
recommence vu que les octets que vous mettez pour être chiffré sont tous
identiques. Mais les blocks se font toujours avec un certain maximum de
caractères: autour de 2ko.
J'ai 816 blocs de 4k qui apparaissent en
double, et 309 blocs qui apparaissent en triple (et un dernier bloc tout
seul, le dernier, parce que le dernier caractère du clair semble être
chiffré légèrement diféremment des autres). Je n'ai pas encore compté les
distances qui séparent 2 blocs identiques, mais je suis presque sûr que
cette distance est constante. Ces redondances ne vous gènent pas? Vraiment
pas?
Absolument pas puisque cela ne correspond pas à la taille des blocks traités
:)
L'hypothèse selon laquelle la clé qui est saisie est transformée en
interne en un bloc de 256 octets, et que c'est ce bloc de 256 octets
dérivé de la clé qui servira à faire le chiffrement est-elle vraie?
Non, la clef n'est pas transformée en bloc de 256 octets avant le
cryptage mais ses caractères sont permutés, doublés puis permutés de
nouveau; ensuite le cryptage/décryptage se fait à partir de là. Mais la
Et j'ai écrit quoi de différent?
Dépendant des valeurs utilisées dans les calculs cela peut donner des
intervalles de répétition différents, non que la taille des blocks change
mais que le cycle du résultat de calcul change, et cela dépend des valeurs
traitées.
lecture d'un fichier se fait par paquet de 2250000 octets à la fois et
ces
2250000 octets sont cryptés ou décrypté par sous paquet qui font plus
d'un
Ko chacun.
On pourrait croire que ça va plus vite d'utiliser de gros buffers, mais
non. Est-ce la faute du langage choisi (VB), ou de la qualité du
programmeur? Sur la machine d'à côté, le même fichier chiffré en AES128
n'a demandé que 2,4 seconde de traitement, sur une machine plus lente.
Disons que le langage de programmation est différent. Ici on est en vb.
Mais un des objectifs futur est d'y créer un dll écrite en C afin
qu'AllCrypter y fasse appel afin que la procédure d'encryptage/décryptage se
fasse de cette manière plutôt, afin d'augmenter sa vitesse de traitement.
Et concernant la taille des blocks à utiliser cela dépend du langage. Ici
j'ai choisi une taille qui donne le meilleur rendement de vitesse au sein de
la procédure qui exécute le cryptage/décryptage. Des tests ont été faits
pour prendre la taille qui donne le meilleur rendement de vitesse.
Par contre l'idée que vous amenez ressemble à ce que je prévois faire
dans la version 3.0. et que l'on peut lire dans l'historique des versions
Hopopopop! Avant de se jeter sur son clavier, il *faut* prendre un bout de
papier et un crayon, et s'équiper de neurones en état de fonctionnement.
Voudriez-vous aller voir sur http://www.cacr.math.uwaterloo.ca/hac/ et
télécharger le chapitre 6 et le lire, *avant* de pondre votre version 3.0
qui ne sera certainement pas plus robuste?
Réponse plus haut.
a+
r.h.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Manuals out, after all possible keystrokes have failed.
Il n'y a pas de problème là-dessus, car une des raisons de ce forum est de donner son appréciation sur des logiciels de cryptage. Je vous remercie donc de prendre du temps pour éprouver mon logiciel. Je remercie également tous ceux et celles qui ont fait de même. Et je tiens quand même compte de vos analyses et de vos commentaires et je suis prêt à faire des changements si cela s'avérerait nécessaire (exemple dans la version 3.0).
En chiffrant un clair d'une certaine taille ne contenant par exemple que des '0', je me suis rendu compte que quelle que soit la taille de la clé, il apparaissait dans le chiffré des patterns de 256 octets.
Bonjour, j'ai essayé aussi avec d'autres clefs mais n'ayant que des zéro (0) à chiffrer, et effectivement on voit souvent certains patterns revenir même si quelques fois il sont légèrement différents.
J'ai chiffré un fichier de 10M rempli de 0x00 avec une clé composée de 128 '0' (0x30), j'obtiens après 5 mn un fichier qui contient des blocs de 4k identiques (strictement identiques, à moins que vous n'ayez réussi à produire des collisions MD5).
Bonjour,
sur ma machine P4 (Pentium 2.4Go) le cryptage/décryptage prend environ 6 à 7 secondes pour chaque Mo, donc environ 1 minutes pour un fichier de 10Mo. AllCrypter ne crypte pas des block de 4 ko même s'il semble que les patterns se répète à cet intervalle; cela est dû aux calculs effectués qui, dépendant des valeurs de chaque caractère calculé, fait qu'un même cycle recommence vu que les octets que vous mettez pour être chiffré sont tous identiques. Mais les blocks se font toujours avec un certain maximum de caractères: autour de 2ko.
J'ai 816 blocs de 4k qui apparaissent en double, et 309 blocs qui apparaissent en triple (et un dernier bloc tout seul, le dernier, parce que le dernier caractère du clair semble être chiffré légèrement diféremment des autres). Je n'ai pas encore compté les distances qui séparent 2 blocs identiques, mais je suis presque sûr que cette distance est constante. Ces redondances ne vous gènent pas? Vraiment pas?
Absolument pas puisque cela ne correspond pas à la taille des blocks traités :)
L'hypothèse selon laquelle la clé qui est saisie est transformée en interne en un bloc de 256 octets, et que c'est ce bloc de 256 octets dérivé de la clé qui servira à faire le chiffrement est-elle vraie?
Non, la clef n'est pas transformée en bloc de 256 octets avant le cryptage mais ses caractères sont permutés, doublés puis permutés de nouveau; ensuite le cryptage/décryptage se fait à partir de là. Mais la
Et j'ai écrit quoi de différent?
Dépendant des valeurs utilisées dans les calculs cela peut donner des intervalles de répétition différents, non que la taille des blocks change mais que le cycle du résultat de calcul change, et cela dépend des valeurs traitées.
lecture d'un fichier se fait par paquet de 2250000 octets à la fois et ces 2250000 octets sont cryptés ou décrypté par sous paquet qui font plus d'un Ko chacun.
On pourrait croire que ça va plus vite d'utiliser de gros buffers, mais non. Est-ce la faute du langage choisi (VB), ou de la qualité du programmeur? Sur la machine d'à côté, le même fichier chiffré en AES128 n'a demandé que 2,4 seconde de traitement, sur une machine plus lente.
Disons que le langage de programmation est différent. Ici on est en vb. Mais un des objectifs futur est d'y créer un dll écrite en C afin qu'AllCrypter y fasse appel afin que la procédure d'encryptage/décryptage se fasse de cette manière plutôt, afin d'augmenter sa vitesse de traitement. Et concernant la taille des blocks à utiliser cela dépend du langage. Ici j'ai choisi une taille qui donne le meilleur rendement de vitesse au sein de la procédure qui exécute le cryptage/décryptage. Des tests ont été faits pour prendre la taille qui donne le meilleur rendement de vitesse.
Par contre l'idée que vous amenez ressemble à ce que je prévois faire dans la version 3.0. et que l'on peut lire dans l'historique des versions
Hopopopop! Avant de se jeter sur son clavier, il *faut* prendre un bout de papier et un crayon, et s'équiper de neurones en état de fonctionnement. Voudriez-vous aller voir sur http://www.cacr.math.uwaterloo.ca/hac/ et télécharger le chapitre 6 et le lire, *avant* de pondre votre version 3.0 qui ne sera certainement pas plus robuste?
Réponse plus haut. a+ r.h.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Manuals out, after all possible keystrokes have failed.
Raymond H.
"Apokrif" a écrit dans le message de news:
Raymond H. :
Présentement le calcul effectué pour crypter la clef est assez simple. Mais on sait que ce n'est pas la quantité de calcul qui fait qu'un cryptage est d'une bonne qualité mais la logique utilisée. Et j'en convient qu'en regardant les changements d'octets effectués lors d'un cryptage ne sont pas toujours important à l'oeil. Cela dépend de la clef: si elle contient des caractères semblables on y voit moins de changements au niveau des octets que si les caractères sont tous différents. Mais dans la version 3.0, ces changements au niveau visuel seront complètement différents puisque ce ne sera pas la clef elle-même qui sera intégrée dans le cryptogramme.
Les résultats du chiffrement devraient être *complètement* différents (c'est une condition nécessaire, pas suffisante).
En effet, vous avez bien raison. Si le début change alors le reste change. a+ r.h.
http://en.wikipedia.org/wiki/Avalanche_effect
-- `cat ~/.signature`
"Apokrif" <apokrif1@yahoo.com> a écrit dans le message de news:
80is7gkhf4.fsf@apokrif.xyz...
Raymond H. :
Présentement le calcul effectué pour crypter la clef est assez
simple. Mais on sait que ce n'est pas la quantité de calcul qui
fait qu'un cryptage est d'une bonne qualité mais la logique
utilisée. Et j'en convient qu'en regardant les changements d'octets
effectués lors d'un cryptage ne sont pas toujours important à
l'oeil. Cela dépend de la clef: si elle contient des caractères
semblables on y voit moins de changements au niveau des octets que
si les caractères sont tous différents. Mais dans la version 3.0,
ces changements au niveau visuel seront complètement différents
puisque ce ne sera pas la clef elle-même qui sera intégrée dans le
cryptogramme.
Les résultats du chiffrement devraient être *complètement* différents
(c'est une condition nécessaire, pas suffisante).
En effet, vous avez bien raison. Si le début change alors le reste change.
a+
r.h.
Présentement le calcul effectué pour crypter la clef est assez simple. Mais on sait que ce n'est pas la quantité de calcul qui fait qu'un cryptage est d'une bonne qualité mais la logique utilisée. Et j'en convient qu'en regardant les changements d'octets effectués lors d'un cryptage ne sont pas toujours important à l'oeil. Cela dépend de la clef: si elle contient des caractères semblables on y voit moins de changements au niveau des octets que si les caractères sont tous différents. Mais dans la version 3.0, ces changements au niveau visuel seront complètement différents puisque ce ne sera pas la clef elle-même qui sera intégrée dans le cryptogramme.
Les résultats du chiffrement devraient être *complètement* différents (c'est une condition nécessaire, pas suffisante).
En effet, vous avez bien raison. Si le début change alors le reste change. a+ r.h.
http://en.wikipedia.org/wiki/Avalanche_effect
-- `cat ~/.signature`
Erwann ABALEA
Bonsoir,
On Sun, 5 Dec 2004, Raymond H. wrote:
"Erwann ABALEA" a écrit dans le message de news:
sur ma machine P4 (Pentium 2.4Go) le cryptage/décryptage prend environ 6 à 7 secondes pour chaque Mo, donc environ 1 minutes pour un fichier de 10Mo.
C'est toujours très lent. La machine sous Windows qui a fait tourner votre machin est un bi-pro à 560 MHz, et la brouette qui a chiffré le même fichier en 2.4 seconde est une U2 à 300 MHz, ça fait du 4Mo par seconde sur mon bouzin, en comptant les accès disque.
AllCrypter ne crypte pas des block de 4 ko même s'il semble que les patterns se répète à cet intervalle; cela est dû aux calculs effectués qui, dépendant des valeurs de chaque caractère calculé, fait qu'un même cycle recommence vu que les octets que vous mettez pour être chiffré sont tous identiques. Mais les blocks se font toujours avec un certain maximum de caractères: autour de 2ko.
Ah oui mais non, parce qu'avec un algo solide utilisé de la bonne façon, j'ai beau avoir plusieurs centaines de Mo identiques dans le clair, je n'aurais pas de bloc identique dans le chiffré.
J'ai 816 blocs de 4k qui apparaissent en double, et 309 blocs qui apparaissent en triple (et un dernier bloc tout seul, le dernier, parce que le dernier caractère du clair semble être chiffré légèrement diféremment des autres). Je n'ai pas encore compté les distances qui séparent 2 blocs identiques, mais je suis presque sûr que cette distance est constante. Ces redondances ne vous gènent pas? Vraiment pas?
Absolument pas puisque cela ne correspond pas à la taille des blocks traités :)
Sérieusement, vous devriez suivre les conseils qu'on vous donne. Des tas de gens ont consacré des années d'étude sur ce sujet et ont pondu des tas d'articles et de bouquins. Vous pensez sérieusement arriver à une idée révolutionnaire en n'y connaissant rien, et surtout en refusant de vous y intéresser? Attention aux arguments que vous pourriez sortir, on les a certainement déjà entendus. Une lecture des archives de ce groupe serait une bonne idée.
Hint: si j'ai 2 blocs de 4k identiques, c'est bien que leurs 2 moitiés de 2k sont également identiques... Et ça ne vous gène toujours pas...
L'hypothèse selon laquelle la clé qui est saisie est transformée en interne en un bloc de 256 octets, et que c'est ce bloc de 256 octets dérivé de la clé qui servira à faire le chiffrement est-elle vraie?
Non, la clef n'est pas transformée en bloc de 256 octets avant le cryptage mais ses caractères sont permutés, doublés puis permutés de nouveau; ensuite le cryptage/décryptage se fait à partir de là. Mais la
Et j'ai écrit quoi de différent?
Dépendant des valeurs utilisées dans les calculs cela peut donner des intervalles de répétition différents, non que la taille des blocks change mais que le cycle du résultat de calcul change, et cela dépend des valeurs traitées.
Bon. Nous attendons une description de votre algo, ou à défaut un morceau de code source pour la partie chiffrement, parce que visiblement, nous ne parlons pas la même langue, en plus de ne pas parler de la même chose.
Voudriez-vous aller voir sur http://www.cacr.math.uwaterloo.ca/hac/ et télécharger le chapitre 6 et le lire, *avant* de pondre votre version 3.0 qui ne sera certainement pas plus robuste?
Réponse plus haut.
Mauvaise réponse, voir plus haut.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Vous faites chier avec vos annonces à la con ! Ou sont les modérateurs ????? Ca se dégrade cheza Oléane, ca se dégrade ...Ah ouais j'avais oublié , y'a du Farce Télécom derrière, ca doit être ça ... -+- PP in: Guide du Neuneu d'Usenet - Tout, faut tout modérer -+-
Bonsoir,
On Sun, 5 Dec 2004, Raymond H. wrote:
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
Pine.LNX.4.58.0412051516240.21931@shining.seclogd.org...
sur ma machine P4 (Pentium 2.4Go) le cryptage/décryptage prend environ
6 à 7 secondes pour chaque Mo, donc environ 1 minutes pour un fichier de
10Mo.
C'est toujours très lent. La machine sous Windows qui a fait tourner votre
machin est un bi-pro à 560 MHz, et la brouette qui a chiffré le même
fichier en 2.4 seconde est une U2 à 300 MHz, ça fait du 4Mo par seconde
sur mon bouzin, en comptant les accès disque.
AllCrypter ne crypte pas des block de 4 ko même s'il semble que les
patterns se répète à cet intervalle; cela est dû aux calculs effectués qui,
dépendant des valeurs de chaque caractère calculé, fait qu'un même cycle
recommence vu que les octets que vous mettez pour être chiffré sont tous
identiques. Mais les blocks se font toujours avec un certain maximum de
caractères: autour de 2ko.
Ah oui mais non, parce qu'avec un algo solide utilisé de la bonne façon,
j'ai beau avoir plusieurs centaines de Mo identiques dans le clair, je
n'aurais pas de bloc identique dans le chiffré.
J'ai 816 blocs de 4k qui apparaissent en
double, et 309 blocs qui apparaissent en triple (et un dernier bloc tout
seul, le dernier, parce que le dernier caractère du clair semble être
chiffré légèrement diféremment des autres). Je n'ai pas encore compté les
distances qui séparent 2 blocs identiques, mais je suis presque sûr que
cette distance est constante. Ces redondances ne vous gènent pas? Vraiment
pas?
Absolument pas puisque cela ne correspond pas à la taille des blocks traités
:)
Sérieusement, vous devriez suivre les conseils qu'on vous donne. Des tas
de gens ont consacré des années d'étude sur ce sujet et ont pondu des tas
d'articles et de bouquins. Vous pensez sérieusement arriver à une idée
révolutionnaire en n'y connaissant rien, et surtout en refusant de vous
y intéresser? Attention aux arguments que vous pourriez sortir, on les a
certainement déjà entendus. Une lecture des archives de ce groupe serait
une bonne idée.
Hint: si j'ai 2 blocs de 4k identiques, c'est bien que leurs 2 moitiés de
2k sont également identiques... Et ça ne vous gène toujours pas...
L'hypothèse selon laquelle la clé qui est saisie est transformée en
interne en un bloc de 256 octets, et que c'est ce bloc de 256 octets
dérivé de la clé qui servira à faire le chiffrement est-elle vraie?
Non, la clef n'est pas transformée en bloc de 256 octets avant le
cryptage mais ses caractères sont permutés, doublés puis permutés de
nouveau; ensuite le cryptage/décryptage se fait à partir de là. Mais la
Et j'ai écrit quoi de différent?
Dépendant des valeurs utilisées dans les calculs cela peut donner des
intervalles de répétition différents, non que la taille des blocks change
mais que le cycle du résultat de calcul change, et cela dépend des valeurs
traitées.
Bon. Nous attendons une description de votre algo, ou à défaut un
morceau de code source pour la partie chiffrement, parce que visiblement,
nous ne parlons pas la même langue, en plus de ne pas parler de la même
chose.
Voudriez-vous aller voir sur http://www.cacr.math.uwaterloo.ca/hac/ et
télécharger le chapitre 6 et le lire, *avant* de pondre votre version 3.0
qui ne sera certainement pas plus robuste?
Réponse plus haut.
Mauvaise réponse, voir plus haut.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Vous faites chier avec vos annonces à la con ! Ou sont les modérateurs
????? Ca se dégrade cheza Oléane, ca se dégrade ...Ah ouais j'avais
oublié , y'a du Farce Télécom derrière, ca doit être ça ...
-+- PP in: Guide du Neuneu d'Usenet - Tout, faut tout modérer -+-
sur ma machine P4 (Pentium 2.4Go) le cryptage/décryptage prend environ 6 à 7 secondes pour chaque Mo, donc environ 1 minutes pour un fichier de 10Mo.
C'est toujours très lent. La machine sous Windows qui a fait tourner votre machin est un bi-pro à 560 MHz, et la brouette qui a chiffré le même fichier en 2.4 seconde est une U2 à 300 MHz, ça fait du 4Mo par seconde sur mon bouzin, en comptant les accès disque.
AllCrypter ne crypte pas des block de 4 ko même s'il semble que les patterns se répète à cet intervalle; cela est dû aux calculs effectués qui, dépendant des valeurs de chaque caractère calculé, fait qu'un même cycle recommence vu que les octets que vous mettez pour être chiffré sont tous identiques. Mais les blocks se font toujours avec un certain maximum de caractères: autour de 2ko.
Ah oui mais non, parce qu'avec un algo solide utilisé de la bonne façon, j'ai beau avoir plusieurs centaines de Mo identiques dans le clair, je n'aurais pas de bloc identique dans le chiffré.
J'ai 816 blocs de 4k qui apparaissent en double, et 309 blocs qui apparaissent en triple (et un dernier bloc tout seul, le dernier, parce que le dernier caractère du clair semble être chiffré légèrement diféremment des autres). Je n'ai pas encore compté les distances qui séparent 2 blocs identiques, mais je suis presque sûr que cette distance est constante. Ces redondances ne vous gènent pas? Vraiment pas?
Absolument pas puisque cela ne correspond pas à la taille des blocks traités :)
Sérieusement, vous devriez suivre les conseils qu'on vous donne. Des tas de gens ont consacré des années d'étude sur ce sujet et ont pondu des tas d'articles et de bouquins. Vous pensez sérieusement arriver à une idée révolutionnaire en n'y connaissant rien, et surtout en refusant de vous y intéresser? Attention aux arguments que vous pourriez sortir, on les a certainement déjà entendus. Une lecture des archives de ce groupe serait une bonne idée.
Hint: si j'ai 2 blocs de 4k identiques, c'est bien que leurs 2 moitiés de 2k sont également identiques... Et ça ne vous gène toujours pas...
L'hypothèse selon laquelle la clé qui est saisie est transformée en interne en un bloc de 256 octets, et que c'est ce bloc de 256 octets dérivé de la clé qui servira à faire le chiffrement est-elle vraie?
Non, la clef n'est pas transformée en bloc de 256 octets avant le cryptage mais ses caractères sont permutés, doublés puis permutés de nouveau; ensuite le cryptage/décryptage se fait à partir de là. Mais la
Et j'ai écrit quoi de différent?
Dépendant des valeurs utilisées dans les calculs cela peut donner des intervalles de répétition différents, non que la taille des blocks change mais que le cycle du résultat de calcul change, et cela dépend des valeurs traitées.
Bon. Nous attendons une description de votre algo, ou à défaut un morceau de code source pour la partie chiffrement, parce que visiblement, nous ne parlons pas la même langue, en plus de ne pas parler de la même chose.
Voudriez-vous aller voir sur http://www.cacr.math.uwaterloo.ca/hac/ et télécharger le chapitre 6 et le lire, *avant* de pondre votre version 3.0 qui ne sera certainement pas plus robuste?
Réponse plus haut.
Mauvaise réponse, voir plus haut.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Vous faites chier avec vos annonces à la con ! Ou sont les modérateurs ????? Ca se dégrade cheza Oléane, ca se dégrade ...Ah ouais j'avais oublié , y'a du Farce Télécom derrière, ca doit être ça ... -+- PP in: Guide du Neuneu d'Usenet - Tout, faut tout modérer -+-
pornin
According to Erwann ABALEA :
On Sun, 5 Dec 2004, Raymond H. wrote:
sur ma machine P4 (Pentium 2.4Go) le cryptage/décryptage prend environ 6 à 7 secondes pour chaque Mo, donc environ 1 minutes pour un fichier de 10Mo.
C'est toujours très lent.
Juste en passant (je n'ai suivi que très distraitement le thread précédent) :
-- Il y a des usages de la cryptographie qui n'ont pas de problèmes de performances. Par exemple, le courrier électronique. Le courrier est asynchrone, et peut prendre son temps ; l'utilisateur moyen, même avec un énorme ADSL, a par ailleurs un débit d'émission assez faible (genre 128 ou 256 kilobits par seconde). Enfin, il est normalement assez rare d'envoyer de gros mails (même si avec des pièces jointes, on peut monter assez vite).
-- Il y a des usages de la cryptographie qui ont de vrais problèmes de performances. Les cas typiques sont les VPN sur de l'ethernet gigabit, et les disques durs chiffrés. Les débits voulus sont alors, respectivement, de 100 et 40 mégaoctets par seconde ; de plus, on voudrait faire ça en n'y consacrant qu'au plus, mettons, 20% du cpu, parce que ça tourne sur des machines dites "multi-tâches" qui ont autre chose à faire que du chiffrement.
Les records en la matière, avec un algorithme décent comme l'AES, sont d'environ 240 cycles d'horloge pour chaque bloc de 16 octets ; sur une machine à 3 GHz, ça fait pas loin de 200 Mo/s (à plein cpu), ce qui, avec 20% du cpu, nous donne les 40 Mo/s voulus pour un disque dur chiffré, mais pas les 100 Mo/s du VPN gigabit. De plus, cette performance est fondé sur un compte de cycle sur Pentium III ; sur Pentium IV, la note monte (le Pentium IV tourne à une cadence plus élevée, mais il en fait moins par cycle d'horloge). Enfin, c'est un compte qui fait fi de toute notion de cache. Donc la performance réelle serait probablement assez nettement plus faible (à la louche, moitié moindre). Ça fait tomber l'AES à 100 Mo/s sur un gros PC, à plein cpu.
Dans ces conditions, 6 ou 7 secondes pour un malheureux mégaoctet, c'est pathétique.
--Thomas Pornin
According to Erwann ABALEA <erwann@abalea.com>:
On Sun, 5 Dec 2004, Raymond H. wrote:
sur ma machine P4 (Pentium 2.4Go) le cryptage/décryptage prend environ
6 à 7 secondes pour chaque Mo, donc environ 1 minutes pour un fichier de
10Mo.
C'est toujours très lent.
Juste en passant (je n'ai suivi que très distraitement le thread
précédent) :
-- Il y a des usages de la cryptographie qui n'ont pas de problèmes de
performances. Par exemple, le courrier électronique. Le courrier est
asynchrone, et peut prendre son temps ; l'utilisateur moyen, même avec
un énorme ADSL, a par ailleurs un débit d'émission assez faible (genre
128 ou 256 kilobits par seconde). Enfin, il est normalement assez rare
d'envoyer de gros mails (même si avec des pièces jointes, on peut monter
assez vite).
-- Il y a des usages de la cryptographie qui ont de vrais problèmes
de performances. Les cas typiques sont les VPN sur de l'ethernet
gigabit, et les disques durs chiffrés. Les débits voulus sont alors,
respectivement, de 100 et 40 mégaoctets par seconde ; de plus, on
voudrait faire ça en n'y consacrant qu'au plus, mettons, 20% du cpu,
parce que ça tourne sur des machines dites "multi-tâches" qui ont autre
chose à faire que du chiffrement.
Les records en la matière, avec un algorithme décent comme l'AES,
sont d'environ 240 cycles d'horloge pour chaque bloc de 16 octets ;
sur une machine à 3 GHz, ça fait pas loin de 200 Mo/s (à plein cpu),
ce qui, avec 20% du cpu, nous donne les 40 Mo/s voulus pour un disque
dur chiffré, mais pas les 100 Mo/s du VPN gigabit. De plus, cette
performance est fondé sur un compte de cycle sur Pentium III ; sur
Pentium IV, la note monte (le Pentium IV tourne à une cadence plus
élevée, mais il en fait moins par cycle d'horloge). Enfin, c'est un
compte qui fait fi de toute notion de cache. Donc la performance réelle
serait probablement assez nettement plus faible (à la louche, moitié
moindre). Ça fait tomber l'AES à 100 Mo/s sur un gros PC, à plein cpu.
Dans ces conditions, 6 ou 7 secondes pour un malheureux mégaoctet,
c'est pathétique.
sur ma machine P4 (Pentium 2.4Go) le cryptage/décryptage prend environ 6 à 7 secondes pour chaque Mo, donc environ 1 minutes pour un fichier de 10Mo.
C'est toujours très lent.
Juste en passant (je n'ai suivi que très distraitement le thread précédent) :
-- Il y a des usages de la cryptographie qui n'ont pas de problèmes de performances. Par exemple, le courrier électronique. Le courrier est asynchrone, et peut prendre son temps ; l'utilisateur moyen, même avec un énorme ADSL, a par ailleurs un débit d'émission assez faible (genre 128 ou 256 kilobits par seconde). Enfin, il est normalement assez rare d'envoyer de gros mails (même si avec des pièces jointes, on peut monter assez vite).
-- Il y a des usages de la cryptographie qui ont de vrais problèmes de performances. Les cas typiques sont les VPN sur de l'ethernet gigabit, et les disques durs chiffrés. Les débits voulus sont alors, respectivement, de 100 et 40 mégaoctets par seconde ; de plus, on voudrait faire ça en n'y consacrant qu'au plus, mettons, 20% du cpu, parce que ça tourne sur des machines dites "multi-tâches" qui ont autre chose à faire que du chiffrement.
Les records en la matière, avec un algorithme décent comme l'AES, sont d'environ 240 cycles d'horloge pour chaque bloc de 16 octets ; sur une machine à 3 GHz, ça fait pas loin de 200 Mo/s (à plein cpu), ce qui, avec 20% du cpu, nous donne les 40 Mo/s voulus pour un disque dur chiffré, mais pas les 100 Mo/s du VPN gigabit. De plus, cette performance est fondé sur un compte de cycle sur Pentium III ; sur Pentium IV, la note monte (le Pentium IV tourne à une cadence plus élevée, mais il en fait moins par cycle d'horloge). Enfin, c'est un compte qui fait fi de toute notion de cache. Donc la performance réelle serait probablement assez nettement plus faible (à la louche, moitié moindre). Ça fait tomber l'AES à 100 Mo/s sur un gros PC, à plein cpu.
Dans ces conditions, 6 ou 7 secondes pour un malheureux mégaoctet, c'est pathétique.
--Thomas Pornin
Vengeur Masqué
On Sun Dec 05 2004 at 16:05, Erwann ABALEA wrote:
J'ai chiffré un fichier de 10M rempli de 0x00 avec une clé composée de 128 '0' (0x30), j'obtiens après 5 mn
Ouaaaaahhhh !.... Ça c'est de l'algo qu'il est performant ! 10 Mo en 5 min... On ne doit pas être loin de 1000 fois plus lent qu'un bon AES.
-- Le Vengeur Masqué se vengera ! http://vm666.dotnode.com/ http://vm666.free.fr/
On Sun Dec 05 2004 at 16:05, Erwann ABALEA wrote:
J'ai chiffré un fichier de 10M rempli de 0x00 avec une clé composée de 128
'0' (0x30), j'obtiens après 5 mn
Ouaaaaahhhh !.... Ça c'est de l'algo qu'il est performant !
10 Mo en 5 min... On ne doit pas être loin de 1000 fois plus lent
qu'un bon AES.
--
Le Vengeur Masqué se vengera !
http://vm666.dotnode.com/ http://vm666.free.fr/
