Schützen Bloomfilter vor einem hartnäckigen Lauscher?

Soweit ich weiß, können Bloom-Filter mit einigen Ziel-Hashes und einer falsch-positiven Rate definiert werden. Beim Filtern der Blockchain werden garantiert alle Zieltransaktionen gefunden, aber viele Fehlalarme werden auch per Design an den Client zurückgegeben.

Angenommen, ein Angreifer ist in der Lage, viele Bloom-Filter-Spezifikationen zu überwachen, die von einem SPV-Client an seine Peers gesendet werden. Wird er schließlich in der Lage sein, alle Fehlalarme zu eliminieren, indem er einen Subset-Matching für alle Transaktionen durchführt, die den Filtern entsprechen?

Lassen Sie als Beispiel die Menge aller Transaktionen die ganzen Zahlen von 1 bis 100 sein, und nehmen Sie an, dass ein Client an den Transaktionen 4, 8 und 15 interessiert ist. Wenn er sich zum ersten Mal mit dem Netzwerk verbindet, überträgt er einen Bloom-Filter-Matching ( 1, 4, 7, 8, 15, 27, 44, 73); beim zweiten Mal stimmt sein Filter überein (3, 4, 6, 8, 15, 27, 66). Ein Angreifer wäre sofort in der Lage, die möglichen Transaktionen auf (4, 8, 15, 27) einzugrenzen; nach mehreren weiteren Anrufungen würde er dann die richtige Antwort finden.

Verstehe ich die Funktionsweise von Bloom-Filtern falsch (z. B. ändern sich die Fehlalarme nicht zwischen den Verbindungen), oder ist dies ein theoretisches oder sogar praktisches Problem?

Antworten (2)

Ja, Sie missverstehen die Funktionsweise von Vanilla-/Canonical-Bloom-Filtern. Bei der Standarddefinition ändern sich falsch positive Ergebnisse nicht zwischen Verbindungen – der bei einer zweiten Anforderung zurückgegebene Satz ist, falls er anders ist, ein Obersatz des ersten Satzes.

Außerdem werden Vanilla-Bloom-Filter nicht als Lösung für Sicherheits-/Abhörprobleme verwendet - sie sind eine Kompromissoptimierung zwischen Berechnung und Festplattenzugriff (ich betrachte sie als eine Teilmenge von Caching-Algorithmen). Sie können einen lokalen Bloom-Filter verwenden, um zu überprüfen, ob eine bestimmte URL bösartig ist, um einen teuren Netzwerkaufruf/Suche bei jedem URL-Zugriff zu vermeiden und den Netzwerkaufruf nur durchzuführen, wenn Sie eine positive Antwort erhalten.


Allerdings gibt es Techniken, um Bloom-Filter-ähnliche Strukturen herzustellen, die robuster sind/stärkere Sicherheitseigenschaften haben. Ich glaube nicht, dass einer von ihnen auf Bitcoin-Implementierungen angewendet wurde.

Die Bitcoin-Spezifikation von Bloom-Filtern scheint eine zufällige Eingabe in die Hash-Funktionen (ntweak) zu enthalten - hat dies nicht auch die False-Positives beeinflusst?
@lxgr Wenn ich den Code schnell durchsehe, scheint mir, dass der ntweak-Wert dazu beitragen soll, die Verwendung von Hash-Funktionen besser zu verteilen und letztendlich die Anzahl der falsch positiven Ergebnisse zu reduzieren (und den Sicherheitswert, den der Bloom-Filter möglicherweise hat, noch weiter zu reduzieren bereitstellen, aber seine Effektivität als Cache erhöhen) - Sie haben Recht, die Implementierung ist nicht kanonisch in dem Sinne, dass bei aufeinanderfolgenden Aufrufen wahrscheinlich zufällige Fehlalarme zurückgegeben werden.