C'est un choix sécurité contre vitesse.
Ça ne change rien à la sécurité d'un point de vue purement crypto : un mot de passe avec 32 bits d'entropie reste un mot de passe avec 32 bits de sécurité, le reste est dans la constante (le 'grand O') de la complexité. L'attaque brute-force augmente linéairement avec le coût de calcul du hachage du mot de passe, mais le coût est augmenté également linéairement pour le vérificateur légitime du mot de passe, ce qui est loin d'être bénéfique (déjà que tout le monde se plaint du coût de la sécurité en termes de performances...).
Ce qui augmente vraiment (exponentiellement, à coût négligeable) la sécurité est d'augmenter l'entropie des mots de passe : ajouter 1 bit d'entropie ne change rien au temps de calcul du hachage, mais double le coût de l'attaque brute-force.
Augmenter la complexité des fonctions de hachage a vraiment peu de sens en pratique contre un attaquant off-line (qui récupère le haché et le bruteforce avec une ferme de FPGA/CPU/GPU/PS3/etc. etc., puisqu'il est possible de réaliser d'énormes économies d'échelle sur le matériel électronique : doubler la puissance de la machine à bruteforcer coûte moins de 2 fois le coût initial). À la limite, ça peut servir contre un attaquant on-line pour l'empêcher de vérifier plus de n mots de passe à la seconde, mais un timer fait tout aussi bien.
Démontrez un rapport "Il suffit de voir les critères pour l'attribution de sha3"!
Ce sont les présentations du NIST aux différentes conférences SHA-3 autour de CRYPTO des années précédentes. Ils se sont basés sur un article qui comparait les performances des implémentations hard des différents finalistes et ont choisi le plus rapide, à savoir Keccak. Par contre ça n'a sans doute rien à voir avec une quelconque facilitation de brute-force de mots de passe.
[^] # Re: pas forcément
Posté par khivapia . En réponse au journal Qu'un algo de chiffrement soit cassé, est-ce important pour nos PETITS secrets ?. Évalué à 3.
C'est un choix sécurité contre vitesse.
Ça ne change rien à la sécurité d'un point de vue purement crypto : un mot de passe avec 32 bits d'entropie reste un mot de passe avec 32 bits de sécurité, le reste est dans la constante (le 'grand O') de la complexité. L'attaque brute-force augmente linéairement avec le coût de calcul du hachage du mot de passe, mais le coût est augmenté également linéairement pour le vérificateur légitime du mot de passe, ce qui est loin d'être bénéfique (déjà que tout le monde se plaint du coût de la sécurité en termes de performances...).
Ce qui augmente vraiment (exponentiellement, à coût négligeable) la sécurité est d'augmenter l'entropie des mots de passe : ajouter 1 bit d'entropie ne change rien au temps de calcul du hachage, mais double le coût de l'attaque brute-force.
Augmenter la complexité des fonctions de hachage a vraiment peu de sens en pratique contre un attaquant off-line (qui récupère le haché et le bruteforce avec une ferme de FPGA/CPU/GPU/PS3/etc. etc., puisqu'il est possible de réaliser d'énormes économies d'échelle sur le matériel électronique : doubler la puissance de la machine à bruteforcer coûte moins de 2 fois le coût initial). À la limite, ça peut servir contre un attaquant on-line pour l'empêcher de vérifier plus de n mots de passe à la seconde, mais un timer fait tout aussi bien.
Démontrez un rapport "Il suffit de voir les critères pour l'attribution de sha3"!
Ce sont les présentations du NIST aux différentes conférences SHA-3 autour de CRYPTO des années précédentes. Ils se sont basés sur un article qui comparait les performances des implémentations hard des différents finalistes et ont choisi le plus rapide, à savoir Keccak. Par contre ça n'a sans doute rien à voir avec une quelconque facilitation de brute-force de mots de passe.