Ce mécanisme n’a pas pour but de générer à la demande un “simple” nombre aléatoire. Tout simplement parce que cela n’a aucun sens. Je vais essayer de t’expliquer pourquoi, sans m’énerver, promis…



Si tu veux un nombre aléatoire, ton système d’exploitation contient déjà une primitive pour ce faire. Elle est “cryptographically secure” et donc tu peux l’utiliser comme clé de chiffrement, tu n’as pas besoin d’une source extérieure.



Imagine maintenant que tu n’aies pas confiance en ce générateur aléatoire (et c’est une crainte parfaitement légitime !) que fais-tu ? Eh bien tu demandes à une autre source. Certes, mais comment fais-tu pour te connecter de façon sécurisée à cette autre source ?



Tu me dis “pourquoi ne pas simplement utiliser cUrl ou wGet qui font ça très bien ?”.

Hé bien tout simplement parce que ces outils vont utiliser du SSL/TLS.

Et ce SSL/TLS, pour être sécurisé, il aura besoin de quoi ?

D’un nombre aléatoire…

Et qui va lui fournir ce nombre aléatoire ?

Ben… une fonction random tournant localement, pardi !

Ha oui mais non, tu viens de dire que tu ne fais pas confiance au système local pour la génération de clés cryptographiques !



Tu es dans une impasse : pour recevoir de l’extérieur un nombre aléatoire en lequel tu as confiance, tu dois préalablement générer localement un nombre aléatoire en lequel tu as confiance. Le “simple” SSL/TLS ne suffit pas. Et je ne parle même pas de l’hérésie de transmettre 512 bits sur un canal chiffré par une clé à (au mieux) 256 bits: en pratique tu as transmis 256 bits d’entropie, pas 512…



Bref, si tu veux t’isoler totalement des menaces extérieures, tu est obligé d’utiliser un stack cryptographique dont tu as la maîtrise complète, que tu exécutes sous ton propre contrôle, et qui ne nécessite pas que tu fasses confiance à un acteur en particulier. C’est une telle solution qu’ils proposent, à base de preuves cryptographiques et de chiffrements asymétriques (partiels, ce que je dois moi-même approfondir, parce que je suis un peu largué).



Leur solution garantit entre autres que le nombre qui a été généré ne peut pas avoir été biaisé, du moment que dans les sources il y en ait au moins quelques unes qui ne sont pas corrompues (et sans même qu’il te soit nécessaire de savoir lesquelles sont corrompues et lesquelles sont saines)



Mais encore une fois, si tu n’as pas besoin de telles garanties, et que tu veux une solution simple à utiliser, tu n’as pas besoin d’une source distribuée, continue à utiliser ton générateur local, il est très bien.

vampire7 a écrit :



Mon contradicteur fait confiance aux sources externes utilisées dans le système discuté ici, moi non.







Heu, non, je ne fais pas confiance aux sources… Où as-tu lu que je faisais confiance aux sources ?



J’ai juste dit que la méthode proposée permet de ne pas avoir besoin de leur faire confiance, puisqu’il faudrait qu’elles se liguent ensemble, toutes, pour que le résultat soit biaisé.







vampire7 a écrit :



la raison étant qu’il n’y a alors plus de garantie que le code fonctionne correctement dans tous les cas, même avec les “vecteurs de test”







La raison est que l’implémentation par défaut a été vraisemblablement auditée pour résister à des attaques “side channel” comme l’analyse du timing de certaines opérations et les patterns d’accès mémoire. Si tu modifies l’implémentation, même en démontrant formellement que les calculs sont identiques, tu cours le risque que ton implémentation soit victime de telles attaques qui permettraient de récupérer la clé.

vampire7 a écrit :



Serpent n’est pas vulnérable à ces attaques (et les optimisations SSE2 n’y changent rien)







Serpent n’est peut-être pas vulnérable à certaines attaques. Affirmer que toutes ses implémentations sont de facto insensibles à toutes les attaques me semble péremptoire. En cherchant, la première chose que j’ai trouvée est une analyse de puissance sur le répartiteur de clés de round dans une smartcard.



https://eprint.iacr.org/2009/473.pdf

Sauf que … non … Tu ne peux pas affirmer que “ça ne change rien”. Les ingénieurs d’Intel aussi disaient “ça ne change rien si on exécute cette instruction sans vérifier les protections mémoire puisque le résultat sera annulé plus tard”. Et vlan ! SPECTRE et Meltdown.



C’est typique des gens qui comme toi réfléchissent en terme de fonctionnalité: la fonctionnalité est la même donc les deux implémentations sont équivalentes. Tant qu’on en reste à la partie fonctionnelle, tu as parfaitement raison. En termes de sécurité, il faut réfléchir en termes de surface d’attaque et de scénarios d’attaque, et là tout change.



C’est toute la différence entre montrer qu’une application fait tout ce qu’on lui demande de faire, et démontrer qu’elle ne fait rien de plus que ce qu’on lui demande de faire.



Ici, en utilisant des instructions SSE tu augmentes la surface d’attaque puisque tu es maintenant à la merci d’un leak au niveau des registres SSE alors que l’implémentation de référence ne l’était pas.



Imagine maintenant que le round est décomposé en deux parties distinctes, une sensible à une attaque par timing, et une autre beaucoup plus longue qui ne l’est pas. Imagine ensuite que la variabilité du timing de la partie sensible est complètement noyé dans celui global d’un round et le risque a été classé comme négligeable. Si tu optimises la partie longue, la proportion de temps passée dans la partie sensible sera plus grande, et l’attaque par timing redevient plausible.



Je ne dis pas que tu as forcément introduit ces faiblesses, mais en analyse de risque tu ne peux pas balayer ces objections d’un revers de main, tu dois démontrer que ces risques ont été pris en compte et mitigés de manière appropriée.

Oui.



C’est un UUID v4 ( reconnaissable au 4 dans -4F0D- ) donc contenant 122 bits aléatoires. Pas nécessairement “vraiment” aléatoires, mais qui contiennent quand même pas mal d’entropie… Je ne sais pas exactement combien (il a été généré par la fonction “generate GUID” d’un IDE Delphi 7 tournant sous Windows XP SP 2…) mais je ne me fais pas trop de souci quant à son unicité :-)