Dans le cadre de mon jeu de rythme que je travaille, je permet aux utilisateurs de créer et de télécharger des chansons personnalisées et des NOTECHARTS. Je pense à haquer la chanson et les Notecharts pour les identifier de manière unique. Bien sûr, j'aimerais que peu de collisions que possible, cependant, la force cryptographique n'est pas particulièrement importante ici comme une large gamme uniforme. De plus, depuis que j'effectue rarement les hachages, l'efficacité informatique n'est pas trop importante d'un problème.
est-il aussi simple que de sélectionner un algorithme de hachage éprouvé avec la plus grande taille de digest? Ou existe-t-il des subtilités que je devrais être au courant? Je cherche SHA-256 ou 512, actuellement.
5 Réponses :
Qu'est-ce qui ne va pas avec quelque chose comme un Bien sûr, comme avec toutes les solutions de hachage, vous devez surveiller les collisions et modifier l'algorithme si la cardinalité devient trop basse. Cela serait vrai quel que soit l'algorithme choisi (puisque vos utilisateurs peuvent commencer à télécharger des données dégénérées).
Vous pouvez finir par trouver que vous essayez de résoudre un problème qui n'existe pas (en d'autres termes, yagni possibles). md5sum ? Ou, si vous voulez un algorithme plus rapide, je créerais simplement un hachage de la longueur du fichier (MOD 64K pour s'adapter à deux octets) et de la somme de contrôle 32 bits. Cela vous donnera un hachage de 6 octets qui devrait être raisonnablement bien distribué. Ce n'est pas trop complexe à mettre en œuvre.
Si vous l'utilisez pour identifier de manière unique des pistes, vous DO veulent un hachage cryptographique: sinon, les utilisateurs pourraient créer délibérément des pistes identiques que les pistes existantes et l'utiliser pour les écraser. En guise de raison convaincante, sinon, SHA-1 devrait être parfaitement satisfaisant.
Tous les algorithmes de force cryptographique ne doivent présenter aucune collision du tout. Bien entendu, les collisions existent nécessairement (il existe des entrées plus possibles que des sorties possibles), mais elle devrait être impossible, en utilisant la technologie informatique existante, pour en trouver un.
Lorsque la fonction Hash a une sortie de bits n , il est possible de trouver une collision avec des travaux sur 2 n / 2 , Donc, dans la pratique, une fonction de hachage avec moins d'environ 140 bits de production ne peut être cryptographiquement fort. De plus, certaines fonctions de hachage ont des faiblesses qui permettent aux assaillants de trouver des collisions plus rapidement que cela; Ces fonctions sont dites "cassées". Un exemple préféré est MD5.
Si vous n'êtes pas dans un réglage de sécurité et que vous ne craignez que les collisions aléatoires aléatoires (c'est-à-dire que personne ne tentera activement de provoquer une collision, ils ne se produiront que d'une mauvaise chance pure), puis une cryptographie cassée La fonction de hachage ira bien. La recommandation habituelle est alors MD4 . Cryptographiquement parlant, il est aussi brisé que possible, mais à des fins non cryptographiques, il est diaboliquement rapide et fournit 128 bits de production, ce qui évite les collisions aléatoires.
Cependant, il y a de fortes chances que vous n'ayez aucun problème de performance avec SHA-256 ou SHA-512. Sur un PC le plus basique, ils traitent déjà des données plus rapidement que ce qu'un disque dur peut fournir: Si vous utilisez un fichier, la lecture du fichier sera le goulot d'étranglement, pas le hachage. Mon conseil serait d'utiliser SHA-256, éventuellement tronquer sa sortie à 128 bits (s'il est utilisé dans une situation non sécurisée) et envisager de passer à une autre fonction uniquement si certains problèmes liés à la performance sont dûment remarqués et mesurés.
Oui, cela a parfaitement répondu à ma question. En effet, je ne suis inquiet que de collisions aléatoires, donc je vais regarder dans SHA-256 et MD4. Merci!
Si la sécurité cryptographique n'est pas préoccupante, vous pouvez regarder cette lien & Ce . Le plus rapide et le plus simple (à mettre en œuvre) serait le hachage Pearson si vous envisagez de calculer le hasch pour le titre / le nom et une recherche ultérieure. Ou vous pouvez regarder la superfast hash ici . Il est également très bon pour une utilisation non cryptographique.
n'est-ce pas de hachage cryptographique dans ce cas dans ce cas, bien que je comprenne que les ordinateurs modernes font ce calcul assez vite? Je suppose que vos utilisateurs auront un usersique unique. Lorsqu'ils téléchargent, vous devez juste augmenter un nombre. Donc, vous les représenterez en interne comme userid1_song_1, userid1_song_2, etc. Vous pouvez stocker ces informations dans une base de données avec celle unique avec le nom spécifié par l'utilisateur.
Vous n'avez pas non plus mentionné la taille de ces chansons. Si c'est MIDI, la taille du fichier sera petite. Si les tailles de fichiers sont grandes (disent 3 Mo), les calculs SHA ne seront pas instantanés. Sur mon ordinateur portable Core2-Duo, SHA256Sum d'un fichier de 3,8 Mo prend 0,25 sec; Pour Sha1sum, il est 0,2 seconde.
Si vous avez l'intention d'utiliser un hachage cryptographique, SHA1 devrait être plus que suffisant et vous n'avez pas besoin de SHA256. Aucune collision -, bien qu'elles existent --- ont encore été trouvées. Les systèmes de contrôle de version distribués git, mercurial et autres utilisent SH1. GIT est un système basé sur le contenu et utilise SHA1 pour savoir si le contenu a été modifié.