Si je regarde ce que me donne la commande top sur mon serveur Genntoo,
j'ai ceci:
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU
COMMAND
30852 pkzip1 56 0 956K 548K RUN 138.6H 98.78% 98.78%
fcrackzip
8<-
Cela fait maintenant pres de 6 jours que mon bi-Pentium3 ne servant
rien du tout fait des milliers de tentatives par jour pour casser un
mot de passe de 8 caracteres du genre "E}9i[<PM"
Est-ce cela signifie que le codage PKZip est solide? Cela en a l'air!
Est-ce cela signifie que le codage PKZip est solide?
Ou que le programme de cassage est totalement stupide ?
Jean-Marc Desperrier
Allan Wilson wrote:
Cela fait maintenant pres de 6 jours que mon bi-Pentium3 ne servant rien du tout fait des milliers de tentatives par jour pour casser un mot de passe de 8 caracteres du genre "E}9i[<PM"
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
Si on considére qu'il n'y a pas les caractère de controle, ni ceux accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit environ 52 bits. Si tu veux casser avec un seul PC en 6 jours, il faut qu'il déroule pas mal d'essais par seconde. Un petit calcul donne autour de 10 milliards d'essais par seconde.
Oui, entre quelquechose de réputé cassable facilement, et "je prends mon pc perso, je laisse tourner, et ca casse sans effort", il y a un écart.
La raison pour laquelle souvent les mot de passe se cassent vite, est qu'ils sont pratiquement toujours, beaucoup, beaucoup plus faible que cela.
Allan Wilson wrote:
Cela fait maintenant pres de 6 jours que mon bi-Pentium3 ne servant
rien du tout fait des milliers de tentatives par jour pour casser un
mot de passe de 8 caracteres du genre "E}9i[<PM"
Ben en pure force brut, 8 caractère sans qu'on soit capable de
restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela
commence à avoir "une certaine" résistance.
Si on considére qu'il n'y a pas les caractère de controle, ni ceux
accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit
environ 52 bits. Si tu veux casser avec un seul PC en 6 jours, il faut
qu'il déroule pas mal d'essais par seconde.
Un petit calcul donne autour de 10 milliards d'essais par seconde.
Oui, entre quelquechose de réputé cassable facilement, et "je prends mon
pc perso, je laisse tourner, et ca casse sans effort", il y a un écart.
La raison pour laquelle souvent les mot de passe se cassent vite, est
qu'ils sont pratiquement toujours, beaucoup, beaucoup plus faible que cela.
Cela fait maintenant pres de 6 jours que mon bi-Pentium3 ne servant rien du tout fait des milliers de tentatives par jour pour casser un mot de passe de 8 caracteres du genre "E}9i[<PM"
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
Si on considére qu'il n'y a pas les caractère de controle, ni ceux accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit environ 52 bits. Si tu veux casser avec un seul PC en 6 jours, il faut qu'il déroule pas mal d'essais par seconde. Un petit calcul donne autour de 10 milliards d'essais par seconde.
Oui, entre quelquechose de réputé cassable facilement, et "je prends mon pc perso, je laisse tourner, et ca casse sans effort", il y a un écart.
La raison pour laquelle souvent les mot de passe se cassent vite, est qu'ils sont pratiquement toujours, beaucoup, beaucoup plus faible que cela.
Xavier Roche
Jean-Marc Desperrier wrote:
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
J'ajoute: Bruce Scheiner a levé des problèmes dans l'algo pkzip qui permettrait d'attaquer le système de chiffrement. A ma connaissance aucune attaque publique disponible n'exploite cette faiblesse.
Mais cela en dit long sur la sécurité du "chiffrement" pkzip.
Jean-Marc Desperrier wrote:
Ben en pure force brut, 8 caractère sans qu'on soit capable de
restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela
commence à avoir "une certaine" résistance.
J'ajoute: Bruce Scheiner a levé des problèmes dans l'algo pkzip qui
permettrait d'attaquer le système de chiffrement. A ma connaissance
aucune attaque publique disponible n'exploite cette faiblesse.
Mais cela en dit long sur la sécurité du "chiffrement" pkzip.
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
J'ajoute: Bruce Scheiner a levé des problèmes dans l'algo pkzip qui permettrait d'attaquer le système de chiffrement. A ma connaissance aucune attaque publique disponible n'exploite cette faiblesse.
Mais cela en dit long sur la sécurité du "chiffrement" pkzip.
Jean-Marc Desperrier
Xavier Roche wrote:
Jean-Marc Desperrier wrote:
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
J'ajoute: Bruce Scheiner a levé des problèmes dans l'algo pkzip qui permettrait d'attaquer le système de chiffrement. A ma connaissance aucune attaque publique disponible n'exploite cette faiblesse.
Mais cela en dit long sur la sécurité du "chiffrement" pkzip.
Il est bien connu que ce chiffrement explose complètement face aux attaques à clair connu. Le clair connu ici, c'est le contenu après compression/avant chiffrement. C'est très, très efficaces, mais pas applicables à 100% des cas. Il y a quelques outils publiquement disponible qui implémentent cela.
Il y a une faille implémenté publiquement (dans le sens description complète, et il existe l'exécutable simple qui le fait au moins sur le disque dur du chercheur qui l'a publié) qui cumule en fait cette faiblesse à une erreur dans la gestion de la date qui fait que toute archive Winzip (au moins sur les versions précédant la publication) contenant plus de 3 fichiers contient plusieurs octets de "clair" pour casser n'importe quelle archive sans que l'utilisateur ait besoin lui de fournir du "clair" à l'outils.
Cependant la plupart des outils de 'crack' disponible à gauche, à droite, font seulement de la force brute, et ça, ça devient rapidement long si le mot de passe est vraiment quelconque et qu'il n'est pas très court.
Xavier Roche wrote:
Jean-Marc Desperrier wrote:
Ben en pure force brut, 8 caractère sans qu'on soit capable de
restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela
commence à avoir "une certaine" résistance.
J'ajoute: Bruce Scheiner a levé des problèmes dans l'algo pkzip qui
permettrait d'attaquer le système de chiffrement. A ma connaissance
aucune attaque publique disponible n'exploite cette faiblesse.
Mais cela en dit long sur la sécurité du "chiffrement" pkzip.
Il est bien connu que ce chiffrement explose complètement face aux
attaques à clair connu.
Le clair connu ici, c'est le contenu après compression/avant chiffrement.
C'est très, très efficaces, mais pas applicables à 100% des cas.
Il y a quelques outils publiquement disponible qui implémentent cela.
Il y a une faille implémenté publiquement (dans le sens description
complète, et il existe l'exécutable simple qui le fait au moins sur le
disque dur du chercheur qui l'a publié) qui cumule en fait cette
faiblesse à une erreur dans la gestion de la date qui fait que toute
archive Winzip (au moins sur les versions précédant la publication)
contenant plus de 3 fichiers contient plusieurs octets de "clair" pour
casser n'importe quelle archive sans que l'utilisateur ait besoin lui de
fournir du "clair" à l'outils.
Cependant la plupart des outils de 'crack' disponible à gauche, à
droite, font seulement de la force brute, et ça, ça devient rapidement
long si le mot de passe est vraiment quelconque et qu'il n'est pas très
court.
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
J'ajoute: Bruce Scheiner a levé des problèmes dans l'algo pkzip qui permettrait d'attaquer le système de chiffrement. A ma connaissance aucune attaque publique disponible n'exploite cette faiblesse.
Mais cela en dit long sur la sécurité du "chiffrement" pkzip.
Il est bien connu que ce chiffrement explose complètement face aux attaques à clair connu. Le clair connu ici, c'est le contenu après compression/avant chiffrement. C'est très, très efficaces, mais pas applicables à 100% des cas. Il y a quelques outils publiquement disponible qui implémentent cela.
Il y a une faille implémenté publiquement (dans le sens description complète, et il existe l'exécutable simple qui le fait au moins sur le disque dur du chercheur qui l'a publié) qui cumule en fait cette faiblesse à une erreur dans la gestion de la date qui fait que toute archive Winzip (au moins sur les versions précédant la publication) contenant plus de 3 fichiers contient plusieurs octets de "clair" pour casser n'importe quelle archive sans que l'utilisateur ait besoin lui de fournir du "clair" à l'outils.
Cependant la plupart des outils de 'crack' disponible à gauche, à droite, font seulement de la force brute, et ça, ça devient rapidement long si le mot de passe est vraiment quelconque et qu'il n'est pas très court.
Apokrif
Jean-Marc Desperrier :
La raison pour laquelle souvent les mot de passe se cassent vite, est qu'ils sont pratiquement toujours, beaucoup, beaucoup plus faible que cela.
La raison pour laquelle un algo est cassé, c'est souvent qu'il existe un moyen plus rapide de le casser que de s'amuser à tester toutes les clefs possibles.
-- `cat ~/.signature`
Jean-Marc Desperrier :
La raison pour laquelle souvent les mot de passe se cassent vite,
est qu'ils sont pratiquement toujours, beaucoup, beaucoup plus
faible que cela.
La raison pour laquelle un algo est cassé, c'est souvent qu'il existe
un moyen plus rapide de le casser que de s'amuser à tester toutes les
clefs possibles.
La raison pour laquelle souvent les mot de passe se cassent vite, est qu'ils sont pratiquement toujours, beaucoup, beaucoup plus faible que cela.
La raison pour laquelle un algo est cassé, c'est souvent qu'il existe un moyen plus rapide de le casser que de s'amuser à tester toutes les clefs possibles.
-- `cat ~/.signature`
Apokrif
Allan Wilson :
Cela fait maintenant pres de 6 jours que mon bi-Pentium3 ne servant rien du tout fait des milliers de tentatives par jour pour casser un mot de passe de 8 caracteres du genre "E}9i[<PM"
Vous seriez parvenu plus vite au même résultat si vous aviez laissé tourner votre programme de recherche de mots de passe quelques secondes seulement, puis aviez fait une petite multiplication pour trouver le temps total nécessaire...
-- `cat ~/.signature`
Allan Wilson :
Cela fait maintenant pres de 6 jours que mon bi-Pentium3 ne servant
rien du tout fait des milliers de tentatives par jour pour casser un
mot de passe de 8 caracteres du genre "E}9i[<PM"
Vous seriez parvenu plus vite au même résultat si vous aviez laissé
tourner votre programme de recherche de mots de passe quelques
secondes seulement, puis aviez fait une petite multiplication pour
trouver le temps total nécessaire...
Cela fait maintenant pres de 6 jours que mon bi-Pentium3 ne servant rien du tout fait des milliers de tentatives par jour pour casser un mot de passe de 8 caracteres du genre "E}9i[<PM"
Vous seriez parvenu plus vite au même résultat si vous aviez laissé tourner votre programme de recherche de mots de passe quelques secondes seulement, puis aviez fait une petite multiplication pour trouver le temps total nécessaire...
-- `cat ~/.signature`
jacopo
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
Si on considére qu'il n'y a pas les caractère de controle, ni ceux accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit environ 52 bits.
Ben en pure force brut, 8 caractère sans qu'on soit capable de
restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela
commence à avoir "une certaine" résistance.
Si on considére qu'il n'y a pas les caractère de controle, ni ceux
accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit
environ 52 bits.
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
Si on considére qu'il n'y a pas les caractère de controle, ni ceux accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit environ 52 bits.
"jacopo" wrote in news:ccf62i$4g1$ reader1.wanadoo.fr:
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
Si on considére qu'il n'y a pas les caractère de controle, ni ceux accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit environ 52 bits.
"jacopo" <jacopo@nospam.com> wrote in news:ccf62i$4g1$1@news-
reader1.wanadoo.fr:
Ben en pure force brut, 8 caractère sans qu'on soit capable de
restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela
commence à avoir "une certaine" résistance.
Si on considére qu'il n'y a pas les caractère de controle, ni ceux
accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit
environ 52 bits.
"jacopo" wrote in news:ccf62i$4g1$ reader1.wanadoo.fr:
Ben en pure force brut, 8 caractère sans qu'on soit capable de restreindre le répertoire dans lequel on les choisi dans l'ASCII, cela commence à avoir "une certaine" résistance.
Si on considére qu'il n'y a pas les caractère de controle, ni ceux accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit environ 52 bits.
"jacopo" wrote in news:ccf62i$4g1$ reader1.wanadoo.fr:
Si on considére qu'il n'y a pas les caractère de controle, ni ceux accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit environ 52 bits.
Oui, le chiffre sort un peu de ma poche quand même.
Stricto sensus on devrait pouvoir aller jusqu'à 94 valeurs utilisables par caractères, (128 - 32 - 1 ('0') -1 ('7F-DELETE' pose de sérieux problèmes) ), mais il me semblait me souvenir qu'il en restait encore 2, 3 trois à exclure.
Mais j'avais tort, on peut bien pousser jusqu'à 94. M'enfin, ça ne change pas grand chose, on pourra dire que j'avais arrondi à l'inférieur, 94^8 = 6.10^15
Pierre Vandevennne wrote:
"jacopo" <jacopo@nospam.com> wrote in news:ccf62i$4g1$1@news-
reader1.wanadoo.fr:
Si on considére qu'il n'y a pas les caractère de controle, ni ceux
accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit
environ 52 bits.
Oui, le chiffre sort un peu de ma poche quand même.
Stricto sensus on devrait pouvoir aller jusqu'à 94 valeurs utilisables
par caractères, (128 - 32 - 1 ('0') -1 ('7F-DELETE' pose de sérieux
problèmes) ), mais il me semblait me souvenir qu'il en restait encore 2,
3 trois à exclure.
Mais j'avais tort, on peut bien pousser jusqu'à 94. M'enfin, ça ne
change pas grand chose, on pourra dire que j'avais arrondi à
l'inférieur, 94^8 = 6.10^15
"jacopo" wrote in news:ccf62i$4g1$ reader1.wanadoo.fr:
Si on considére qu'il n'y a pas les caractère de controle, ni ceux accentués, ça fait quand même déjà dans les 5.10^15 possibilités, soit environ 52 bits.
Oui, le chiffre sort un peu de ma poche quand même.
Stricto sensus on devrait pouvoir aller jusqu'à 94 valeurs utilisables par caractères, (128 - 32 - 1 ('0') -1 ('7F-DELETE' pose de sérieux problèmes) ), mais il me semblait me souvenir qu'il en restait encore 2, 3 trois à exclure.
Mais j'avais tort, on peut bien pousser jusqu'à 94. M'enfin, ça ne change pas grand chose, on pourra dire que j'avais arrondi à l'inférieur, 94^8 = 6.10^15
