Mélange associatif de hachage


14

Considérez la liste faiblement liée dans un cadre purement fonctionnel. Ses louanges ont été chantées du haut des montagnes et continueront d'être chantées. Ici, je vais aborder l'une de ses nombreuses forces et la question de savoir comment l'étendre à la classe plus large de séquences purement fonctionnelles basées sur les arbres.

Le problème est le suivant: vous voulez tester une égalité structurelle presque certaine en temps O (1) au moyen d'un hachage fort. Si la fonction de hachage est structurellement récursive, c'est-à-dire hash (x: xs) = mix x (hash xs), alors vous pouvez mettre en cache de manière transparente les valeurs de hachage sur les listes et les mettre à jour en O (1) lorsqu'un élément est conséré dans une liste existante . La plupart des algorithmes de hachage des listes sont structurellement récursifs, donc cette approche est éminemment utilisable dans la pratique.

Mais supposons qu'au lieu de listes liées individuellement, vous ayez des séquences arborescentes qui prennent en charge la concaténation de deux séquences de longueur O (n) en temps O (log n). Pour que la mise en cache de hachage fonctionne ici, la fonction de mélange de hachage doit être associative afin de respecter les degrés de liberté dont dispose un arbre pour représenter la même séquence linéaire. Le mélangeur doit prendre les valeurs de hachage des sous-arbres et calculer la valeur de hachage de l'arbre entier.

C'est là que j'étais il y a six mois quand j'ai passé une journée à réfléchir et à rechercher ce problème. Il semble n'avoir reçu aucune attention dans la littérature sur les structures de données. Je suis tombé sur l'algorithme de hachage Tillich-Zemor de la cryptographie. Il s'appuie sur une multiplication matricielle 2x2 (qui est associative) où les bits 0 et 1 correspondent aux deux générateurs d'une sous-algèbre avec des entrées dans un champ de Galois.

Ma question est, qu'est-ce que j'ai raté? Il doit y avoir des articles pertinents à la fois dans la littérature sur la cryptographie et les structures de données que je n'ai pas trouvé dans ma recherche. Tout commentaire sur ce problème et les lieux possibles à explorer serait grandement apprécié.

Edit: je suis intéressé par cette question à la fois sur les extrémités douces et cryptographiquement fortes du spectre. Sur le côté plus doux, il peut être utilisé pour les tables de hachage où les collisions doivent être évitées mais ne sont pas catastrophiques. Du côté le plus fort, il peut être utilisé pour les tests d'égalité.

Réponses:


2

Ajouté : Après avoir lu les commentaires de Per, je pense que cette réponse n'est qu'une (mauvaise) variation de l'algorithme de hachage de Tillich-Zemor qui est déjà mentionné dans la question. Je retire cette réponse, mais je la laisse en espérant qu'elle (et les commentaires) puissent être informatifs pour certains lecteurs.


Edit : Une révision antérieure de cette réponse a suggéré d'utiliser une opération monoïde sur [ m ], mais comme Per l'a souligné dans un commentaire, il est souhaitable d'utiliser une opération de groupe.

Cette réponse concerne la création d'une fonction de hachage pour les tables de hachage qui est facile à implémenter. Aucune garantie prouvable sur la qualité n'est attendue.

En supposant que vous avez déjà une fonction de hachage pour chaque élément d'une séquence vers un ensemble fini [ m ] = {1,…, m }, que diriez-vous d'interpréter chaque élément de [ m ] comme un élément dans un groupe fini G et d'utiliser le opération de groupe sur G ? Vous pouvez utiliser n'importe quel mappage de [ m ] à G , mais il est souhaitable que le mappage soit injectif afin que nous ne perdions pas les informations dans la valeur de hachage de chaque élément. Il est également souhaitable que le groupe ne soit pas commutatif pour que la fonction de hachage puisse saisir la différence dans l'ordre des éléments dans une séquence.

Je ne connais pas grand-chose aux groupes finis qui permettent des opérations rapides, mais je suppose que ces groupes sont connus dans la théorie du codage. L'utilisation du groupe d'ordre symétrique au moins m peut ne pas être si mauvaise.


1
Oui, le hachage de Tillich-Zemor utilise également la multiplication matricielle. Ce que vous proposez ne peut pas fonctionner sans modifications supplémentaires à la Tillich-Zemor. Par exemple, vous devez éviter les matrices singulières ou vous obtenez une accumulation à 0, ruinant les statistiques de hachage. Tillich-Zemor travaille sur un champ de Galois; une version antérieure de leur algorithme avait des problèmes car ils utilisaient un polynôme générateur qui avait des statistiques sous-optimales, donc le champ de Galois particulier peut être très important.
Per Vognsen

@Per: Je vois. Merci pour votre explication. Qu'en est-il alors de l'utilisation de groupes finis? J'ai modifié la réponse à cela.
Tsuyoshi Ito

Je suis d'accord. La meilleure façon de générer des familles infinies de groupes est d'utiliser des groupes matriciels sur des champs finis (cf. le théorème de classification pour les groupes simples finis), il semble donc que les algorithmes de cette forme soient de type Tillich-Zemor.
Per Vognsen

@Per: Je ne connais pas la théorie des groupes et je ne vois pas pourquoi les groupes matriciels sur des champs finis sont meilleurs que les groupes symétriques dans ce contexte. Pouvez-vous nous en dire plus?
Tsuyoshi Ito

1
Il y a plusieurs raisons. D'une part, vous ne pouvez pas calculer efficacement dans de grands groupes symétriques, et vous avez besoin que les groupes soient de l'ordre de 2 ^ 128 pour la résistance aux collisions. En revanche, vous pouvez calculer avec des matrices sur 2 champs finis caractéristiques très efficacement, surtout si vous choisissez un polynôme générateur clairsemé; c'est juste un tas de manipulations de bits.
Per Vognsen

1

La famille presque universelle de fonctions de hachage

{ha(x)=aiximodp:aZp}

ha(x)+a|x|ha(y)=ha(xy)a|x|O(1)Zp

xyO(min(|x|,|y|)/p) . Voir CLRS ou Dietzfelbinger et al. Dans "Les fonctions de hachage polynomiales sont fiables".


1

nn,ny,yny=H(y,y)HO(1)O(lgn)

H(x1,,xm)x1,,xmm

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.