Logbuch-Netzpolitik on Linus Neumann

Gedanken zur Cybersicherheitsagenda

Fri, 15 Jul 2022 00:00:00 +0000

Am Dienstag hat das Innenministerium die “Cybersicherheitsagenda” für die 20. Legislaturperiode vorgestellt.
Die Agenda

ist an viel zu schwammig formuliert, um abschließend beurteilt zu werden,
verkennt ganz generell das Problem, vor dem wir stehen,
und versäumt dringend notwendige Chancen.

An sinnvollen Ansätzen für nachhaltige IT-Sicherheit herrscht eigentlich kein Mangel. Unter anderem haben wir als CCC solche in folgenden Sachverständigenanhörungen im Bundestag angeregt:

In Tagesschau und Tagesthemen durfte ich das Dokument kurz kommentieren:

Gedanken zum COVID-19-Impfnachweis

Fri, 21 May 2021 00:00:00 +0000

Disclaimer: Ich betreibe meinen WHO-Impfausweis als Panini-Sammelalbum meines Immunsystems. Ich strebe eine komplette Sammlung an und bin auf seltene Sticker besonders stolz.

Gesellschaftliches Problem

Wenn es in Zeiten der Pandemie gesundheitliche Sicherheit und Zugang zu gesellschaftlicher Teilhabe zu verteilen gibt, fällt jede Scham. Eine befreundete Medizinerin wollte mir vor einigen Wochen gar nicht glauben, dass ich noch gar keinen Biontech-Shot hätte: “Also in unserem Freundeskreis längst durchgeimpft. Soll ich dir kurz ein Rezept ausstellen? Dann kannst du morgen direkt zu einer Kollegin von mir…”

Corona und Datenschutz: Julian Nida-Rümelin verdreht noch mehr Tatsachen, als ich zunächst dachte.

Wed, 23 Dec 2020 00:00:00 +0000

Bei “Anne Will” vom 13. Dezember 2020 stellte der Philosoph Julian Nida-Rümelin eine Reihe schwer haltbarer Tatsachenbehauptungen auf. Für eine informierte Debatte mitten in der zweiten Welle einer tödlichen Pandemie ist das fatal.

In der aktuellen Folge unseres Podcasts Logbuch:Netzpolitik haben wir die Journalistin Katharin Tai zu Gast, die sich gerade in Taiwan aufhält. Erstaunt stellten wir fest: Vieles, das in Deutschland medial als Tatsache rauf und runter gebetet wird, entspricht einfach nicht den Tatsachen: LNP374 Ein alter weißer Mann ist passiert.

Die Corona-Warn-App verliert den Anschluss

Fri, 16 Oct 2020 00:00:00 +0000

Update: Ein kürzerer und prägnanterer Artikel zu diesem Thema wurde bei heise.de als Gastbeitrag veröffentlicht: Alle reden von Clustern – nur die Corona-App nicht.

Seit dem Launch der Corona-Warn-App sind bald 4 Monate vergangen. In dieser Zeit haben wir viel über das Virus gelernt. Dieses Wissen muss nun auch in der App ankommen.

Zur Erinnerung: Die App soll dabei helfen, Risiko-Kontakte zu erfassen. Als Risiko-Kontakt gilt für die App: Abstand weniger als 1,5m; Dauer länger als 15min.

Weitere Gedanken zum Contact Tracing mit "Corona Apps"

Sun, 05 Apr 2020 00:00:00 +0000

Updates:

2020-04-26: Nachdem die Bundesregierung zuletzt einen zentralen Ansatz bevorzugte, wird nun ein dezentraler Ansatz verfolgt. Das ist sehr zu begrüßen.
2020-04-22: Die Debatte wird aktuell unübersichtlich. Weiterhin stehen dezentrale Ansätze wie DP-3T, Apple/Google und der von mir unten beschriebene Ansatz den “zentralen” Ansätzen gegenüber.
Der Hauptunterschied ist, wo die Entscheidung über Alarmierung getroffen wird. In dezentralen Ansätzen erfolgen Analyse und Entscheidung für Alarmierung auf den Geräten der Nutzerinnen. In zentralen Ansätzen geschieht dies auf dem bzw. einem Server.
Ich habe den Stand der Debatte und die jeweiligen Argumente in einem Interview mit der Wirtschaftswoche zusammengefasst.
Meine These: Apple und Google geben jetzt den Ton an, die meisten Diskussionen haben sich erübrigt. Ähnlich habe ich den Stand auch in Logbuch:Netzpolitik Folge 341 zusammengefasst.
2020-04-10: Wie zu erwarten war, haben Apple und Google einen gemeinsamen Standard für Contact Tracing entwickelt und veröffentlicht:
2020-04-09: Martin Holland und Jürgen Kuri haben das Thema heute in der heise-Show mit mir als Gast besprochen.
2020-04-06: CCC veröffentlicht 10 Prüfsteine für die Beurteilung von “Contact Tracing”-Apps

Logbuch:Netzpolitik

In der neuen Folge unseres Podcasts Logbuch:Netzpolitik habe ich unter anderem mit einer Reihe an Missverständnissen zu den Möglichkeiten und Grenzen sogenannter “Corona Apps” auseinander gesetzt.

„Corona-Apps“: Sinn und Unsinn von Tracking

Mon, 30 Mar 2020 00:00:00 +0000

Updates:

2020-04-26: Nachdem die Bundesregierung zuletzt einen zentralen Ansatz bevorzugte, wird nun ein dezentraler Ansatz verfolgt. Das ist sehr zu begrüßen.
2020-04-22: Die Debatte wird unübersichtlich und hitzig. Weiterhin stehen dezentrale Ansätze wie DP-3T, Apple/Google und der von mir unten beschriebene Ansatz den “zentralen” Ansätzen gegenüber.
Der Hauptunterschied ist, wo die Entscheidung über Alarmierung getroffen wird. In dezentralen Ansätzen erfolgen Analyse und Entscheidung für Alarmierung auf den Geräten der Nutzerinnen. In zentralen Ansätzen geschieht dies auf dem bzw. einem Server.
Ich habe den Stand der Debatte und die jeweiligen Argumente in einem Interview mit der Wirtschaftswoche zusammengefasst.
Meine These: Apple und Google geben jetzt den Ton an, die meisten Diskussionen haben sich erübrigt. Ähnlich habe ich den Stand auch in Logbuch:Netzpolitik Folge 341 zusammengefasst.
2020-04-10: Wie zu erwarten war, haben Apple und Google einen gemeinsamen Standard für Contact Tracing entwickelt und veröffentlicht:
2020-04-05: Tim Pritlove und ich diskutieren gesellschaftliche und technische Anforderungen in LNP339 Die Fantasie kennt keine Grenzen beim Setzen von Grenzen
2020-04-02: Interview zum Thema bei Markus Lanz (youtube)
2020-03-31: Tim Pritlove und erklären das allgemeine Konzept in LNP338 Corona Tracking App
2020-03-31: Interview bei phoenix (youtube)
2020-03-31: Beitrag WDR aktuelle Stunde hinzugefügt
2020-03-29: FAQ am Ende des Artikels hinzugefügt

Über eine technisch gestützte Rückverfolgung von Corona-Infektionen werden zur Zeit verschiedene Debatten heiß geführt. Es begann mit der Weitergabe von Bewegungsdaten durch Mobilfunkanbieter an das Robert-Koch-Institut und natürlich ließen auch Gesetzesänderungen zum vollumfänglichen Location-Tracking nicht lang auf sich warten.

Im Folgenden erkläre ich, warum Location-Tracking völlig ungeeignet ist, und welche Methoden stattdessen zielführend sein könnten. Wichtig ist immer, Sinn und Ziel einer solchen App nicht aus den Augen zu verlieren:

Wenn bei einer Person zum Zeitpunkt t eine Infektion festgestellt wird, soll sie in der Lage sein, ihre Kontakte der letzen t–14 Tage darüber zu informieren. Nicht mehr, aber auch nicht weniger. Primäres Ziel sollte also sein, die Kontakte reliabel zu erfassen.

Datentypen

In der Debatte werden die Begriffe „Standortdaten“, „Bewegungsdaten“ und „Kontaktdaten“ wild gemischt. Zunächst müssen wir also klären, wovon überhaupt die Rede ist.

1. Standortdaten: Person x war zum Zeitpunkt t an Ort A

Problem 1: Die räumliche Auflösung via GPS ist ziemlich ungenau.
Ob sich zwei Personen nah genug gekommen sind, um einander zu infizieren, oder ob sie mehrere Meter voneinander entfernt waren, lässt sich anhand der Genauigkeit von GPS einfach nicht entscheiden – eine Unmenge an false positives wäre die Folge.

Problem 2: Da wir uns bewegen, entsteht natürlich eine sehr lange Liste für jede Person. Die Länge der Liste richtet sich dabei nach der Frequenz der Erfassung. Noch dazu sind die Daten personengebunden. Da wir uns zurzeit weitestgehend isolieren, wäre der größte Teil der erfassten Daten zudem noch absolut irrelevant!

Fazit: Standortdaten sind aufgrund ihrer Ungenauigkeit schlichtweg ungeeignet. Schon das allein disqualifiziert sie, so dass wir die immensen Datenschutz- und Grundrechtsverletzungen gar nicht erst zu diskutieren brauchen.

2. Bewegungsdaten: In Zeitraum Δt haben sich n Personen von Bereich A in Bereich B bewegt.

Bewegungsdaten sind also im Gegensatz zu Standortdaten räumlich und zeitlich geringer aufgelöst. Sie sollten darüber hinaus über mehrere Personen aggregiert sein, so das die Identifikation der Bewegungen einzelner nicht möglich sein sollte.

Anwendungszweck: Diese Art Daten eignen sich gut zur Messung der Effektivität von Maßnahmen zur Senkung der Mobilität.Das ist im weitesten Sinne das, was von den Mobilfunknetzen an das RKI gegeben wird – ein Anspruch also, für den es eine seit Jahren existierende Lösung gibt. Diese Lösung wurde kommerziell übrigens allen angeboten, die bereit sind, dafür zu bezahlen. Das RKI ist in der Reihe der Abnehmer vermutlich noch der am wenigsten problematische.

Problem 1: Je nach zeitlicher und räumlicher Auflösung sind diese Daten ggf. von einer böswilligen Anwenderin durchaus de-anonymisierbar.

Problem 2: Für das Identifizieren von Kontakten sind die Daten nicht geeignet.

3. Kontaktdaten: Person a und Person b hatten zum Zeitpunkt t für einen Zeitraum länger als Δt Kontakt.

Dies ist der einzige relevante Messwert, um den es hier wirklich gehen soll. Wo dieser Kontakt stattgefunden hat, oder an welchem Ort a und b davor und danach waren, ist absolut uninteressant. Wieso sollte das also überhaupt erfasst werden?

Halten wir fest: alles, was erfasst werden muss, sind Kontaktdaten.

Datenspeicherung

Viele vorgeschlagene Konzepte sehen eine zentrale Speicherung von Standort- oder Bewegungsdaten vor. Hierbei würde eine Unmenge an irrelevanten Daten (kein Kontakt) gespeichert. Darüber hinaus ist eine zentrale Datenhaltung aus offensichtlichen Gründen abzulehnen: IANAL; aber nicht nur unterliegen wir hier dem Bereich der DSGVO, sondern auch den besonderen Anforderungen für sensible Gesundheitsdaten.

Die offensichtliche Anforderung ist also, sämtliche Daten dezentral und anonym vorzuhalten – und zwar auf eine Weise anonymisiert, die auch keine Deanonymisierung zulässt.

Es ergeben sich folgende Anforderungen:

Dezentralität: Jede Person sammelt nur Daten für sich selbst. Diese werden nicht automatisiert weitergegeben.
Anonymität:
- Die Daten, die jede Person sammelt, sind nicht geeignet zur Deanonymisierung anderer.
- Die Daten, die jede Person sammelt, sind nicht geeignet zur Deanonymisierung der Person selbst.
Datensparsamkeit: Nur im Infektionsfall kann eine Person ihre Daten weitergeben. Auch in diesem Fall geben die Daten aber weder die Identität der infizierten Person, noch die Identität ihrer Kontaktpersonen preis.

Als Mitglied der Jury des Hackathons „Wir vs Virus“ hatte ich die Freude, eine Reihe von Einreichungen zu begutachten, die eine kluge Lösung gefunden haben, diese Anforderungen zu vereinen. Zur Veranschaulichung stark vereinfacht möchte ich sie hier einmal grob darstellen:

Mein Handy sendet in regelmäßigen Abständen mittels Bluetooth Low Energy Beacon einen zufälligen Code aus. Dieser Code ändert sich regelmäßig, bspw. alle 30 Minuten.
Empfängt mein Handy den Code eines anderen Handys, wird anhand der Signalstärke der Abstand geschätzt. Ist der Abstand gering genug, speichert mein Handy diesen Code. Da sich der Code der anderen Person bald wieder ändern wird, hat mein Handy keine personengebundenen Daten erfasst und ist auch nicht in der Lage, die andere Person längere Zeit zu tracken.
Werde ich als infiziert diagnostiziert, veröffentliche ich an zentraler Stelle alle Codes, die ich je gesendet habe auf einem zentralen Server. Hier werden auch die Codes von allen anderen Menschen veröffentlicht, die diagnostiziert wurden.
Alle anderen Nutzer laden regelmäßig die veröffentlichten als „infiziert“ markierten Codes herunter. Diese Codes sind ohne jede Aussage über Ort, Zeit oder Personen. Sie haben nur Informationswert für jene Personen, mit denen ich Kontakt hatte.
Der Abgleich der veröffentlichten mit den lokal auf meinem Handy gespeicherten Codes ermöglicht das Berechnen meiner Exposition. Dabei ist es unerheblich, ob ich 10 Stunden mit einer infizierten Person verbracht habe, oder jeweils 20 halbe Stunden mit unterschiedlichen infizierten Personen. Selbst das kann aus den Daten nicht rekonstruiert werden.
Auf dem zentralen Server befinden sich keinerlei Daten darüber, welche Personen infiziert sind, wo sie sich wann aufgehalten haben, oder welche Personen sie wo getroffen haben.

Trotzdem haben wir auf diese weise den Datensatz bester Qualität, weil genau nur unsere Kontakte aufgezeichnet wurden – jene Daten also, auf die es wirklich ankommt.

Elegante Lösungen

Diesen Anforderungen entsprechen folgende Einreichungen zum Hackathon „Wir vs. Virus“, die alle mittels Bluetooth ausgetauschte, zeitlich beschränkte Codes nutzen. Ich verlinke sie hier ohne Anspruch auf Vollständigkeit, weil ich nicht weiß ob ich alle Einreichungen zu diesem Thema reviewed habe:

Update: Inzwischen haben sich drei der Projekte zusammengeschlossen:
ito – track infections, not people!, früher:
Den weiteren Fortschritt von ito kann man hier begutachten und sich einbringen.
CovidEncounters

Für Menschen ohne Smartphone würde sich mit leichten Abstrichen in eine QR-Code-Lösung anbieten, bei der die Privatsphäre der Personen zumindest gegenüber wohlmeinenden Kontakten sichergestellt werden könnte – natürlich fehlt dem QR-Code aber die Benachrichtigungsfunktion: Tracking Infection Awareness Alert (IAA)

Wir lernen also: Die Daten der höchsten Qualität und Aussagekraft lassen sich vollständig anonym und dezentral erfassen. Ein wunderschönes Beispiel, wie wir ohne zentralisierte Massenüberwachung sogar ein besseres Ergebnis bekommen – und dabei entspannt und frei weiterleben können, ohne der Corona-Krise gleich noch eine selbstverschuldete Grundrechtskrise folgen zu lassen.

Mein Lob, meine Anerkennung und mein Glückwunsch gilt den „Wir vs Virus“-Teams!

Der Teufel steckt im Detail

Natürlich muss aber auch angemerkt werden, dass nur minimale Änderungen ausreichen würden, die Anonymität oder Dezentralität zu zerstören. Beispielsweise, den Code nicht regelmäßig zu ändern, oder alle Codes immer zentral zu erfassen. Selbstverständlich kann so eine App ausschließlich auf freiwilliger Basis verbreitet werden. Wenn die hier skizzierten Anforderungen kompromisslos erfüllt sind, hätte ich aber keinerlei Bedenken, die App zu nutzen – und ich denke dass es vielen Menschen ähnlich ginge.

Medienberichte

In den Tagesthemen konnte ich gestern diese Gedanken zum Teil ausführen:

Hack und Back vom BND?

Wed, 05 Jun 2019 00:00:00 +0000

In der vergangenen Woche wurden erstmals die konkreten Pläne der Bundesregierung bekannt, in den Cyber-Krieg zu ziehen. Ich sehe in diesem Vorgehen 3 Kernprobleme:

Spontanes Hacking auf Befehl geht nicht – ein Hack braucht lange Vorbereitung, im Zweifelsfall muss die Infiltration schon lange erfolgt sein, bevor der Befehl zur Sabotage ausgeführt wird.
Ein Hack setzt bekannte Schwachstellen voraus – diese müssen geheim gehalten werden und auf allen Systemen ungepatcht sein. So werden wir alle einem Risiko ausgesetzt, auf das Wannacry nur ein Vorgeschmack war.
Schadenabwehr durch Gegenangriff funktioniert nicht – Es fällt auch der Bundesregierung schwer, einen Fall zu konstruieren, in dem ein Gegenangriff zu signifikanter Schadenminderung oder gar -abwehr beigetragen hat oder hätte.

Von den 3 Problemen möchte die Bundesregierung nur dem ersten begegnen: Weil spontane Hacks nicht funktionieren, sollen die Offensiv-Kapazitäten beim BND angesiedelt werden. Der BND würde damit von der reinen Spionage zur Sabotage übergehen, von der NSA zur CIA werden. Begriffe wie “Hackback”, “Abwehr” oder “Verteidigung” sind dabei nicht zutreffend, weil die Infiltration der Zielsysteme bereits vorher erfolgt. In Logbuch:Netzpolitik Folge 248 haben wir dafür den Begriff “Hack & Back” eingeführt.

Lehren aus den Doxing-Angriffen

Wed, 09 Jan 2019 00:00:00 +0000

Nach dem öffentlichen Bekanntwerden konnten Täter und Mittäter hinter den ausführlichen Datenveröffentlichungen im “Doxing-Adventskalender” sehr zügig dingfest gemacht werden. Nun ist es Zeit, daraus die richtigen Lehren zu ziehen.

War das ein Superhack?

Nein. Es ist auch nichts, worauf man stolz sein könnte.

“Nur” 50 der 1.000 betroffenen Personen wurde wirklich gehackt – der Rest der Daten stammte aus diesen illegalen Zugriffen und vermutlich aus weiteren Recherchen.
Das Vorgehen war simpel, hatte keine besondere technische Komponente und
der Täter verstand es nicht, seine Spuren zu verwischen um sich nicht erwischen zu lassen.

Das bedeutet aber auch:

Damit es der Russe(TM) nicht macht: CCC hackt die Bundestagswahl

Thu, 07 Sep 2017 00:00:00 +0000

Zusammen mit Thorsten Schröder und Martin Tschirsich habe ich mir in den letzten Wochen die zur Organisation, Erfassung, Berechnung, grafischen Präsentation, Meldung und statistische Nachbereitung von Wahlen verwendete Software PC-Wahl angeschaut.

Dabei ist uns einer Reihe an Sicherheitslücken aufgefallen, die sich zu drei unterschiedlichen praktikablen Angriffszenarien auf die Bundestagswahl kombinieren lassen. Die Ergebnisse haben wir in einem 23-seitigen Bericht zusammengefasst und die im Rahmen der Analyse entwickelten Angriffe auf github veröffentlicht.

Darüber berichtet die ZEIT auf Papier und online darüber, ebenso wie Spiegel Online und netzpolitik.org. In Logbuch:Netzpolitik 228 berichten wir darüber hinaus ausführlich und in lockerer Atmosphäre von der Analyse.

„Es ist einfach nicht das richtige Bundestagswahljahrtausend, um in Fragen der IT-Sicherheit bei Wahlen ein Auge zuzudrücken“, sagte Linus Neumann. „Wirksame technische Schutzmaßnahmen sind teilweise seit Jahrzehnten verfügbar. Es ist nicht nachvollziehbar, warum diese keine Anwendung finden.“

Bericht: Analyse einer Wahlsoftware
Repository: Walruss PC-Wahl 10 Hacking Tools
Podcast: Logbuch:Netzpolitik 228 Interessierte Bürger
Pressemitteilung CCC: Software zur Auswertung der Bundestagswahl unsicher und angreifbar

Zu Gast im SWR Forum zum Bundestagswahlkampf

Thu, 31 Aug 2017 00:00:00 +0000

Mit der Einflussnahme auf Wahlen beschäftige ich mich seit einem Jahr ausführlich. Nicht nur im Logbuch:Netzpolitik behandeln wir das Thema regelmäßig – auch im Bundestag musste ich inzwischen mehrmals dazu Rede und Antwort stehen.

Am Mittwoch habe ich im SWR mit

Dr. Jeanette Hofmann, Professorin für Internetpolitik an der Freien Universität Berlin
Robert Heinrich, Wahlkampfmanager Bündnis90/Die Grünen

darüber diskutiert. Moderiert wurde die Sendung von Claus Heinrich.

Anzeigen bei Google, persönliche Tweets mit Hilfe von Big-Data, die Abwehr von Fake-News. Noch nie wurde in Deutschland von den Parteien so viel in digitale Medien investiert wie bei diesem Bundestags-Wahlkampf. Für die meisten Politiker heißt das experimentieren im “Neuland”. Lohnt sich der Aufwand? Welche Online-Strategien sind bei welchen Zielgruppen erfolgreich? Führt das “Like” bei Facebook tatsächlich zum Kreuz bei der Wahl? In den USA haben Hacker den Ausgang der Präsidentenwahl über sogenannte Social Bots beeinflusst. In Deutschland wollen alle Parteien auf diese Meinungsroboter verzichten. Reicht das aus, um den Wahlkampf im Netz vor Manipulation zu schützen?

Tagesschau zum Netzwerkdurchsetzungsgesetz

Thu, 06 Apr 2017 00:00:00 +0000

Gestern wurde das Netzwerkdurchsetzungsgesetz vom Kabinett beschlossen. Über sein Ziel, strafrechtlich relevante Äußerungen schneller aus dem Netz entfernen zu lassen, schießt es weit hinaus.

Künftig soll Webseitenbetreiber und soziale Netzwerke die Löschentscheidung selbst treffen. Dabei können sie natürlich Fehler machen. Löschen sie eine strafrechtlich relevante Äußerung nicht, so drohen empfindliche Strafen. Andererseits könnten sie eine von der Meinungsfreiheit gedeckte Äußerung fälschlich löschen. In diesem Fall droht ihnen jedoch keine relevante Sanktion.

Der Russe manipuliert die Wahl!1!

Wed, 14 Dec 2016 00:00:00 +0000

Gestern morgen habe ich im Deutschlandfunk erklärt, mit welchen Methoden in sozialen Medien der Versuch unternommen wird, auf das Ergebnis von Wahlen einzuwirken. Das Interview gibt es online in der ARD Mediathek und hier zum Download.

Ich hoffe, dass ich auch in der kurzen Zeit einerseits das Potenzial, andererseits auch die Limitationen dieser Ansätze verdeutlicht habe. Sehr viel ausführlicher haben wir uns dem Thema in LNP203 Unglück im Glück im Unglück gewidmet (Kapitel Big Data & Fake News, insgesamt über 90min)

Logbuch:Netzpolitik Folge 200

Sun, 06 Nov 2016 00:00:00 +0000

Am 5. November haben Tim Pritlove und ich in Berlin die 200. Folge unseres Podcasts Logbuch:Netzpolitik mit einer Live-Sendung gefeiert.

Im ehemaligen Stummfilmkino Delphi haben wir die 5 Jahre des Bestehens von Logbuch:Netzpolitik gebührend mit 400 Gästen gefeiert. Dank dem C3VOC gibt es davon eine Video-Aufzeichung:

↗ YouTube

Als Pre-Show hatten wir unsere Freunde von Methodisch Inkorrekt zu Gast:

↗ YouTube

Die Shownotes, viele Photos, und weitere Infos zu Logbuch Netzpolitik gibt es an der gewohnten Stelle.

Zapp über "Social Bots"

Thu, 21 Apr 2016 00:00:00 +0000

Das Medienmagazin ZAPP berichtete gestern über Social Bots – automatische, nicht menschliche Accounts in sozialen Netzwerken. Forscher der Universität Siegen haben diese zu nichts geringerem als einer Gefahr für die Demokratie erklärt.

Diese Einschätzung teile ich nicht, wie ich schon in Logbuch:Netzpolitik 175 ausgeführt habe. Eine größere (aber ebenso vernachlässigbare) Gefahr für die Demokratie ist wahrscheinlich, dass das Bundesministerium für Bildung und Forschung im Jahr 2016 noch derartige “Forschung” fördert, nachdem Spam und Bots vermutlich älter sind, als die meisten der beteiligten Forscher.

32C3

Wed, 10 Feb 2016 00:00:00 +0000

Großes Lampenfieber hatte ich vor der Eröffnung, die Carina Haupt zusammen mit mir bestritten hat:

↗ media.ccc.de

Das großartige Eröffnungsvideo stammte übrigens von Frederic Brückner, mit Sound von Erich Lesowsky.
Das Design-Gesamtkonzept stammte von Roland Brückner.

Zu Kollisionen in Hashfunktionen und dem (Un)sinn, sie zur Suche zu verwenden.

Wed, 14 Mar 2012 00:00:00 +0000

Heute habe ich im Logbuch Netzpolitik eine kurze Einführung gegeben, was kryptografische Hashfunktionen sind, und welchen Zweck sie bei der Integritätsprüfung von Dateien erfüllen. Dabei kam ich auch auf Kollisionen zu sprechen, den Fall, dass 2 Dateien einen gleichen Hash haben.

Per Twitter fragte mich gerade @LucasF:

Im Bezug auf LNP, müsste es nicht theoretisch unendlich viele Dateien mit gleichem Hashwert geben, und nicht nur zwei?

Die kurze Antwort:

Theoretisch ja, aber wenn nDateien -> ∞ und Dateigröße -> ∞, dann brauchst du immer noch t -> ∞ um gezielt Dateien mit gleichem Hash, also eine Kollision zu finden / zu konstruieren.

Das ist nämlich der Sinn von Hashfunktionen, die zum Beispiel bei PGP-Emailsignaturen zum Einsatz kommen: Es soll dem Angreifer unmöglich sein, eine Nachricht zu konstruieren, die den gleichen Hash produziert, dabei aber immer noch sinnvoll überzeugend ist, um beim Empfänger kein Misstrauen zu wecken. Gleiches gilt bei der Datei-Integritätsprüfung bei Software-Downloads: Es ist eine Sache, evtl. eine kollidierende Datei mit gleichem Hash zu konstruieren, aber ungleich schwieriger, dafür zu sorgen, dass diese dann auch eine ausführbare, (schadhafte) Datei ist.

Das gilt aber nur so lange, wie die Hashfunktion “ideal” ist, deshalb gibt es hier

Die lange Antwort:

Eine gute Hashfunktion zum Generieren von Datei-Fingerabdrücken muss folgende Anforderungen erfüllen: