Je suis interpellé par le "ça va vite, c'est parallèlisable, vivement que tout le monde utilise ça", pour un algo de hashage!
Quand je choisis un algo de hashage, j'ai quelques critères à prendre en compte:
- ai-je vraiment besoin d'une résistance cryptographique?
- ai-je besoin que ça soit facilement optimisable pour aller vite ou au contraire, dois-je pourrir volontairement les performances?
Aussi surprenant que celà puisse paraitre, disposer d'algo de hash difficilement parallèlisable et long à faire tourner est un cas d'usage très fréquent!
Par exemple, pour le stockage de mot de passe, on en est arrivé à implémenter des algo où on hash plusieurs centaines de fois la sortie de la fonction de hashage en chaine pour volontairement augmenter la puissance de calcul nécessaire à un bruteforce.
# J'ai pas toujours envie que mon hash crypto aille vite...
Posté par YetiBarBar . En réponse au journal BLAKE3, le condensat cryptographique qui laisse les autres sur le quai. Évalué à 8.
Je suis interpellé par le "ça va vite, c'est parallèlisable, vivement que tout le monde utilise ça", pour un algo de hashage!
Quand je choisis un algo de hashage, j'ai quelques critères à prendre en compte:
- ai-je vraiment besoin d'une résistance cryptographique?
- ai-je besoin que ça soit facilement optimisable pour aller vite ou au contraire, dois-je pourrir volontairement les performances?
Aussi surprenant que celà puisse paraitre, disposer d'algo de hash difficilement parallèlisable et long à faire tourner est un cas d'usage très fréquent!
Par exemple, pour le stockage de mot de passe, on en est arrivé à implémenter des algo où on hash plusieurs centaines de fois la sortie de la fonction de hashage en chaine pour volontairement augmenter la puissance de calcul nécessaire à un bruteforce.