WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire
Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600
seconds? Avec un P4 3Ghz par exemple?
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Ca va prendre à peu près 100% des capacités de ton CPU, quel qu'il soit, si tu le laisses faire. Ce qui variera, c'est le temps qu'il faudra pour arriver au bout.
Le mar, 07 nov 2006 at 10:09 GMT, Jordy <Jordy@Jordy.com> a écrit :
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire
Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600
seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Ca va prendre à peu près 100% des capacités de ton CPU, quel qu'il soit,
si tu le laisses faire.
Ce qui variera, c'est le temps qu'il faudra pour arriver au bout.
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Ca va prendre à peu près 100% des capacités de ton CPU, quel qu'il soit, si tu le laisses faire. Ce qui variera, c'est le temps qu'il faudra pour arriver au bout.
Fred sur Free
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Merci pour vos réponses :-) LOL
DurDur d'être un hacker Tu peux monter un projet BOINC pour aller vite ... LOL
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire
Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600
seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Merci pour vos réponses :-)
LOL
DurDur d'être un hacker
Tu peux monter un projet BOINC pour aller vite ...
LOL
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Merci pour vos réponses :-) LOL
DurDur d'être un hacker Tu peux monter un projet BOINC pour aller vite ... LOL
Eric Razny
Le Tue, 07 Nov 2006 10:09:06 +0000, Jordy a écrit :
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Ca fait une clef brute de 375 bits. Si ton générateur évite les clefs faibles la possibilité de crackage est anecdotique. Le hacker devra passer par d'autres moyens (trojan en poussant à consulter un site offensif via un email par exemple) pour avoir accès au système.
Ca suppose quand même bien sur que les machines ne soient pas accessibles physiquement au premier venu, sinon c'est -bien sur- mort.
Eric.
Le Tue, 07 Nov 2006 10:09:06 +0000, Jordy a écrit :
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire
Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600
seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Ca fait une clef brute de 375 bits.
Si ton générateur évite les clefs faibles la possibilité de crackage
est anecdotique. Le hacker devra passer par d'autres moyens (trojan en
poussant à consulter un site offensif via un email par exemple) pour
avoir accès au système.
Ca suppose quand même bien sur que les machines ne soient pas accessibles
physiquement au premier venu, sinon c'est -bien sur- mort.
Le Tue, 07 Nov 2006 10:09:06 +0000, Jordy a écrit :
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Ca fait une clef brute de 375 bits. Si ton générateur évite les clefs faibles la possibilité de crackage est anecdotique. Le hacker devra passer par d'autres moyens (trojan en poussant à consulter un site offensif via un email par exemple) pour avoir accès au système.
Ca suppose quand même bien sur que les machines ne soient pas accessibles physiquement au premier venu, sinon c'est -bien sur- mort.
Eric.
Pascal Bourguignon
Frederic Bonroy writes:
Mon rêve à moi, c'est que les logiciels commencent enfin un jour à profiter réellement de l'évolution du matériel et que la vitesse d'exécution perçue augmente ENFIN véritablement.
Il suffit d'éviter les GUI au maximum.
Je trouve ça un peu couillon qu'Intel et AMD passent du temps à peaufiner leurs processeurs jusqu'au dernier transistor alors qu'en même temps on a des tas de manches qui produisent des programmes plus adipeux les uns que les autres. La logique m'échappe, mais alors totalement.
La logique est commerciale et salariale.
Un PC neuf coûte 300 euro. Une journée de programmeur coûte au moins 300 euro.
Alors, si le gain de vitesse obtenu au bout d'une journée de travail d'un programmeur est inférieur à celui obtenu en achetant un processeur neuf, c'est vite vu...
Et si tu as besoin d'encore plus de vitesse, tu peux aussi considérer des ordinateurs plus puissants, le plus probable, c'est que même avec une année.homme de salaire de programmeur (~72,000 ¤), il ne fera pas plus rapide et moins cher que le matériel disponible pour ce prix.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Cats meow out of angst "Thumbs! If only we had thumbs! We could break so much!"
Frederic Bonroy <bidonavirus@yahoo.fr> writes:
Mon rêve à moi, c'est que les logiciels commencent enfin un jour à
profiter réellement de l'évolution du matériel et que la vitesse
d'exécution perçue augmente ENFIN véritablement.
Il suffit d'éviter les GUI au maximum.
Je trouve ça un peu couillon qu'Intel et AMD passent du temps à
peaufiner leurs processeurs jusqu'au dernier transistor alors qu'en
même temps on a des tas de manches qui produisent des programmes plus
adipeux les uns que les autres. La logique m'échappe, mais alors
totalement.
La logique est commerciale et salariale.
Un PC neuf coûte 300 euro.
Une journée de programmeur coûte au moins 300 euro.
Alors, si le gain de vitesse obtenu au bout d'une journée de travail
d'un programmeur est inférieur à celui obtenu en achetant un
processeur neuf, c'est vite vu...
Et si tu as besoin d'encore plus de vitesse, tu peux aussi considérer
des ordinateurs plus puissants, le plus probable, c'est que même avec
une année.homme de salaire de programmeur (~72,000 ¤), il ne fera pas
plus rapide et moins cher que le matériel disponible pour ce prix.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
Mon rêve à moi, c'est que les logiciels commencent enfin un jour à profiter réellement de l'évolution du matériel et que la vitesse d'exécution perçue augmente ENFIN véritablement.
Il suffit d'éviter les GUI au maximum.
Je trouve ça un peu couillon qu'Intel et AMD passent du temps à peaufiner leurs processeurs jusqu'au dernier transistor alors qu'en même temps on a des tas de manches qui produisent des programmes plus adipeux les uns que les autres. La logique m'échappe, mais alors totalement.
La logique est commerciale et salariale.
Un PC neuf coûte 300 euro. Une journée de programmeur coûte au moins 300 euro.
Alors, si le gain de vitesse obtenu au bout d'une journée de travail d'un programmeur est inférieur à celui obtenu en achetant un processeur neuf, c'est vite vu...
Et si tu as besoin d'encore plus de vitesse, tu peux aussi considérer des ordinateurs plus puissants, le plus probable, c'est que même avec une année.homme de salaire de programmeur (~72,000 ¤), il ne fera pas plus rapide et moins cher que le matériel disponible pour ce prix.
-- __Pascal Bourguignon__ http://www.informatimago.com/ Cats meow out of angst "Thumbs! If only we had thumbs! We could break so much!"
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Tu comprends que ta question n'a pas tellement de sens ? Que veux tu faire exactement ?
Est ce gourmand en ressource?
Là dessus, Arnold et autres ont bien résumé...
Yves
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire
Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600
seconds? Avec un P4 3Ghz par exemple?
Tu comprends que ta question n'a pas tellement de sens ?
Que veux tu faire exactement ?
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Tu comprends que ta question n'a pas tellement de sens ? Que veux tu faire exactement ?
Est ce gourmand en ressource?
Là dessus, Arnold et autres ont bien résumé...
Yves
Arnold McDonald \(AMcD\)
Olivier Masson wrote:
Tu mélanges bcp de problèmes.
Ben voyons !
Et tu fais encore une confusion.
Mais oui...
Mais ensuite, je suis devenu également admin réseau, et depuis, lorsque le cpu de serveurs passe au-dessus de 70%, je dois avouer que j'ai un peu peur. Rien à craindre mais derrière, ce n'est pas le calcul des décimales de pi ou la vidéo de mémé au ski en H264, c'est la productivité d'une entreprise.
Mais ça veux dire quoi 70% ? Rien du tout. Mémoire, cpu, bande passante ? Quel contexte ? Quelle charge ? Quelle application ? Distribuée ? Multithread ? Combien de processeurs ? Combien de clients ? De connexions ?
Chaque thread prendra le même nombre de ms pour s'exécuter hein... Moi, je dirai l'inverse, si ta machine tourne à 70%, c'est bien, au moins, elle sert à quelque chose.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Olivier Masson wrote:
Tu mélanges bcp de problèmes.
Ben voyons !
Et tu fais encore une confusion.
Mais oui...
Mais ensuite, je suis devenu également admin réseau, et depuis,
lorsque le cpu de serveurs passe au-dessus de 70%, je dois avouer que j'ai
un
peu peur. Rien à craindre mais derrière, ce n'est pas le calcul des
décimales de pi ou la vidéo de mémé au ski en H264, c'est la
productivité d'une entreprise.
Mais ça veux dire quoi 70% ? Rien du tout. Mémoire, cpu, bande passante ?
Quel contexte ? Quelle charge ? Quelle application ? Distribuée ?
Multithread ? Combien de processeurs ? Combien de clients ? De connexions ?
Chaque thread prendra le même nombre de ms pour s'exécuter hein... Moi, je
dirai l'inverse, si ta machine tourne à 70%, c'est bien, au moins, elle sert
à quelque chose.
Mais ensuite, je suis devenu également admin réseau, et depuis, lorsque le cpu de serveurs passe au-dessus de 70%, je dois avouer que j'ai un peu peur. Rien à craindre mais derrière, ce n'est pas le calcul des décimales de pi ou la vidéo de mémé au ski en H264, c'est la productivité d'une entreprise.
Mais ça veux dire quoi 70% ? Rien du tout. Mémoire, cpu, bande passante ? Quel contexte ? Quelle charge ? Quelle application ? Distribuée ? Multithread ? Combien de processeurs ? Combien de clients ? De connexions ?
Chaque thread prendra le même nombre de ms pour s'exécuter hein... Moi, je dirai l'inverse, si ta machine tourne à 70%, c'est bien, au moins, elle sert à quelque chose.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Olivier Masson
Olivier Masson wrote:
Tu mélanges bcp de problèmes.
Ben voyons !
Eh oui.
Et tu fais encore une confusion.
Mais oui...
C'est sûr.
Mais ça veux dire quoi 70% ? Rien du tout. Mémoire, cpu, bande passante ? Quel contexte ? Quelle charge ? Quelle application ? Distribuée ? Multithread ? Combien de processeurs ? Combien de clients ? De connexions ?
Chaque thread prendra le même nombre de ms pour s'exécuter hein... Moi, je dirai l'inverse, si ta machine tourne à 70%, c'est bien, au moins, elle sert à quelque chose.
Tu te focalises sur mes 70% alors que c'est tout le reste qui était intéressant. J'avais dis que ce % n'avait rien de significatif et que je prenais peur pour pas grand chose. Tu vois, tu te trompes de sujet.
Ensuite, dans ta liste d'interrogations, il y a des choses qui n'ont pas lieu d'être si on réfléchit un minimum. On a rien à faire du nombre de clients, de connexions, de proc, pour avoir peur d'une utilisation CPU(s) à 97% pour un unique serveur d'entreprise (donc, en général, serveur de fichier, ldap, dns, dhcp, smtp, etc.) Qu'il y ait 10 clients ou 10000, le problème est le même : le serveur est surchargé. Par contre, la solution sera certainement différente (et ce n'est pas du quad-opteron qui solutionnera forcément les choses) et dépendra du cas précis (si j'ai 10000 clients qd je suis à 97% mais qu'habituellement j'ai 1000 clients, je peux respirer).
Mais bon, tout ça tu le sais bien. Ce que je veux dire, c'est simplement qu'une appli légère, c'est légitime de le vouloir. Et, selon l'utilisation de UC, 70% ça peut être énorme ou pas. "si ta machine tourne à 70%, c'est bien, au moins, elle sert à quelque chose" : certes, mais là encore, ça dépend du moment. Si elle est à 70% et que je sais que j'aurais des pics de 10 fois la charge actuelle, je suis très mal.
Olivier Masson wrote:
Tu mélanges bcp de problèmes.
Ben voyons !
Eh oui.
Et tu fais encore une confusion.
Mais oui...
C'est sûr.
Mais ça veux dire quoi 70% ? Rien du tout. Mémoire, cpu, bande passante ?
Quel contexte ? Quelle charge ? Quelle application ? Distribuée ?
Multithread ? Combien de processeurs ? Combien de clients ? De connexions ?
Chaque thread prendra le même nombre de ms pour s'exécuter hein... Moi, je
dirai l'inverse, si ta machine tourne à 70%, c'est bien, au moins, elle sert
à quelque chose.
Tu te focalises sur mes 70% alors que c'est tout le reste qui était
intéressant. J'avais dis que ce % n'avait rien de significatif et que je
prenais peur pour pas grand chose. Tu vois, tu te trompes de sujet.
Ensuite, dans ta liste d'interrogations, il y a des choses qui n'ont pas
lieu d'être si on réfléchit un minimum. On a rien à faire du nombre de
clients, de connexions, de proc, pour avoir peur d'une utilisation
CPU(s) à 97% pour un unique serveur d'entreprise (donc, en général,
serveur de fichier, ldap, dns, dhcp, smtp, etc.) Qu'il y ait 10 clients
ou 10000, le problème est le même : le serveur est surchargé. Par
contre, la solution sera certainement différente (et ce n'est pas du
quad-opteron qui solutionnera forcément les choses) et dépendra du cas
précis (si j'ai 10000 clients qd je suis à 97% mais qu'habituellement
j'ai 1000 clients, je peux respirer).
Mais bon, tout ça tu le sais bien. Ce que je veux dire, c'est simplement
qu'une appli légère, c'est légitime de le vouloir. Et, selon
l'utilisation de UC, 70% ça peut être énorme ou pas. "si ta machine
tourne à 70%, c'est bien, au moins, elle sert à quelque chose" : certes,
mais là encore, ça dépend du moment. Si elle est à 70% et que je sais
que j'aurais des pics de 10 fois la charge actuelle, je suis très mal.
Mais ça veux dire quoi 70% ? Rien du tout. Mémoire, cpu, bande passante ? Quel contexte ? Quelle charge ? Quelle application ? Distribuée ? Multithread ? Combien de processeurs ? Combien de clients ? De connexions ?
Chaque thread prendra le même nombre de ms pour s'exécuter hein... Moi, je dirai l'inverse, si ta machine tourne à 70%, c'est bien, au moins, elle sert à quelque chose.
Tu te focalises sur mes 70% alors que c'est tout le reste qui était intéressant. J'avais dis que ce % n'avait rien de significatif et que je prenais peur pour pas grand chose. Tu vois, tu te trompes de sujet.
Ensuite, dans ta liste d'interrogations, il y a des choses qui n'ont pas lieu d'être si on réfléchit un minimum. On a rien à faire du nombre de clients, de connexions, de proc, pour avoir peur d'une utilisation CPU(s) à 97% pour un unique serveur d'entreprise (donc, en général, serveur de fichier, ldap, dns, dhcp, smtp, etc.) Qu'il y ait 10 clients ou 10000, le problème est le même : le serveur est surchargé. Par contre, la solution sera certainement différente (et ce n'est pas du quad-opteron qui solutionnera forcément les choses) et dépendra du cas précis (si j'ai 10000 clients qd je suis à 97% mais qu'habituellement j'ai 1000 clients, je peux respirer).
Mais bon, tout ça tu le sais bien. Ce que je veux dire, c'est simplement qu'une appli légère, c'est légitime de le vouloir. Et, selon l'utilisation de UC, 70% ça peut être énorme ou pas. "si ta machine tourne à 70%, c'est bien, au moins, elle sert à quelque chose" : certes, mais là encore, ça dépend du moment. Si elle est à 70% et que je sais que j'aurais des pics de 10 fois la charge actuelle, je suis très mal.
Frederic Bonroy
Pascal Bourguignon kirjoitti:
Il suffit d'éviter les GUI au maximum.
Pourquoi se priver de ce confort? GUI ne rime pas forcément avec poids lourd, lorsqu'elles sont bien faites.
La logique est commerciale et salariale.
Dans le domaine professionnel, admettons. Dans le domaine amateur, non. Il y a suffisamment de programmeurs amateurs qui ne raisonnent pas en terme d'argent et qui produisent des programmes excessivement lourds. Effet de mode, laxisme, incompétence, tout ce qu'on veut...
Alors, si le gain de vitesse obtenu au bout d'une journée de travail d'un programmeur est inférieur à celui obtenu en achetant un processeur neuf, c'est vite vu...
Il n'est pas question de passer des heures à optimiser chaque ligne de code, mais bien d'éviter d'encombrer inutilement les programmes. Après tout, ajouter des trucs et des machins, c'est justement ça qui prend du temps et coûte donc de l'argent.
Pascal Bourguignon kirjoitti:
Il suffit d'éviter les GUI au maximum.
Pourquoi se priver de ce confort? GUI ne rime pas forcément avec poids
lourd, lorsqu'elles sont bien faites.
La logique est commerciale et salariale.
Dans le domaine professionnel, admettons. Dans le domaine amateur, non.
Il y a suffisamment de programmeurs amateurs qui ne raisonnent pas en
terme d'argent et qui produisent des programmes excessivement lourds.
Effet de mode, laxisme, incompétence, tout ce qu'on veut...
Alors, si le gain de vitesse obtenu au bout d'une journée de travail
d'un programmeur est inférieur à celui obtenu en achetant un
processeur neuf, c'est vite vu...
Il n'est pas question de passer des heures à optimiser chaque ligne de
code, mais bien d'éviter d'encombrer inutilement les programmes. Après
tout, ajouter des trucs et des machins, c'est justement ça qui prend du
temps et coûte donc de l'argent.
Pourquoi se priver de ce confort? GUI ne rime pas forcément avec poids lourd, lorsqu'elles sont bien faites.
La logique est commerciale et salariale.
Dans le domaine professionnel, admettons. Dans le domaine amateur, non. Il y a suffisamment de programmeurs amateurs qui ne raisonnent pas en terme d'argent et qui produisent des programmes excessivement lourds. Effet de mode, laxisme, incompétence, tout ce qu'on veut...
Alors, si le gain de vitesse obtenu au bout d'une journée de travail d'un programmeur est inférieur à celui obtenu en achetant un processeur neuf, c'est vite vu...
Il n'est pas question de passer des heures à optimiser chaque ligne de code, mais bien d'éviter d'encombrer inutilement les programmes. Après tout, ajouter des trucs et des machins, c'est justement ça qui prend du temps et coûte donc de l'argent.
Jean-Marc Desperrier
Jordy wrote:
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules)
Soit un peu moins de 6 bits par caractère, j'arrive à la conclusion que la clé est sur un peu plus de 370 bits.
et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Si la clé est vraiment parfaitement aléatoire, tu devrais avoir le temps d'y arriver avant que les trous noirs n'ait fini d'absorber l'intégralité de la matière de l'univers. Mais tu n'as pas beaucoup de marge.
Bon il est évident qu'il sera beaucoup plus facile de trouver une faille dans l'algorithme WPA2. Au niveau d'une dizaine de caractères pour la clé, on dépasse tout ce qui est atteignable en force brute par un individu, et les réseaux de machine ou hardware spécialisés n'augmentent la portée que de 2 ou 3 caractères.
Jordy wrote:
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire
Chiffres, lettres, majuscules, minuscules)
Soit un peu moins de 6 bits par caractère, j'arrive à la conclusion que
la clé est sur un peu plus de 370 bits.
et un Group Key Renewal de 3600
seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Si la clé est vraiment parfaitement aléatoire, tu devrais avoir le temps
d'y arriver avant que les trous noirs n'ait fini d'absorber
l'intégralité de la matière de l'univers.
Mais tu n'as pas beaucoup de marge.
Bon il est évident qu'il sera beaucoup plus facile de trouver une faille
dans l'algorithme WPA2. Au niveau d'une dizaine de caractères pour la
clé, on dépasse tout ce qui est atteignable en force brute par un
individu, et les réseaux de machine ou hardware spécialisés n'augmentent
la portée que de 2 ou 3 caractères.
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules)
Soit un peu moins de 6 bits par caractère, j'arrive à la conclusion que la clé est sur un peu plus de 370 bits.
et un Group Key Renewal de 3600 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Si la clé est vraiment parfaitement aléatoire, tu devrais avoir le temps d'y arriver avant que les trous noirs n'ait fini d'absorber l'intégralité de la matière de l'univers. Mais tu n'as pas beaucoup de marge.
Bon il est évident qu'il sera beaucoup plus facile de trouver une faille dans l'algorithme WPA2. Au niveau d'une dizaine de caractères pour la clé, on dépasse tout ce qui est atteignable en force brute par un individu, et les réseaux de machine ou hardware spécialisés n'augmentent la portée que de 2 ou 3 caractères.
