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?
Ne pas confondre qui TE font vivre, et qui NOUS font vivre. Tout le monde ne vit pas de la mauvaise éducation informatique des gens...
En parlant de mauvaise éducation, on est bien loin de la crypto, là.. .
-- ___________ _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Pour bien répondre avec Google, ne pas cliquer -'(__) « Répondre », mais « Afficher les options », _/___(_) puis cliquer « Répondre » (parmi les options).
Le 08.11.2006 10:49, :
Ne pas confondre qui TE font vivre, et qui NOUS font vivre. Tout le
monde ne vit pas de la mauvaise éducation informatique des gens...
En parlant de mauvaise éducation, on est bien loin de la crypto, là.. .
--
___________
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Pour bien répondre avec Google, ne pas cliquer
-'(__) « Répondre », mais « Afficher les options »,
_/___(_) puis cliquer « Répondre » (parmi les options).
Ne pas confondre qui TE font vivre, et qui NOUS font vivre. Tout le monde ne vit pas de la mauvaise éducation informatique des gens...
En parlant de mauvaise éducation, on est bien loin de la crypto, là.. .
-- ___________ _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Pour bien répondre avec Google, ne pas cliquer -'(__) « Répondre », mais « Afficher les options », _/___(_) puis cliquer « Répondre » (parmi les options).
Thierry
Jordy wrote:
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 ?
Si l'attaque est offline et cible la PSK, peu importe le renewal puisque tu as la clé.
Jordy wrote:
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 ?
Si l'attaque est offline et cible la PSK, peu importe le renewal puisque tu
as la clé.
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 ?
Si l'attaque est offline et cible la PSK, peu importe le renewal puisque tu as la clé.
Jordy
"Arnold McDonald (AMcD)" a écrit dans le message de news: 4550831a$0$7618$
Rien que de lire ça m'ôte toute envie de répondre !
Du calme ;-)
Je demandais juste une aproximation du nombre nécessaire de pc (de base) nécessaire pour casser un tel cryptage en force brute :-)
Genre 30 000 pc zombis ?
"Arnold McDonald (AMcD)" <killspammers@free.fr> a écrit dans le message de
news: 4550831a$0$7618$426a74cc@news.free.fr...
Rien que de lire ça m'ôte toute envie de répondre !
Du calme ;-)
Je demandais juste une aproximation du nombre nécessaire de pc (de base)
nécessaire pour casser un tel cryptage en force brute :-)
"Arnold McDonald (AMcD)" a écrit dans le message de news: 4550831a$0$7618$
Rien que de lire ça m'ôte toute envie de répondre !
Du calme ;-)
Je demandais juste une aproximation du nombre nécessaire de pc (de base) nécessaire pour casser un tel cryptage en force brute :-)
Genre 30 000 pc zombis ?
Erwann ABALEA
Hodie VII Id. Nov. MMVI est, Roland Garcia scripsit:
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?
pfff, 64 caractères ne seraient pas moins ridicules mais au moins ça ferait informatique.
Une sombre histoire de limite de taille de champ entre Windows et l'interface web chez Free...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- ``There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.'' Mark Twain
Hodie VII Id. Nov. MMVI est, Roland Garcia scripsit:
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?
pfff, 64 caractères ne seraient pas moins ridicules mais au moins ça ferait informatique.
Une sombre histoire de limite de taille de champ entre Windows et
l'interface web chez Free...
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
``There are basically two types of people.
People who accomplish things, and people who claim to have accomplished
things. The first group is less crowded.''
Mark Twain
Hodie VII Id. Nov. MMVI est, Roland Garcia scripsit:
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?
pfff, 64 caractères ne seraient pas moins ridicules mais au moins ça ferait informatique.
Une sombre histoire de limite de taille de champ entre Windows et l'interface web chez Free...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- ``There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.'' Mark Twain
On Tue, 7 Nov 2006 21:13:18 +0100, "Arnold McDonald (AMcD)" wrote:
Frederic Bonroy wrote:
Le problème c'est que certains programmeurs ont tendance à négliger le fait que leurs créations ne tourneront pratiquement jamais toutes seules sur un ordinateur.
Tu parles de mauvais programmeurs. Mais tu sais bien que ce n'est pas entièrement de leur faute non plus. Le problème est double, formation minable (entendu par des "profs" : désallouer, bof, avec 1 Go de RAM hein, l'OS se débrouillera) et pression (faut toujours que le soft soit prêt pour avant-hier).
En gros je suis assez d'accord avec tout ce que tu as dit.
Cependant je me demande si cette "programmation à la louche" n'est pas due au fait que dans les "hautezécoles" on se moque comme de l'an 40 de l'aspect "pratique" de l'informatique.
J'ai eu l'honneur et l'avantage de commencer la "petite" informatique dans les années 70 après avoir fait mes études sur des monstres IBM qu'il fallait gaver de cartes perforées de lignes de Fortran. En ces temps là, donc, je me suis payé un miraculeux (pour l'époque) TSR-80 de Tandy avec son écran TRES basse résolution et ses extraordinaires.... 4K de mémoire. Je me suis alors lancé dans la conception, en basic d'abord en assembleur plus tard, d'un petit programme Mastermind en mode texte (il n'y avait rien d'autre). J'ai sué pendant des heures pour faire entrer ce machin dans les 4K qui étaient à ma disposition. Ca aide à "optimiser" quand on n'a pas le choix. Sans compter qu'il fallait cinq bonnes minutes pour "charger/ décharger" le programme en utilisant le bête enregistreur à mini-cassette.
Quelques mois plus tard j'ai étendu (oh, miracle de la technologie) ma machine en lui ajoutant une extention de 64K (c'est Bizance) et un lecteur de disquette (180 K).
Quelques décénies plus tard j'ai cependant gardé de cette glorieuse époque la manie (ou plutot l'obsession) de compacter au maximum. Alors que je sais parfaitement que c'est devenu inutile. Mais, comme disait Monsieur Spock, "personne n'est parfait" ;-)
On Tue, 7 Nov 2006 21:13:18 +0100, "Arnold McDonald (AMcD)"
<killspammers@free.fr> wrote:
Frederic Bonroy wrote:
Le problème c'est que certains programmeurs ont tendance à négliger le
fait que leurs créations ne tourneront pratiquement jamais toutes
seules sur un ordinateur.
Tu parles de mauvais programmeurs. Mais tu sais bien que ce n'est pas
entièrement de leur faute non plus. Le problème est double, formation
minable (entendu par des "profs" : désallouer, bof, avec 1 Go de RAM hein,
l'OS se débrouillera) et pression (faut toujours que le soft soit prêt pour
avant-hier).
En gros je suis assez d'accord avec tout ce que tu as dit.
Cependant je me demande si cette "programmation à la louche" n'est
pas due au fait que dans les "hautezécoles" on se moque comme de l'an
40 de l'aspect "pratique" de l'informatique.
J'ai eu l'honneur et l'avantage de commencer la "petite"
informatique dans les années 70 après avoir fait mes études sur des
monstres IBM qu'il fallait gaver de cartes perforées de lignes de
Fortran. En ces temps là, donc, je me suis payé un miraculeux (pour
l'époque) TSR-80 de Tandy avec son écran TRES basse résolution et ses
extraordinaires.... 4K de mémoire. Je me suis alors lancé dans la
conception, en basic d'abord en assembleur plus tard, d'un petit
programme Mastermind en mode texte (il n'y avait rien d'autre). J'ai
sué pendant des heures pour faire entrer ce machin dans les 4K qui
étaient à ma disposition. Ca aide à "optimiser" quand on n'a pas le
choix. Sans compter qu'il fallait cinq bonnes minutes pour "charger/
décharger" le programme en utilisant le bête enregistreur à
mini-cassette.
Quelques mois plus tard j'ai étendu (oh, miracle de la technologie)
ma machine en lui ajoutant une extention de 64K (c'est Bizance) et un
lecteur de disquette (180 K).
Quelques décénies plus tard j'ai cependant gardé de cette glorieuse
époque la manie (ou plutot l'obsession) de compacter au maximum. Alors
que je sais parfaitement que c'est devenu inutile. Mais, comme disait
Monsieur Spock, "personne n'est parfait" ;-)
On Tue, 7 Nov 2006 21:13:18 +0100, "Arnold McDonald (AMcD)" wrote:
Frederic Bonroy wrote:
Le problème c'est que certains programmeurs ont tendance à négliger le fait que leurs créations ne tourneront pratiquement jamais toutes seules sur un ordinateur.
Tu parles de mauvais programmeurs. Mais tu sais bien que ce n'est pas entièrement de leur faute non plus. Le problème est double, formation minable (entendu par des "profs" : désallouer, bof, avec 1 Go de RAM hein, l'OS se débrouillera) et pression (faut toujours que le soft soit prêt pour avant-hier).
En gros je suis assez d'accord avec tout ce que tu as dit.
Cependant je me demande si cette "programmation à la louche" n'est pas due au fait que dans les "hautezécoles" on se moque comme de l'an 40 de l'aspect "pratique" de l'informatique.
J'ai eu l'honneur et l'avantage de commencer la "petite" informatique dans les années 70 après avoir fait mes études sur des monstres IBM qu'il fallait gaver de cartes perforées de lignes de Fortran. En ces temps là, donc, je me suis payé un miraculeux (pour l'époque) TSR-80 de Tandy avec son écran TRES basse résolution et ses extraordinaires.... 4K de mémoire. Je me suis alors lancé dans la conception, en basic d'abord en assembleur plus tard, d'un petit programme Mastermind en mode texte (il n'y avait rien d'autre). J'ai sué pendant des heures pour faire entrer ce machin dans les 4K qui étaient à ma disposition. Ca aide à "optimiser" quand on n'a pas le choix. Sans compter qu'il fallait cinq bonnes minutes pour "charger/ décharger" le programme en utilisant le bête enregistreur à mini-cassette.
Quelques mois plus tard j'ai étendu (oh, miracle de la technologie) ma machine en lui ajoutant une extention de 64K (c'est Bizance) et un lecteur de disquette (180 K).
Quelques décénies plus tard j'ai cependant gardé de cette glorieuse époque la manie (ou plutot l'obsession) de compacter au maximum. Alors que je sais parfaitement que c'est devenu inutile. Mais, comme disait Monsieur Spock, "personne n'est parfait" ;-)
Thierry
Jordy wrote:
Du calme ;-)
Je demandais juste une aproximation du nombre nécessaire de pc (de base) nécessaire pour casser un tel cryptage en force brute :-)
http://www.mirrors.wiretapped.net/security/vulnerability-assessment/aircrack/whax-aircrack-wpa/whax-aircrack-wpa.swf 40 clés/s, a toi de calculer...
Jordy wrote:
Du calme ;-)
Je demandais juste une aproximation du nombre nécessaire de pc (de base)
nécessaire pour casser un tel cryptage en force brute :-)
http://www.mirrors.wiretapped.net/security/vulnerability-assessment/aircrack/whax-aircrack-wpa/whax-aircrack-wpa.swf
40 clés/s, a toi de calculer...
Je demandais juste une aproximation du nombre nécessaire de pc (de base) nécessaire pour casser un tel cryptage en force brute :-)
http://www.mirrors.wiretapped.net/security/vulnerability-assessment/aircrack/whax-aircrack-wpa/whax-aircrack-wpa.swf 40 clés/s, a toi de calculer...
Xavier Roche
Tu parles de mauvais programmeurs. Mais tu sais bien que ce n'est pas entièrement de leur faute non plus.
On ne dénoncera jamais assez les dégâts que peuvent causer les wagons de "programmeurs" apprentis-charcutiers avec deux mois de formation avant leur intégration en SSII. Mais bon.
entendu par des "profs" : désallouer, bof, avec 1 Go de RAM hein, l'OS se débrouillera
Des noms, des noms!
et pression (faut toujours que le soft soit prêt pour avant-hier).
La pression augmente surtout la densité de bugs, amha. Le côté crade dépend d'autres facteurs (design, expérience, coding style..)
Alors, quand je vois des comiques dire que un gros soft fait ramer les autres, premier lol.
Non, d'expérience la priorité est prise en compte de manière assez efficace sous WIN32. C'est d'ailleurs un problème sur certains programmes qui ont la bonne idée de lancer des threads en priorité haute, et qui mettent a genoux le système (le do{}while(TRUE) en THREAD_PRIORITY_TIME_CRITICAL donne des résultats assez intéressants)
20.000 fois par jour, cette fonction crée une variable sur la pile, l'alloue
L'allocation sur la pile ne consomme rien, aucun locking, et souvent un seul appel par fonction (surprise, c'est dans le prélude de la fonction qu'on allouera le stackframe pour la fonction courante toute entière - feignasse de compilateur :p)
Un static !! Mondieukelorreur
Oui, quelle horreur. Outre l'absence d'interêt pour l'optimisation, cela pose quelques problèmes (réentrance, lisibilité, modularité..)
Tu crois que c'est plus efficace d'allouer une fois ou de faire une gestion locale comme décrite ci-dessus ?
L'allocation aujourd'hui est gérée de manière très aggressive - par exemple sous Linux, les petits blocs sont alloués sur un tas spécial, et les gros blocs en mmap(MAP_PRIVATE|MAP_ANONYMOUS)
Essayer d'utiliser du static pour optimiser est amha voué à l'échec. Par contre, dans certains cas, des pools privés sont efficaces.
temps de changement de page de la mémoire virtuelle ! C'est ben beau de
Oui, mais en général cela dépend de la charge du système. Si le système a plein de RAM, il ne descend pas les pages pour rien sur disque.
C'est paske t'es une truffe en programmation (hihihi). Certaines "optimisations" comme décrites plus haute, font perdre plus de temps qu'autre chose.
Mouais, bof. L'optimisation n'est pas qu'un problème de qualité de code, mais souvent de design *volontaire* (on préfère choisir un design dont on sait qu'il sera un peu lourdingue, mais en échange on gagne en temps de développement ou en souplesses - le design de COM sous Windows est amha un bon exemple: c'est lourdingue, mais très efficace)
Bon, on s'éloigne décidément du thème de fr.misc.cryptologie - je propose un FU2 vers fr.misc.divers vu qu'on part dans tous les sens
Tu parles de mauvais programmeurs. Mais tu sais bien que ce n'est pas
entièrement de leur faute non plus.
On ne dénoncera jamais assez les dégâts que peuvent causer les wagons de
"programmeurs" apprentis-charcutiers avec deux mois de formation avant
leur intégration en SSII. Mais bon.
entendu par des "profs" : désallouer, bof, avec 1 Go de RAM hein,
l'OS se débrouillera
Des noms, des noms!
et pression (faut toujours que le soft soit prêt pour
avant-hier).
La pression augmente surtout la densité de bugs, amha. Le côté crade
dépend d'autres facteurs (design, expérience, coding style..)
Alors, quand je vois des comiques dire que un gros soft
fait ramer les autres, premier lol.
Non, d'expérience la priorité est prise en compte de manière assez
efficace sous WIN32. C'est d'ailleurs un problème sur certains
programmes qui ont la bonne idée de lancer des threads en priorité
haute, et qui mettent a genoux le système (le do{}while(TRUE) en
THREAD_PRIORITY_TIME_CRITICAL donne des résultats assez intéressants)
20.000 fois par jour, cette fonction crée une variable sur la pile,
l'alloue
L'allocation sur la pile ne consomme rien, aucun locking, et souvent un
seul appel par fonction (surprise, c'est dans le prélude de la fonction
qu'on allouera le stackframe pour la fonction courante toute entière -
feignasse de compilateur :p)
Un static !! Mondieukelorreur
Oui, quelle horreur. Outre l'absence d'interêt pour l'optimisation, cela
pose quelques problèmes (réentrance, lisibilité, modularité..)
Tu crois que c'est plus
efficace d'allouer une fois ou de faire une gestion locale comme décrite
ci-dessus ?
L'allocation aujourd'hui est gérée de manière très aggressive - par
exemple sous Linux, les petits blocs sont alloués sur un tas spécial, et
les gros blocs en mmap(MAP_PRIVATE|MAP_ANONYMOUS)
Essayer d'utiliser du static pour optimiser est amha voué à l'échec. Par
contre, dans certains cas, des pools privés sont efficaces.
temps de changement de page de la mémoire virtuelle ! C'est ben beau de
Oui, mais en général cela dépend de la charge du système. Si le système
a plein de RAM, il ne descend pas les pages pour rien sur disque.
C'est paske t'es une truffe en programmation (hihihi). Certaines
"optimisations" comme décrites plus haute, font perdre plus de temps
qu'autre chose.
Mouais, bof. L'optimisation n'est pas qu'un problème de qualité de code,
mais souvent de design *volontaire* (on préfère choisir un design dont
on sait qu'il sera un peu lourdingue, mais en échange on gagne en temps
de développement ou en souplesses - le design de COM sous Windows est
amha un bon exemple: c'est lourdingue, mais très efficace)
Bon, on s'éloigne décidément du thème de fr.misc.cryptologie - je
propose un FU2 vers fr.misc.divers vu qu'on part dans tous les sens
Tu parles de mauvais programmeurs. Mais tu sais bien que ce n'est pas entièrement de leur faute non plus.
On ne dénoncera jamais assez les dégâts que peuvent causer les wagons de "programmeurs" apprentis-charcutiers avec deux mois de formation avant leur intégration en SSII. Mais bon.
entendu par des "profs" : désallouer, bof, avec 1 Go de RAM hein, l'OS se débrouillera
Des noms, des noms!
et pression (faut toujours que le soft soit prêt pour avant-hier).
La pression augmente surtout la densité de bugs, amha. Le côté crade dépend d'autres facteurs (design, expérience, coding style..)
Alors, quand je vois des comiques dire que un gros soft fait ramer les autres, premier lol.
Non, d'expérience la priorité est prise en compte de manière assez efficace sous WIN32. C'est d'ailleurs un problème sur certains programmes qui ont la bonne idée de lancer des threads en priorité haute, et qui mettent a genoux le système (le do{}while(TRUE) en THREAD_PRIORITY_TIME_CRITICAL donne des résultats assez intéressants)
20.000 fois par jour, cette fonction crée une variable sur la pile, l'alloue
L'allocation sur la pile ne consomme rien, aucun locking, et souvent un seul appel par fonction (surprise, c'est dans le prélude de la fonction qu'on allouera le stackframe pour la fonction courante toute entière - feignasse de compilateur :p)
Un static !! Mondieukelorreur
Oui, quelle horreur. Outre l'absence d'interêt pour l'optimisation, cela pose quelques problèmes (réentrance, lisibilité, modularité..)
Tu crois que c'est plus efficace d'allouer une fois ou de faire une gestion locale comme décrite ci-dessus ?
L'allocation aujourd'hui est gérée de manière très aggressive - par exemple sous Linux, les petits blocs sont alloués sur un tas spécial, et les gros blocs en mmap(MAP_PRIVATE|MAP_ANONYMOUS)
Essayer d'utiliser du static pour optimiser est amha voué à l'échec. Par contre, dans certains cas, des pools privés sont efficaces.
temps de changement de page de la mémoire virtuelle ! C'est ben beau de
Oui, mais en général cela dépend de la charge du système. Si le système a plein de RAM, il ne descend pas les pages pour rien sur disque.
C'est paske t'es une truffe en programmation (hihihi). Certaines "optimisations" comme décrites plus haute, font perdre plus de temps qu'autre chose.
Mouais, bof. L'optimisation n'est pas qu'un problème de qualité de code, mais souvent de design *volontaire* (on préfère choisir un design dont on sait qu'il sera un peu lourdingue, mais en échange on gagne en temps de développement ou en souplesses - le design de COM sous Windows est amha un bon exemple: c'est lourdingue, mais très efficace)
Bon, on s'éloigne décidément du thème de fr.misc.cryptologie - je propose un FU2 vers fr.misc.divers vu qu'on part dans tous les sens
Arnold McDonald \(AMcD\)
Xavier Roche wrote:
On ne dénoncera jamais assez les dégâts que peuvent causer les wagons de "programmeurs" apprentis-charcutiers avec deux mois de formation avant leur intégration en SSII. Mais bon.
S'ils n'y avait qu'eux... Il y a aussi des semi-remorques de bac+x largement incompétents.
Alors, quand je vois des comiques dire que un gros soft fait ramer les autres, premier lol.
Non, d'expérience la priorité est prise en compte de manière assez efficace sous WIN32.
Je confirme.
C'est d'ailleurs un problème sur certains programmes qui ont la bonne idée de lancer des threads en priorité haute, et qui mettent a genoux le système (le do{}while(TRUE) en THREAD_PRIORITY_TIME_CRITICAL donne des résultats assez intéressants)
Hors composant système ou vraiment critique, il ets parfaitement stupide d'utiliser THREAD_PRIORITY_TIME_CRITICAL.
L'allocation sur la pile ne consomme rien, aucun locking, et souvent un seul appel par fonction (surprise, c'est dans le prélude de la fonction qu'on allouera le stackframe pour la fonction courante toute entière - feignasse de compilateur :p)
On doit pas coder pareil. Allouer sur la pile, c'est juste décrémenter un peu plus ESP. Certes, ça fait rien. Mais ce n'est pas le problème que j'évoque :-). Ce dont je parle est le fait d'allouer à chaque entrée de fonction. Cela signifie qu'à chaque entrée dans la fonction, tu va sutiliser une fonction pour allouer, le système va mettre à zéro (ou une autre valeur) ce bloc mémoire, et en sortie une autre fonction pour désallouer. Ces trois fonctions appelées des milliers de fois, ça prend du temps.
Un static !! Mondieukelorreur
Oui, quelle horreur. Outre l'absence d'interêt pour l'optimisation, cela pose quelques problèmes (réentrance, lisibilité, modularité..)
Cela permet justement une énorme optimisation. Moi, si je dois allouer 100 Mo 10.000 fois par jour, je le fais UNE fois en static et basta. Je ne dis pas que c'est beau. Je dis que c'est optimisé (voir ci-dessus). Problèmes de réentrance ? Un static ??? Faut apprendre à synchroniser hein :-).
L'allocation aujourd'hui est gérée de manière très aggressive - par exemple sous Linux, les petits blocs sont alloués sur un tas spécial, et les gros blocs en mmap(MAP_PRIVATE|MAP_ANONYMOUS)
Oui. Mais il y a allocation et initialisation. Par exemple, pour manipuler des images, je vais vouloir initialiser la mémoire allouée avec telle ou telle valeur. Et ça, ça chiffre vite si tu manipules des Mo de mémoire. À une époque je codais des trucs pour moteurs de rendu en OpenGL, je peux te certifier qu'allouer les buffers annexes en static pour les opérations de double-buffering, stencil, etc, ça pulvérisait les temps de rendu hein...
Essayer d'utiliser du static pour optimiser est amha voué à l'échec.
Cela dépend des cas. De toute façon, l'optimisation de code n'est pas affaire de théorie mais de mesure et de test.
Par contre, dans certains cas, des pools privés sont efficaces.
Certes.
Mouais, bof. L'optimisation n'est pas qu'un problème de qualité de code,
Toutafé
mais souvent de design *volontaire* (on préfère choisir un design dont on sait qu'il sera un peu lourdingue, mais en échange on gagne en temps de développement ou en souplesses
Par exemple.
Bon, on s'éloigne décidément du thème de fr.misc.cryptologie - je propose un FU2 vers fr.misc.divers vu qu'on part dans tous les sens
C'est bon pour moi EOT.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
Xavier Roche wrote:
On ne dénoncera jamais assez les dégâts que peuvent causer les wagons
de "programmeurs" apprentis-charcutiers avec deux mois de formation
avant leur intégration en SSII. Mais bon.
S'ils n'y avait qu'eux... Il y a aussi des semi-remorques de bac+x largement
incompétents.
Alors, quand je vois des comiques dire que un gros soft
fait ramer les autres, premier lol.
Non, d'expérience la priorité est prise en compte de manière assez
efficace sous WIN32.
Je confirme.
C'est d'ailleurs un problème sur certains
programmes qui ont la bonne idée de lancer des threads en priorité
haute, et qui mettent a genoux le système (le do{}while(TRUE) en
THREAD_PRIORITY_TIME_CRITICAL donne des résultats assez intéressants)
Hors composant système ou vraiment critique, il ets parfaitement stupide
d'utiliser THREAD_PRIORITY_TIME_CRITICAL.
L'allocation sur la pile ne consomme rien, aucun locking, et souvent
un seul appel par fonction (surprise, c'est dans le prélude de la
fonction qu'on allouera le stackframe pour la fonction courante toute
entière - feignasse de compilateur :p)
On doit pas coder pareil. Allouer sur la pile, c'est juste décrémenter un
peu plus ESP. Certes, ça fait rien. Mais ce n'est pas le problème que
j'évoque :-). Ce dont je parle est le fait d'allouer à chaque entrée de
fonction. Cela signifie qu'à chaque entrée dans la fonction, tu va sutiliser
une fonction pour allouer, le système va mettre à zéro (ou une autre valeur)
ce bloc mémoire, et en sortie une autre fonction pour désallouer. Ces trois
fonctions appelées des milliers de fois, ça prend du temps.
Un static !! Mondieukelorreur
Oui, quelle horreur. Outre l'absence d'interêt pour l'optimisation,
cela pose quelques problèmes (réentrance, lisibilité, modularité..)
Cela permet justement une énorme optimisation. Moi, si je dois allouer 100
Mo 10.000 fois par jour, je le fais UNE fois en static et basta. Je ne dis
pas que c'est beau. Je dis que c'est optimisé (voir ci-dessus). Problèmes de
réentrance ? Un static ??? Faut apprendre à synchroniser hein :-).
L'allocation aujourd'hui est gérée de manière très aggressive - par
exemple sous Linux, les petits blocs sont alloués sur un tas spécial,
et les gros blocs en mmap(MAP_PRIVATE|MAP_ANONYMOUS)
Oui. Mais il y a allocation et initialisation. Par exemple, pour manipuler
des images, je vais vouloir initialiser la mémoire allouée avec telle ou
telle valeur. Et ça, ça chiffre vite si tu manipules des Mo de mémoire. À
une époque je codais des trucs pour moteurs de rendu en OpenGL, je peux te
certifier qu'allouer les buffers annexes en static pour les opérations de
double-buffering, stencil, etc, ça pulvérisait les temps de rendu hein...
Essayer d'utiliser du static pour optimiser est amha voué à l'échec.
Cela dépend des cas. De toute façon, l'optimisation de code n'est pas
affaire de théorie mais de mesure et de test.
Par contre, dans certains cas, des pools privés sont efficaces.
Certes.
Mouais, bof. L'optimisation n'est pas qu'un problème de qualité de
code,
Toutafé
mais souvent de design *volontaire* (on préfère choisir un
design dont on sait qu'il sera un peu lourdingue, mais en échange on
gagne en temps de développement ou en souplesses
Par exemple.
Bon, on s'éloigne décidément du thème de fr.misc.cryptologie - je
propose un FU2 vers fr.misc.divers vu qu'on part dans tous les sens
On ne dénoncera jamais assez les dégâts que peuvent causer les wagons de "programmeurs" apprentis-charcutiers avec deux mois de formation avant leur intégration en SSII. Mais bon.
S'ils n'y avait qu'eux... Il y a aussi des semi-remorques de bac+x largement incompétents.
Alors, quand je vois des comiques dire que un gros soft fait ramer les autres, premier lol.
Non, d'expérience la priorité est prise en compte de manière assez efficace sous WIN32.
Je confirme.
C'est d'ailleurs un problème sur certains programmes qui ont la bonne idée de lancer des threads en priorité haute, et qui mettent a genoux le système (le do{}while(TRUE) en THREAD_PRIORITY_TIME_CRITICAL donne des résultats assez intéressants)
Hors composant système ou vraiment critique, il ets parfaitement stupide d'utiliser THREAD_PRIORITY_TIME_CRITICAL.
L'allocation sur la pile ne consomme rien, aucun locking, et souvent un seul appel par fonction (surprise, c'est dans le prélude de la fonction qu'on allouera le stackframe pour la fonction courante toute entière - feignasse de compilateur :p)
On doit pas coder pareil. Allouer sur la pile, c'est juste décrémenter un peu plus ESP. Certes, ça fait rien. Mais ce n'est pas le problème que j'évoque :-). Ce dont je parle est le fait d'allouer à chaque entrée de fonction. Cela signifie qu'à chaque entrée dans la fonction, tu va sutiliser une fonction pour allouer, le système va mettre à zéro (ou une autre valeur) ce bloc mémoire, et en sortie une autre fonction pour désallouer. Ces trois fonctions appelées des milliers de fois, ça prend du temps.
Un static !! Mondieukelorreur
Oui, quelle horreur. Outre l'absence d'interêt pour l'optimisation, cela pose quelques problèmes (réentrance, lisibilité, modularité..)
Cela permet justement une énorme optimisation. Moi, si je dois allouer 100 Mo 10.000 fois par jour, je le fais UNE fois en static et basta. Je ne dis pas que c'est beau. Je dis que c'est optimisé (voir ci-dessus). Problèmes de réentrance ? Un static ??? Faut apprendre à synchroniser hein :-).
L'allocation aujourd'hui est gérée de manière très aggressive - par exemple sous Linux, les petits blocs sont alloués sur un tas spécial, et les gros blocs en mmap(MAP_PRIVATE|MAP_ANONYMOUS)
Oui. Mais il y a allocation et initialisation. Par exemple, pour manipuler des images, je vais vouloir initialiser la mémoire allouée avec telle ou telle valeur. Et ça, ça chiffre vite si tu manipules des Mo de mémoire. À une époque je codais des trucs pour moteurs de rendu en OpenGL, je peux te certifier qu'allouer les buffers annexes en static pour les opérations de double-buffering, stencil, etc, ça pulvérisait les temps de rendu hein...
Essayer d'utiliser du static pour optimiser est amha voué à l'échec.
Cela dépend des cas. De toute façon, l'optimisation de code n'est pas affaire de théorie mais de mesure et de test.
Par contre, dans certains cas, des pools privés sont efficaces.
Certes.
Mouais, bof. L'optimisation n'est pas qu'un problème de qualité de code,
Toutafé
mais souvent de design *volontaire* (on préfère choisir un design dont on sait qu'il sera un peu lourdingue, mais en échange on gagne en temps de développement ou en souplesses
Par exemple.
Bon, on s'éloigne décidément du thème de fr.misc.cryptologie - je propose un FU2 vers fr.misc.divers vu qu'on part dans tous les sens
C'est bon pour moi EOT.
-- Arnold McDonald (AMcD)
http://arnold.mcdonald.free.fr/
xorax
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 36 00 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Merci pour vos réponses :-)
Je ne suis pas très axé WPA mais il me semble qu'en 3600 secondes ya le temps de trouvé une clef static s'il y a du réseau.
par contre pour la casser avec AES... la ça risque d'être long.
PS: bordel vous pouvez pas vous barrez sur un autre thread avec discussion hors sujet !!!
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire
Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 36 00
seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Merci pour vos réponses :-)
Je ne suis pas très axé WPA mais il me semble qu'en 3600 secondes ya
le temps de trouvé une clef static s'il y a du réseau.
par contre pour la casser avec AES... la ça risque d'être long.
PS: bordel vous pouvez pas vous barrez sur un autre thread avec
discussion hors sujet !!!
WPA2-Personal TKIP+AES avec une clef de 63 caractères (pure aléatoire Chiffres, lettres, majuscules, minuscules) et un Group Key Renewal de 36 00 seconds? Avec un P4 3Ghz par exemple?
Est ce gourmand en ressource?
Merci pour vos réponses :-)
Je ne suis pas très axé WPA mais il me semble qu'en 3600 secondes ya le temps de trouvé une clef static s'il y a du réseau.
par contre pour la casser avec AES... la ça risque d'être long.
PS: bordel vous pouvez pas vous barrez sur un autre thread avec discussion hors sujet !!!
