Régler hashcat pour un vrai débit GPU

La première chose que l'on fait avec un nouveau GPU, c'est lancer un benchmark et citer le chiffre vedette. Ce chiffre est vrai pendant une trentaine de secondes. Le débit soutenu sur une vraie attaque, carte chaude, avec le kernel que votre empreinte utilise réellement, voilà la valeur qui décide si un travail se termine ce soir ou la semaine prochaine. Le réglage, c'est l'écart entre les deux.

Benchmarkez le mode que vous exécutez

hashcat -b parcourt chaque mode et affiche un débit pour chacun. Utile pour comparer des cartes, inutile pour planifier un travail précis, car l'algorithme domine tout.

hashcat -b              # benchmark complet, tous les modes
hashcat -b -m 0         # MD5 uniquement
hashcat -b -m 3200      # bcrypt uniquement

Lancez ces deux-là et l'écart raconte toute l'histoire. MD5 sur un GPU actuel se mesure en dizaines de milliards de hash par seconde (lisez 21000.0 MH/s comme 21 milliards de H/s). bcrypt au coût 5 sur la même carte atterrit dans les basses dizaines de milliers. Ce n'est pas une coquille, ce sont six ou sept ordres de grandeur. Sur les hash rapides, le GPU fait tout le travail et le réglage compte énormément. Sur les hash lents, l'algorithme a déjà gagné : une carte plus rapide ne vous achète presque rien, et votre effort doit aller dans la liste de mots.

Profils de charge

-w règle l'agressivité avec laquelle hashcat alimente le GPU, de 1 à 4.

hashcat -m 0 -w 3 hashes.txt rockyou.txt

Le profil 1 est destiné à une machine que vous utilisez activement. Le profil 3 est par défaut et convient à la plupart des exécutions dédiées. Le profil 4 grappille les derniers pourcents en confiant à la carte des lots très longs, et sur un poste de bureau où le même GPU pilote votre écran, cela se retourne contre vous : l'affichage saccade, la saisie traîne, et sur certains pilotes le chien de garde tue le kernel parce qu'il ne rend pas la main. Machine sans affichage, -w 4. Poste de travail quotidien, plafonnez à 3 et ne soyez pas surpris si 4 rend la machine inutilisable pour un gain de vitesse à un chiffre.

Les kernels optimisés et le piège de la longueur

-O active les kernels optimisés. Ils sont plus rapides, parfois de loin. Le piège est un plafond strict sur la longueur des candidats, souvent 31 caractères ou moins selon le mode, et hashcat ne vous préviendra pas en cours d'exécution qu'il a ignoré tout ce qui était plus long.

hashcat -m 0 -O hashes.txt rockyou.txt

C'est le piège abordé dans trouver le bon mode hashcat : une exécution propre sans aucun résultat ne prouve pas que le mot de passe est incassable, elle prouve peut-être que -O n'a jamais essayé les longs. Utilisez -O pour les hash rapides et les masques courts, là où vous savez que le plafond de longueur est sans conséquence. Abandonnez-le dès que vous soupçonnez des phrases de passe longues, et relancez sans lui avant de déclarer une empreinte incassée.

Le throttling thermique explique la chute de vos chiffres

Les benchmarks tournent à froid. Dix minutes après le début d'un vrai travail, la puce est chaude, la carte atteint sa limite de température, et le firmware baisse les fréquences pour se protéger. Le débit soutenu se stabilise sous le pic, parfois très en dessous dans un boîtier exigu mal ventilé.

hashcat -m 0 -w 3 --hwmon-temp-abort=90 hashes.txt rockyou.txt

Surveillez la température et le ventilateur avec la supervision matérielle (active par défaut : ne passez pas l'option de désactivation). Jugez une carte sur son chiffre en régime stable, une fois chauffée. Si les fréquences chutent en charge, la solution est la ventilation et une courbe de ventilateur, pas une option hashcat.

Multi-GPU et candidats lents

-d sélectionne les périphériques par index : vous pouvez ainsi épingler un travail à des cartes précises ou répartir la charge entre elles.

hashcat -I                                    # lister les index des périphériques
hashcat -m 3200 -d 1,2 hashes.txt rockyou.txt # exécuter sur les cartes 1 et 2

-S bascule sur le chemin des candidats lents. Contre toute intuition, pour les hash lents comme bcrypt cela peut être plus rapide, car le goulot d'étranglement est l'empreinte elle-même plutôt que la génération de candidats, et le chemin lent alimente le pipeline plus efficacement. Benchmarkez dans les deux sens sur votre empreinte : ne supposez rien.

Découper les grosses attaques

Un espace de clés qui prend une semaine sur une seule machine doit être découpé. -s (skip) et -l (limit), aussi écrits --skip et --limit, découpent une tranche contiguë de l'espace de clés pour confier chaque segment à une machine différente.

hashcat -m 0 -a 3 hashes.txt ?a?a?a?a?a?a?a?a --keyspace   # taille totale
hashcat -m 0 -a 3 hashes.txt ?a?a?a?a?a?a?a?a -s 0           -l 5000000000
hashcat -m 0 -a 3 hashes.txt ?a?a?a?a?a?a?a?a -s 5000000000  -l 5000000000

Interrogez --keyspace, divisez par le nombre de travailleurs, et distribuez les tranches. C'est de la distribution artisanale et cela fonctionne pour une poignée de nœuds. Au-delà, le coût de la coordination manuelle l'emporte sur une vraie infrastructure distribuée.

Le calcul de la location cloud, honnêtement

Louer des GPU à l'heure en vaut vraiment la peine pour une rafale courte sur un hash rapide. Quelques heures sur du matériel loué peuvent remplacer des jours sur votre propre carte, et vous ne payez que la durée. Là où cela cesse d'avoir du sens, c'est le cassage soutenu de hash lents. bcrypt se moque que vous ayez loué huit cartes haut de gamme : le facteur de coût plafonne vos essais par seconde et par périphérique, donc vous payez des tarifs horaires élevés pour grignoter un espace de clés que l'algorithme a précisément été conçu pour rendre coûteux à grignoter. Louez pour des rafales sur hash rapides et l'épuisement de masques courts. Ne louez pas une flotte pour casser en force brute un KDF bien configuré, car le calcul qui protège le défenseur le protège aussi contre votre flotte louée.