Si je déteste des données similaires à la taille d'une taille (numéros de sécurité sociale, par exemple) à l'aide d'un algorithme de hachage avec une taille d'octets plus importante que les données (SHA-256, par exemple), le hachage garantira le même niveau de unicité comme les données d'origine?
5 Réponses :
Si vous utilisez un hasch cryptographique comme Sha, la réponse courte est oui.
Merci. Je pensais donc, mais je ne pouvais pas trouver une référence pour le sauvegarder et je ne suis pas assez intelligent pour creuser dans les mathématiques et conclure d'une manière ou d'une autre!
Comme indiqué ci-dessus, un hachage cryptographique dit simplement que les collisions sont extraordinairement improbables, pas impossibles.
@Novelcrat, la réponse courte à la question initiale est oui. Tandis que dans la théorie, une collision est possible, le temps moyen de trouver une collision est considérablement plus long que le temps qu'il faudra le soleil pour évoluer dans un géant rouge et détruire la Terre.
@Novelcrat. P.s. Si vous pouvez publier deux SSN à 10 chiffres qui produisent les mêmes haubans SHA-256, je vous paierai de 1 000 USD.
@Dieinsente je les ai trouvés! Payez-moi et je vous le ferai savoir. : P
Vous pouvez toujours créer un hachage personnalisé qui garantit l'unicité. Pour les données dans un domaine connu (comme SSN), l'exercice est relativement simple.
Si votre valeur de hachage cible a en fait plus de bits disponibles que ce que vous conduisez, le hachage permet simplement de saisir les valeurs d'entrée vers l'une des valeurs de sortie disponibles. Ce sera un simple mappage linéaire de la valeur d'entrée en tant qu'entreger multi-octets à la sortie en tant qu'oeur multi-octet.
Lorsque votre valeur de hachage cible a moins de bits que ce qui est haché, alors l'unicité ne peut jamais être garantie.
Merci. Je compte que je envisage de hadrater SSN et un identifiant "compte" qui peut varier avec chaque mise en œuvre. Donc, si je peux utiliser une fonction de hachage au lieu d'un pré-généré, ce serait préférable.
Si le masquage des numéros de sécurité sociale est l'objectif, la mise en œuvre de la fonction de cartographie linéaire ne suffirait pas, car il serait plutôt facile de calculer l'entrée d'origine à partir de certains échantillons de la sortie. En outre, la longueur de la chaîne d'entrée n'affecte définitivement pas l'efficacité d'une fonction de hachage cryptographiquement sécurisée. L'utilisation d'un algorithme de hachage connu est la voie à suivre
une caractéristique clé d'un Fonction de hachage cryptographiquement sécurisée est que vous êtes à l'abri des collisions au-delà doute raisonnable, quelle que soit l'entrée. Ceci est également valable pour l'entrée plus courte que la taille de la sortie, qui est la même d'un message plus long avec peu d'entropie. Donc, vous pouvez utiliser SHA-2 sans vous soucier des collisions.
La probabilité d'une collision de hachage n'a rien à voir avec la taille de la chaîne d'entrée (sauf dans la mesure où elle indique le nombre d'intrants dont vous avez besoin pour garder l'unicité entre). Il est possible d'avoir une collision de hachage lorsque vous HASH 0 et 1 en utilisant un algorithme de hachage parfait, bien que la possibilité soit de 1 / (2 ^ longueur). Qui dans le cas de SHA-256 est effectivement zéro.
Les collisions de hasch sont un problème de paradoxe anniversaire. Dans le cas d'un hachage de 256 bits, la probabilité d'une collision entre deux entrées dépend purement du nombre d'entrées et est la suivante:
Vrai. Je ne remets pas en question les implications de sécurité, cependant. Je demande une probabilité d'unicité d'un hachage lorsque la taille des données est inférieure à la taille du hachage. (J'ai besoin de la valeur résultante pour être déterministe / répétable, de sorte qu'un sel aléatoire de x octets ne fonctionne pas pour moi. Je pourrais "sel" en ajoutant des caractères constants par implémentation - par exemple, je pourrais ajouter des caractères comme "593JRA" au SSN avant le hachage).
Le paradoxe d'anniversaire n'est-il pas basé sur le principe du pigeonhole? Si oui, en théorie, je n'ai pas de scénario de pigeonhole.
Le principe du pigeonhole est la notion simple que lorsque vous avez plus d'articles que des pigeonholes, vous êtes garanti d'avoir une collision. Le paradoxe d'anniversaire dit simplement que vous êtes vraiment probablement probablement susceptible d'obtenir une collision si votre ratio d'articles aux pigeonholes est «élevé». Où "haut" est défini par la formule ci-dessus.
Je pense que vous n'avez pas besoin de la partie 1 - dans votre formule - sauf si vous essayez d'exprimer la probabilité de collision NO . Au fait, pouvez-vous nous donner une source pour cette formule?
D'autres ont souligné que les collisions ne devraient pas être une préoccupation; C'est tout le point de fonctions de hachage cryptographiquement sécurisées. Je voudrais juste ajouter ce qui suit: