• [^] # Re: .

    Posté par . En réponse à la dépêche Les clients officiels de Ryzom migrent de la version 2.1 à la version 3.0. Évalué à 6. Dernière modification le 19 octobre 2016 à 22:13.

    C'est du code du domaine public qu'ils ont repris sans regarder les détails (de toute façon éditer toi-même du code cryptographique fourni par "des gens qui s'y connaissent" serait aussi folie). En l'occurence le code se retrouve aussi dans la libc musl qui est bien considérée dans l'embarqué par exemple.

    Je ne dis pas que le code est joli, je dis que c'est du code standard que des gens de cette communauté vont écrire. Peut-être que tu réagis négativement et vulgairement car tes goûts esthétiques te font préférer d'autres langages que le C, ou un style plus haut niveau que celui des gens qui écrivent de la crypto pour leur job. Peut-être aussi que tu as cru que c'étaient les développeurs de Ryzom qui ont écrit ce code, et qu'on peut se foutre de leur gueule car ce ne sont pas "des gens qui s'y connaissent". Dans tous les cas je trouve ça moyen.

    Par ailleurs le code, un peu plus haut, explique dans un commentaire pourquoi il y a ce fragment:

    key limit is not part of the original design, added for DoS protection.

    Quand on y réfléchit, ce n'est pas forcément idiot (même si ce n'est peut-être pas non plus la meilleure façon de faire). Si je charge un mot de passe de 3Mo sur le serveur, et qu'il fait 5,000 itérations de sha512 dessus, ça fait quand même 15Go que je viens de le convaincre de chiffrer en sha512, je peux lui occuper un de ces processeurs à plein temps pendant quelques secondes.

    Mettre une limite fixée permet d'obtenir une borne supérieure sur le temps passé dans ce code, ce qui est sans doute rassurant pour le serveur. On peut pinailler sur la limite de 256 (on pourrait vouloir un mot de passe plus long que ça, c'est là ton reproche ?), mais le fait d'avoir une limite semble raisonnable.