Est-il possible d'obtenir un hachage SHA1 identique?
Étant donné deux chaînes différentes S1 et S2 (S1! = S2), est-il possible que:
SHA1(S1) == SHA1(S2)
est vrai?
- Si oui - avec quelle probabilité?
- Sinon - pourquoi pas?
- Y a-t-il une limite supérieure sur la longueur d'une chaîne d'entrée, pour laquelle la probabilité d'obtenir des doublons est de 0? OR le calcul de SHA1 (d'où la probabilité de doublons) est-il indépendant de la longueur de la chaîne?
Le but que j'essaie d'atteindre est de hacher une chaîne d'ID sensible (éventuellement jointe à d'autres champs comme l'ID parent), afin que je puisse utiliser la valeur de hachage comme ID à la place (par exemple dans la base de données).
Exemple:
Resource ID: X123
Parent ID: P123
Je ne veux pas exposer la nature de mon identifiant de ressource pour permettre au client de voir "X123-P123".
Au lieu de cela, je veux créer un nouveau hachage de colonne ("X123-P123"), disons que c'est AAAZZZ. Ensuite, le client peut demander des ressources avec l'ID AAAZZZ et ne pas connaître mes identifiants internes, etc.
Ce que vous décrivez s'appelle une collision. Les collisions existent nécessairement, car SHA-1 accepte beaucoup plus de messages distincts en entrée qu'il peut produire des sorties distinctes (SHA-1 peut manger n'importe quelle chaîne de bits jusqu'à 2 ^ 64 bits, mais ne produit que 160 bits; donc, au moins une sortie doit apparaître plusieurs fois). Cette observation est valable pour toute fonction dont la sortie est inférieure à son entrée, que la fonction soit ou non une "bonne" fonction de hachage.
En supposant que SHA-1 se comporte comme un "Oracle aléatoire" (un objet conceptuel qui renvoie essentiellement des valeurs aléatoires, avec la seule restriction qu'une fois qu'il a renvoyé la sortie v sur l'entrée m, il doit toujours renvoyer par la suite v en entrée m), alors la probabilité de collision, pour deux chaînes distinctes S1 et S2, devrait être 2 ^ (- 160). Toujours sous l'hypothèse que SHA-1 se comporte comme un Oracle aléatoire, si vous collectez de nombreuses chaînes d'entrée, vous commencerez à observer les collisions après avoir collecté environ 2 ^ 80 de ces chaînes.
(C'est 2 ^ 80 et non 2 ^ 160 car, avec 2 ^ 80 chaînes, vous pouvez faire environ 2 ^ 159 paires de chaînes. Ceci est souvent appelé le "paradoxe d'anniversaire" car il surprend la plupart des gens lorsqu'il est appliqué à des collisions les anniversaires. Voir la page Wikipedia sur le sujet.)
Maintenant, nous soupçonnons fortement que SHA-1 pas se comporte vraiment comme un Oracle aléatoire, car l'approche anniversaire-paradoxe est l'algorithme de recherche de collision optimal pour un Oracle aléatoire. Pourtant, il existe une attaque publiée qui devrait trouver une collision en environ 2 ^ 63 étapes, donc 2 ^ 17 = 131072 fois plus rapide que l'algorithme d'anniversaire-paradoxe. Une telle attaque ne devrait pas être réalisable sur un véritable Oracle aléatoire. Attention, cette attaque n'est pas encore terminée, elle reste théorique (certaines personnes essayé mais apparemment n'ont pas trouvé assez de puissance CP ) ( Mise à jour: au début de 2017, quelqu'un l'a fait a calculé un SHA-1 collision avec la méthode mentionnée ci-dessus, et cela a fonctionné exactement comme prévu). Pourtant, la théorie semble solide et il semble vraiment que SHA-1 ne soit pas un Oracle aléatoire. De même, en ce qui concerne la probabilité de collision, eh bien, tous les paris sont désactivés.
Quant à votre troisième question: pour une fonction avec une sortie n - bit, alors il y a forcément des collisions si vous pouvez saisir plus de 2 ^ n messages distincts , c'est-à-dire si la longueur maximale du message d'entrée est supérieure à n. Avec une borne m inférieure à n, la réponse n'est pas aussi simple. Si la fonction se comporte comme un Oracle aléatoire, alors la probabilité de l'existence d'une collision diminue avec m, et non linéairement, plutôt avec une coupure abrupte autour de m = n/2 . C'est la même analyse que le paradoxe d'anniversaire. Avec SHA-1, cela signifie que si m <80 alors il y a des chances qu'il n'y ait pas de collision, tandis que m> 80 fait l'existence d'au moins un collision très probable (avec m> 160 cela devient une certitude).
Notez qu'il y a une différence entre "il existe une collision" et "vous trouvez une collision". Même lorsqu'une collision doit existe, vous avez toujours votre probabilité de 2 ^ (- 160) à chaque fois que vous essayez. Ce que signifie le paragraphe précédent, c'est qu'une telle probabilité n'a pas de sens si vous ne pouvez pas (conceptuellement) essayer 2 ^ 160 paires de chaînes, par ex. car vous vous limitez aux chaînes de moins de 80 bits.
Oui, c'est possible à cause du principe du pigeon .
La plupart des hachages (également sha1) ont une longueur de sortie fixe, tandis que l'entrée est de taille arbitraire. Donc, si vous essayez assez longtemps, vous pouvez les trouver.
Cependant, les fonctions de hachage cryptographiques (comme la famille sha, la famille md, etc.) sont conçues pour minimiser ces collisions. La meilleure attaque connue prend 2 ^ 63 tentatives pour trouver une collision, donc la chance est 2 ^ (- 63) qui est 0 en pratique.
git utilise des hachages SHA1 comme ID et il n'y a toujours aucune collision SHA1 connue en 2014. Évidemment, l'algorithme SHA1 est magique. Je pense que c'est un bon pari que les collisions n'existent pas pour les cordes de votre longueur, comme elles auraient été découvertes maintenant. Cependant, si vous ne faites pas confiance à la magie et que vous n'êtes pas un parieur, vous pouvez générer des chaînes aléatoires et les associer à vos identifiants dans votre base de données. Mais si vous utilisez des hachages SHA1 et devenez le premier à découvrir une collision, vous pouvez simplement changer votre système pour utiliser des chaînes aléatoires à ce moment-là, en conservant les hachages SHA1 en tant que chaînes "aléatoires" pour les ID hérités.
Une collision est presque toujours possible dans une fonction de hachage. À ce jour, SHA1 a été assez sûr pour générer des collisions imprévisibles. Le danger est que lorsque des collisions peuvent être prédites, il n'est pas nécessaire de connaître l'entrée de hachage d'origine pour générer la même sortie de hachage.
Par exemple, des attaques contre MD5 ont été menées contre la signature de certificat de serveur SSL l'année dernière, comme en témoigne l'épisode 17 du podcast Security Now . Cela a permis à des attaquants sophistiqués de générer un faux certificat de serveur SSL pour un site Web escroc. et semblent être la chose reaol. Pour cette raison, il est fortement recommandé d'éviter d'acheter des certificats signés MD5.
Ce dont vous parlez s'appelle une collision. Voici un article sur les collisions SHA1: http://www.rsa.com/rsalabs/node.asp?id=2927
Edit: Donc, un autre répondeur m'a battu pour mentionner le principe des trous de pigeon LOL, mais pour clarifier c'est pourquoi on l'appelle le principe des trous de pigeon, parce que si vous avez des trous découpés pour que les pigeons voyageurs puissent nicher, mais vous avez plus de pigeons que de trous , alors certains pigeons (une valeur d'entrée) doivent partager un trou (la valeur de sortie).