Skip to content

Mathematik verstehen am Beispiel einer Defintion

Kürzlich ging eine Erschütterung durch die Welt der Kryptografie. Das Paper Quantum Algorithms for Lattice Problems versprach einen neuen Angriff gegen bestimmte Algorithmen. Diese heißen Learning-With-Errors (LWE) und bilden eine Grundlage für Algorithmen, die gegen Quantencomputer sicher sein sollen. Hier spielt eine Menge Mathematik mit hinein. Als Beispiel seht ihr eine halbe Seite aus dem Paper:

Seite 22 des Papers
Seite 22 des Papers

Das Thema klang hinreichend interessant und ich wollte mich ein wenig einlesen. Zum konkreten Paper muss man sagen, dass mittlerweile ein Fehler im Algorithmus gefunden wurde und die Autoren schreiben:

Now the claim of showing a polynomial time quantum algorithm for solving LWE with polynomial modulus-noise ratios does not hold.

Beim Lesen fiel mir wieder etwas auf, was mir schon früher auffiel. Es gibt Sätze, die kommen recht unschuldig daher und klingen leicht verständlich. Dennoch steckt soviel Theorie dahinter, dass es eine Weile dauern könnte, um diese zu durchdringen.

Gleich in der Einführung findet sich ein Beispiel: An n-dimensional lattice L is a discrete additive subgroup of ℝn. (Ein n-dimensionales Gitter L ist eine diskrete additive Untergruppe von ℝn.)

Welche Begriffe muss man verstehen oder interpretieren können, um die Definition zu verstehen?

  1. n-dimensional
  2. diskrete additive Untergruppe
  3. n

Das heißt, nahezu jedes Wort ist erklärungsbedürftig und mit Schulwissen kaum zu durchdringen. Wenn wir jetzt die Wikipedia konsultieren, kommen wir ein Stück weiter. Dort findet sich auch eine Definition des Gitters als diskrete Untergruppe eines euklidischen Raums sowie einige Beispiele. Wenn wir beide Definitionen vergleichen, steht in dem Paper zusätzlich das Wort additiv und anstatt euklidischer Raum wird von ℝn gesprochen. Aus der Wikipedia-Seite zum euklidischen Raum wird schnell klar, dass ℝn ein euklidischer Raum ist. Also sind beide Definitionen ähnlich. Das heißt, mit kleinen Einschränkungen können wir mit der Wikipedia-Definition weiterarbeiten.

Um den Satz nun zu verstehen, sollten wir uns dem zweiten Begriff, der diskreten additiven Untergruppe, zuwenden. Beim Aufdröseln ergeben sich neue Begriffe, die man entweder kennen oder lernen muss.

  • Untergruppe
    • Eine Untergruppe hat eine Verknüpfung (Addition, Multiplikation etc.) und bildet eine Gruppe.
      • Eine Gruppe ist eine Menge mit einer Verknüpfung (Addition, Multiplikation etc.). Bei der Verknüpfung ist es egal, wie man Klammern setzt (Assoziativgesetz), es gibt ein so genanntes neutrales Element und ein inverses Element. Wenn man ein neutrales Element verknüpft, ändert sich nichts, so wie bei einer Addition mit 0. Wenn man ein Element der Menge mit dessem inversen Element verknüpft, erhält man das neutrale Element (12-12=0 bei der Addition, -12 ist das inverse Element).
  • Additive Untergruppe
    • Das ist eine Untergruppe, wo die Verknüpfung Addition heißt.
  • Diskrete Untergruppe
    • Eigentlich geht es hier um diskrete Teilmengen eines Raumes mit der zusätzlichen Eigenschaft, dass diese Teilmenge eine Untergruppe bildet.
    • Eine Teilmenge ist, wie der Name schon sagt, ein Teil der Menge.
    • Diskret bedeutet nun, dass jedes Element der Menge eine Umgebung hat, dass kein weiteres Element der Teilmenge enthält. Das heißt, die einzelnen Elemente der Menge sind isolierte Punkte.
    • Die ganzen Zahlen …, -2, -1, 0, 1, 2, … sind als Teilmenge der reellen Zahlen eine solche Menge. Denn bei jeder Zahl gibt es nach links und rechts einen Abstand, wo sich keine andere Zahl drin findet. Bei den Brüchen (rationale Zahlen) ist das anders. Dort finden sich keine zwei Zahlen mit einem kleinen Abstand, dass keine andere rationale drin läge. Daher ist das keine diskrete Teilmenge.
  • n
    • n ist der n-dimensionale Raum der reellen Zahlen. Aus der Schule kennt man ℝ1 (Zahlenstrahl), ℝ2 (Zahlenebene) und ℝ3 (dreidimensionaler Raum).

Damit haben wir alle Bauteile zusammen, um den obigen Satz zu verstehen. Wobei ich zugeben, muss, dass ich oben einige Abkürzungen genommen habe und auf intuitives Verständnis gesetzt habe. Dennoch reicht das in der Mathematik oftmals nicht. Es ist sinnvoll, sich Beispiele auszudenken. Diese sollten sowohl den positiven Fall abdecken (erfüllt die Definition), aber auch den negativen Fall (erfüllt die Definition nicht). Das sorgt dann wirklich für ein Verständnis des Ganzen.

Das war es auch, was ich am Anfang meinte, als ich von dem kleinen unschuldig klingenden Satz schrieb. Um den zu verstehen, muss man entweder tief im irgendwann mal Erlernten graben oder neues lernen und es dauert eine längere Zeit, bis man ein Paper einmal durchgearbeitet hat. Noch viel länger dauert es, bis man es verstanden hat. :-)

Der obige Satz war der Einstieg in das Paper und nur die Einleitung. Später geht es um gaussche Funktionen und Fouriertransformationen. Das sind Konzepte über die es semesterlange Vorlesungen gibt. Das heißt, um das zu verstehen, kann man wirklich aus den Tiefen der Mathematik schöpfen. Ich wünsche euch viel Spaß bei der Lektüre. :-)

Mit dem Paper haben sich einige andere auseinandergesetzt. Hier findet ihr interessante Lektüre dazu:

security.txt

Kennt ihr noch die Datei robots.txt, die auf verschiedenen Webseiten hinterlegt sind? Dahinter stand der Robots Exclusion Standard und die verschiedenen Bots sollen zuerst die Seite ausweren, bevor sie eine Webpräsenz indexieren. Daneben entstand auch die Idee für eine humans.txt und mit dem “Erschaffen” des .well-known-Verzeichnisses auf dem Webserver gibt es eine ganze Reihe Dateiformate zur Information oder für andere Zwecke.

Seit April 2022 gibt es nun den RFC 9116 für die Datei security.txt. Diese soll anderen helfen, Sicherheitslücken an die richtige Stelle zu melden. Denn oftmals steht das Problem, dass eine Schwachstelle gefunden wurde und es vielleicht unklar ist, wohin diese zu melden ist.

Mail wäre natürlich eine mögliche Wahl. Im besten Fall existiert sogar eine E-Mail-Adresse namens security@. Aber sehr häufig ist dies nicht der Fall. Mails an info@ oder ähnliche Adressen landen eher im Nirwana oder werden mit Standardtextbausteinen beantwortet. Daher ist ein gezielter, standardisierter Weg gut.

Der RFC 9116 definiert hierfür eben die Datei security.txt, die im Unterordner .well-known einer Webpräsenz liegen muss. Die Datei selbst muss über HTTPS erreichbar sein. Ein korrekter Pfad wäre also https://example.com/.well-known/security.txt.

Doch was darf da drin stehen? Naheliegend sind Kontaktinformationen. :-) Spezieller Informationen, an die man Informationen zu Schwachstellen melden kann. Hierfür ist der Eintrag Contact: gedacht. Dieser muss in der Datei enthalten sein und sollte die Kontaktmöglichkeiten in absteigender Reihenfolge enthalten. Daneben benötigt die Datei zwingend ein Ablaufdatum. Eine Minimalversion der Datei kann also so aussehen:

Contact: mailto:security@example.com
Expires: 2023-05-01T12:13:24+02:00

Weiterhin könnt ihr in der Datei Informationen zu einer Policy hinterlegen, welche Sprachen ihr sprecht, ob ihr Leute einstellt, wer in der Vergangenheit Lücken meldete und einen Verweis zu einem Schlüssel machen. Eine erweiterte Version der Datei sähe also so aus:

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

Hier sind mehrere Kontaktmöglichkeiten genannt. Es gibt eine Policy. Die Leute sprechen Deutsch und Englisch und ihr bekommt Infos über andere, die etwas gemeldet haben. Am Schluss findet sich auch ein PGP-Schlüssel. Optimalweise würde der über Web Key Discovery bereit gestellt. Aber das ist ein Thema für einen anderen Beitrag. ;-)

Schließlich könnt ihr den Eintrag auch noch mittels OpenPGP signieren. Dann sähe meine obige Datei so aus:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.19

[Viele Zeichen, die gpg auswerten kann]
-----END PGP SIGNATURE-----

Wenn ihr also eine Schwachstelle gefunden habt, dann lohnt es sich nach der Datei zu schauen und die dort genannten Kontakte anzusprechen. Ich habe mal ein wenig gegraben. Bei den großen, bekannten Seiten, wie Google, Facebook, Twitter, GitHub usw., fand ich jeweils eine solche Datei. Seiten aus dem Microsoft-Universum wie auch viele chinesische Seiten haben keinerlei solche Informationen.

Ansonsten ist das Bild recht gemischt. Während beispielsweise Facebook und WhatsApp eine security.txt anbieten, hat Instagram keine, obwohl alle zum selben Konzern gehören.

Unter andere namhaften Seiten fand ich nichts bei

  • Reddit
  • Wikipedia
  • Zoom
  • Netflix
  • Stackoverflow
  • Apple
  • und weiteren

Hier ist also noch ein wenig Arbeit zu tun. Wenn die Datei auch bei euch oder eurem Arbeigeber fehlt, sprecht die doch an und bittet die, diese Informationen bereitzustellen (und natürlich bei Bedarf zu aktualisieren).

Siehe auch:

Update: Ich hatte übersehen, dass das Expires:-Feld auch ein Pflichtfeld ist und habe die obige Beschreibung ergänzt. Vielen Dank an Jürgen für den Hinweis!

Blog entflickt

In einem Beitrag vor ein paar Tagen kam ich zu der Ansicht, dass spätestens mit der Anwendung der Datenschutz-Grundverordnung am 25. Mai 2018 Flickr nicht mehr genutzt werden kann. Das bedeutete für mich, dass ich mein Blog auf Bilder prüfen muss, die über Flickt eingebunden werden. Soweit ich das sehe, ist das jetzt abgeschlossen. Es sollten keine Bilder mehr über Flickr und andere fremde Quellen kommen.

Weiterhin habe ich geprüft, ob ich bei YouTube-Videos die Domain youtube-nocookie.com verwende. Auch dies sollte jetzt der Fall sein. Damit kommen die Videos hier im Blog entweder von obiger YouTube-Seite oder von media.ccc.de.

Solltet ihr noch Sachen finden, die von woanders eingebunden werden, freue ich mich über einen Hinweis in den Kommentaren.

Wer ist hinter APT3?

Habt ihr schon mal von APT3 oder Gothic Panda oder Buckeye gehört? Oder sagen euch die Operationen Double Tap oder Clandestine Fox etwas?

Zugegeben sind die Aktionen aus dem Jahr 2014 und damit schon etwas älter. Die Gruppe, die als APT3, UPS, Gothic Panda, Buckeye etc., bekannt ist, ist schon weit älter. Das Unternehmen FireEye berichtete bereits im Jahr 2010 zum ersten Mal darüber.

Die Operation Double Tap bestand aus einer Phishing Mail, die Leute zu einer Mitgliedschaft in einem Playboysclub einlud. Wer dann auf den Link in der Mail klickte, gelangte auf eine Webseite, die einen Exploit ausnutzte. Dieser installierte letztlich eine Schadsoftware auf dem Rechner und diese kommunizierte mit einem Server. FireEye hat mehr Details zu der Operation. Die Operation Clandestine Fox war ähnlich interessant.

Nun fragen sich viele, wer eigentlich hinter der Gruppe steckt. Wenn man aktuelle Pressemitteilungen liest, so ergibt sich der Eindruck, dass es immer entweder russische oder chinesische Angreifer sind. Im Falle von APT3 gibt es noch ein paar mehr Hinweise:

  • Die Domainnamen müssen von einer Person registriert werden. Dabei wurde die E-Mail-Adresse mxmtmw@gmail.com angegeben. Ausgehend davon gelang es, eine Person mit dem Namen Wu Yingzhou zu ermitteln. Die Seite https://intrusiontruth.wordpress.com/2017/05/02/who-is-mr-wu/ hat alle Details dazu.

  • Auch bei einer zweiten Domain spielte eine andere E-Mail-Adresse eine wesentliche Rolle. Die Forscher konnten die Person Dong Hao ermitteln.

  • Beide Personen sind Eigentümer der Firma Boyusec. Diese Firma wiederum ist Auftragnehmer des Ministeriums für Staatssicherheit in China.

Das ist doch ein recht klarer Hinweis, dass Boyusec hinter APT3 steckt. Dies folgt einem Trend. Denn viele Dienste lagern die Aufgaben an Privatfirmen aus.

Infosec Bytes -- Videoanleitungen zur sicheren Kommunikation

Ich habe in den letzten Tagen ein wenig mit Infosec Bytes zusammengearbeitet. Die Organisation enstammt dem Centre for Investigative Journalism und möchte anderen Journalisten Trainings im sicheren Umgang mit dem Rechner und dem Netz bieten. Hierzu wurden eine Reihe von Videos veröffentlicht, andere Publikationen sind noch in der Pipeline.

Hier findet ihr beispielsweise eine kleine Einführung zu Tor:

Why journalists and whistleblowers need to understand infosecurity

TLS-Bingo -- Wer bietet mehr?

Ich hatte heute den verwegenen Plan und wollte die Webseite des sächsischen Landtages per HTTPS aufrufen. Der Browser stoppte mich und zeigte eine schöne Fehlermeldung:

Edas
Fehlermeldung zum Zertifikat von edas.landtag.sachsen.de

Also dem Zertifikat traut der Browser nicht. Außerdem fehlen dem weitere Bestandteile. Das Zertifikat ist eigentlich für eine andere Domain und schon längst abgelaufen.

Hier frage ich mich, ob jemand schon mal eine Liste von Zertifikatsfehlern gesehen hat, die länger ist, als die obige. :-)

cronjob