Très court journal, avec la sortie d'une nouvelle version de BLAKE3 : https://github.com/BLAKE3-team/BLAKE3/releases/tag/1.7.0
Cette version implémente le parallélisme dans la version C, qui atteint donc des performances équivalentes à l'implémentation en Rust.
Pour rappel, BLAKE3 est un algorithme de condensat cryptographique (hash function) qui atteint des performances réellement impressionnantes… sur un seul processeur. Et comme il a le bon goût d'être parallélisable, ça marche encore plus vite. Comme dirait Doc : « Marty, c'est incroyable ! ».
Bref, je pense qu'il manque un peu de test de robustesse pour s'assurer que BLAKE3 est vraiment solide pour du condensat cryptographique, mais à part ça, j'aimerais vraiment le voir plus utilisé que le reste.
# Formulation amusante
Posté par Benoît Sibaud (site web personnel) . Évalué à 9 (+6/-0).
Formulé ainsi, ça fait un peu « il manque juste la preuve qu'il remplit sa fonction de base, mais sinon il est super ». Tendance « on ne sait pas si le goût et la consommabilité de cette eau de Javel sont ok, mais ça pourrait faire du Bourgogne Grand Cru à vraiment pas cher ».
(BLAKE3 est peut-être très bien par ailleurs, je n'en ai aucune idée, je ne réagis qu'à la petite phrase finale du journal)
[^] # Re: Formulation amusante
Posté par Glandos . Évalué à 5 (+3/-0).
Oooooh, tout de suite :)
En fait, c'était vraiment une question plus ouverte : est-ce que BLAKE3 est simplement méconnu, ou bien est-ce que c'est le comportement habituel de ne pas se précipiter sur le nouveau truc à la mode ?
[^] # Re: Formulation amusante
Posté par Mimoza . Évalué à 4 (+2/-0).
En général tout ce qui tourne autour de la sécu/crypto est assez conservateur, donc met de temps a s’implanté surtout s’il n’y a pas de sentiment d’urgence.
[^] # Re: Formulation amusante
Posté par aiolos . Évalué à 4 (+2/-0).
BLAKE2 a fait parti du peloton de tête pour SHA-3 ; arrivé en phase finale, il a cependant perdu la compétition face à Keccak. C'est le signe d'une bonne qualité, mais pas forcement dans toutes les situations. Lors de la sélection d'un algorithme dans ces compétitions, on va chercher un algo unique qui va offrir le meilleur compromis sur l'ensemble des circonstances (consommation CPU, consommation mémoire, nombre de cycles de l'implémentation software ou surface de l'implémentation matérielle, etc.). Je ne connais pas les détails de la sélection de Keccak par rapport à BLAKE, donc je ne peux pas détailler ici, mais Keccak avait l'avantage et l'inconvénient de reposer sur une toute nouvelle technique, les fonctions éponges, là où la famille BLAKE utilise des primitives de ChaCha20.
Ceci dit, ça n'empêche pas son utilisation dans des contextes moins normé, BLAKE2 reste un très bon algorithme, et BLAKE3 ajoute une grande parallélisation grâce à une structure d'arbre binaire, d'après ce que j'en ai lu. Une ou l'autre des variantes de BLAKE2 est notamment utilisé dans Argon2, Chef, Wireguard, diverses cryptomonaies (Zcash par exemple) et dans le générateur pseudo-aléatoire de Linux.
# J'ai pas toujours envie que mon hash crypto aille vite...
Posté par YetiBarBar . Évalué à 4 (+3/-0).
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.
[^] # Re: J'ai pas toujours envie que mon hash crypto aille vite...
Posté par Colin Pitrat (site web personnel) . Évalué à 3 (+1/-0).
Pareil, rapide et parallelisable pour un hash cryptographique ça ne me paraît pas souhaitable. Là où ça peut être utile c'est pour des tables de hachage (hashmap) où de bonnes propriétés qu'on cherche aussi sur des hashs cryptos sont souhaitables (difficulté de création de collisions en particulier, pour éviter les déni de service consistant à transformer une table de hachage en liste) mais où la rapidité est bienvenue quand même.
[^] # Re: J'ai pas toujours envie que mon hash crypto aille vite...
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+9/-0).
Page d'accueil du projet sur GitHub
[^] # Re: J'ai pas toujours envie que mon hash crypto aille vite...
Posté par aiolos . Évalué à 3 (+1/-0).
Certes, mais ce n'est pas parce qu'il existe des cas d'usages où c'est intéressant qu'il n'existe pas de cas d'usage où on souhaite la rapidité… Le hachage est beaucoup utilisé dans les protocoles réseaux pour le contrôle d'intégrité (contre des altérations volontaires ou accidentelles), avec ou sans clef (HMAC notament) ou pour de la signature. Dans ce cas, quand tu es dans les couches basses, la crypto est utilisée de façon transparente pour les couches plus hautes et toute la crypto est un overhead, et donc tu va vouloir le diminuer au maximum.
[^] # Re: J'ai pas toujours envie que mon hash crypto aille vite...
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
Les propriétés sont largement indépendantes en fait :
/dev/zeroest un mauvais algo de condensat, très mauvais en termes de crypto mais très rapide.MD5 est un bon algo de condensat, rapide, mais plus au niveau pour de la crypto.
Etc.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.