Als Teil meines Rhythmusspiels, an dem ich arbeite, erlaube ich Nutzern, eigene Songs und Notchcharts zu erstellen und hochzuladen. Ich denke daran, den Song und die Notchcharts zu hashen, um sie eindeutig zu identifizieren. Natürlich möchte ich so wenig Kollisionen wie möglich haben, aber kryptografische Stärke ist hier nicht so wichtig wie eine breite einheitliche Reichweite. Da ich die Hashes selten ausführen werde, ist die rechnerische Effizienz kein allzu großes Problem.
Ist das so einfach wie die Auswahl eines bewährten Hash-Algorithmus mit der größten Digest-Größe? Oder gibt es einige Feinheiten, denen ich bewusst sein sollte? Ich schaue derzeit entweder SHA-256 oder 512 an.
Der Algorithmus für die kryptografische Stärke sollte überhaupt keine Kollision zeigen. Natürlich sind Kollisionen notwendig (es gibt mehr mögliche Eingaben als mögliche Ausgaben), aber es sollte unmöglich sein, mit der vorhandenen Computertechnologie tatsächlich eine zu finden.
Wenn die Hash-Funktion eine Ausgabe von n Bits hat, ist es möglich, eine Kollision mit der Arbeit über 2 n / 2 zu finden. In der Praxis kann also eine Hash-Funktion mit weniger als 140 Bits Ausgabe nicht kryptographisch stark sein. Darüber hinaus haben einige Hash-Funktionen Schwächen, die es Angreifern ermöglichen, Kollisionen schneller zu finden. Solche Funktionen werden als "kaputt" bezeichnet. Ein Paradebeispiel ist MD5.
Wenn Sie nicht in einer Sicherheitseinstellung sind und nur zufällige Kollisionen befürchten (dh niemand wird aktiv versuchen, eine Kollision zu provozieren, kann dies nur aus reinem Pech geschehen), dann eine kaputte Kryptographie Hash-Funktion wird in Ordnung sein. Die übliche Empfehlung ist dann MD4 . Kryptografisch gesehen ist es so kaputt wie es nur sein kann, aber für nicht-kryptografische Zwecke ist es teuflisch schnell und bietet 128 Bits Ausgabe, die zufällige Kollisionen vermeiden.
Es besteht jedoch die Möglichkeit, dass Sie kein Leistungsproblem mit SHA-256 oder SHA-512 haben. Auf einem grundlegendsten PC verarbeiten sie Daten bereits schneller als das, was eine Festplatte bieten kann: Wenn Sie eine Datei hashen, ist das Lesen der Datei der Engpass, nicht das Hashing. Mein Rat wäre, SHA-256 zu verwenden und möglicherweise seine Ausgabe auf 128 Bit zu kürzen (wenn es in einer nicht sicherheitsrelevanten Situation verwendet wird) und nur dann auf eine andere Funktion umzusteigen, wenn ein leistungsbezogenes Problem erkannt und gemessen wird.
>Wenn Sie Tracks zum eindeutigen Identifizieren verwenden, möchten Sie einen kryptografischen Hash erhalten: Andernfalls könnten Benutzer absichtlich Tracks erstellen, die dieselben Hash-Werte wie vorhandene Tracks aufweisen und diese zum Überschreiben verwenden. Abgesehen von einem zwingenden Grund sollte SHA-1 vollkommen zufriedenstellend sein.
Wenn die kryptografische Sicherheit keine Rolle spielt, können Sie diesen Link & amp; dies . Die schnellste und einfachste (zu implementieren) wäre Pearson-Hashing, wenn Sie planen, Hash für den Titel / Namen zu berechnen und später nachschlagen. oder Sie können sich den hier ansehen. Es ist auch sehr gut für nicht kryptografische Verwendung.
Was ist los mit so etwas wie md5sum ? Oder, wenn Sie einen schnelleren Algorithmus wünschen, würde ich nur einen Hash aus der Dateilänge (Mod 64K, um in zwei Bytes zu passen) und 32-Bit-Prüfsumme erstellen. Das wird Ihnen einen 6-Byte-Hash geben, der vernünftig gut verteilt sein sollte. Es ist nicht übermäßig komplex zu implementieren.
Wie bei allen Hash-Lösungen sollten Sie natürlich die Kollisionen überwachen und den Algorithmus ändern, wenn die Kardinalität zu niedrig wird. Dies gilt unabhängig vom ausgewählten Algorithmus (da Ihre Benutzer möglicherweise mit dem Hochladen von entarteten Daten beginnen).
Sie können am Ende feststellen, dass Sie versuchen, ein Problem zu lösen, das nicht existiert (mit anderen Worten, mögliches YAGNI).
Ist in diesem Fall nicht kryptographisch ein Overkill, obwohl ich weiß, dass moderne Computer diese Berechnung ziemlich schnell machen? Ich nehme an, dass Ihre Benutzer eine eindeutige Benutzer-ID haben. Beim Hochladen müssen Sie nur eine Zahl erhöhen. So werden Sie sie intern als userid1_song_1, userid1_song_2 usw. darstellen. Sie können diese Informationen in einer Datenbank mit diesem als eindeutigen Schlüssel zusammen mit dem vom Benutzer angegebenen Namen speichern.
Sie haben auch nicht die Größe dieser Songs erwähnt. Wenn es Midi ist, wird die Dateigröße klein sein. Wenn die Dateigröße groß ist (sagen wir 3 MB), werden die sha Berechnungen nicht sofort durchgeführt. Auf meinem core2-duo Laptop dauert die sha256sum einer 3,8 MB großen Datei 0,25 Sekunden; für sha1sum sind es 0,2 Sekunden.
Wenn Sie einen kryptografischen Hash verwenden möchten, sollte sha1 mehr als ausreichend sein und Sie brauchen sha256 nicht. Keine Kollisionen - obwohl sie existieren - wurden bisher gefunden. Git, Mercurial und andere verteilte Versionskontrollsysteme verwenden sh1. Git ist ein inhaltsbasiertes System und verwendet sha1, um herauszufinden, ob der Inhalt geändert wurde.
Tags und Links algorithm cryptography hash