Tu écris un long poste alors que tu ne semble même pas avoir lu les 10 lignes du readme du projet, ni les autres commentaires sur le sujet. J'ai déjà répondu plein de fois sur le sujet.
Je peux quand même en rajouter une couche :
- je n'invente pas de crypto j'utilise sha512 3 fois (pas de seed de random, pas de hash custom, pas de lfsr)
- Avec les 3 hashs je ne réutilise aucun bit pour éviter toute collision
- chaque réel utilise 4 bytes, mais je n'imprime que 5 chiffres
-> donc les 22 nombres réels entre 0 et 1.0 sont mathématiquement indistinct d'un random sauf si sha512 est cassé
Ensuite, il faut être sûr que le générateur de dessin propose suffisamment de dessins différents pour éviter les collisions visuelles. L'option -test permet de le vérifier pour des exemples. Il génère une image normalement, et génère 22 images de plus en ajoutant 0.01 à chaque paramètre (invisible pour les couleurs, j'ai fait aussi des testes avec 0.1, ce qui marche bien, d'où mon 1022).
Pour faire les choses correctement, il faudrait injecter du random dans ghash, générer les 20 images, puis faire un test comme -psnr de gmic (ou compare) pour trouver un valeur supérieur à 30 entre 2 images, par exemple. L'idée est de trouver des collisions graphiques. Je n'ai pas fait cette étape de "brute force". Cela serait à faire pour prouver la solidité du truc, c'est un sorte de "fuzzing".
Comme dit ailleurs, trouver une collision consiste à faire la même chose, en ajoutant du random à une string fixe, et comparer l'image d'origine à la nouvelle image. Mais avec 200 ms par image, cela sera trèèèèèès long.
[^] # Re: Les différences
Posté par Nicolas Boulay (site web personnel) . En réponse au journal ghash: génération d'image à partir d'un hash. Évalué à 5.
Tu écris un long poste alors que tu ne semble même pas avoir lu les 10 lignes du readme du projet, ni les autres commentaires sur le sujet. J'ai déjà répondu plein de fois sur le sujet.
Je peux quand même en rajouter une couche :
- je n'invente pas de crypto j'utilise sha512 3 fois (pas de seed de random, pas de hash custom, pas de lfsr)
- Avec les 3 hashs je ne réutilise aucun bit pour éviter toute collision
- chaque réel utilise 4 bytes, mais je n'imprime que 5 chiffres
-> donc les 22 nombres réels entre 0 et 1.0 sont mathématiquement indistinct d'un random sauf si sha512 est cassé
Ensuite, il faut être sûr que le générateur de dessin propose suffisamment de dessins différents pour éviter les collisions visuelles. L'option -test permet de le vérifier pour des exemples. Il génère une image normalement, et génère 22 images de plus en ajoutant 0.01 à chaque paramètre (invisible pour les couleurs, j'ai fait aussi des testes avec 0.1, ce qui marche bien, d'où mon 1022).
Pour faire les choses correctement, il faudrait injecter du random dans ghash, générer les 20 images, puis faire un test comme -psnr de gmic (ou compare) pour trouver un valeur supérieur à 30 entre 2 images, par exemple. L'idée est de trouver des collisions graphiques. Je n'ai pas fait cette étape de "brute force". Cela serait à faire pour prouver la solidité du truc, c'est un sorte de "fuzzing".
Comme dit ailleurs, trouver une collision consiste à faire la même chose, en ajoutant du random à une string fixe, et comparer l'image d'origine à la nouvelle image. Mais avec 200 ms par image, cela sera trèèèèèès long.
"La première sécurité est la liberté"