Symmetrische und asymmetrische Verschlüsselung - allgemeines Verständnis

[py]

Ich habe mich in den letzten Tagen etwas mit Verschlüsselung und auch Passkeys auseinandergesetzt.
Dazu kamen mir ein paar Fragen, die mir nicht so klar sind.

Mein Wissensstand:
Normale Passwörter sind der symmetrischen Verschlüsselung zuzuordnen. Das heißt, dass es ein Geheimnis gibt, mit dem beide Seiten die Nachricht entschlüsseln oder verschlüsseln.
Nun ist es nicht schlau, dieses Geheimnis preiszugeben. Also ist eine Speicherung Klartext auf einem Server alles andere als gut, wenn man irgendwo online ein Konto eröffnet. Deshalb werden die Passwörter mit einem Hash versehen, der sich aus dem Passwort/Geheimnis ergibt. Allerdings ist nur eine Richtung möglich, was bedeutet, dass vom Passwort via Hashfunktion (ich meine, dies passiert mit "Argon2", "PBKDF2" oder "bcrypt" im Idealfall) ein Hashwert erzeugt wird, welcher sich aber nicht rückgängig machen lässt. Also eine maximale Entropie aufweist. Quasi so, als würde man Milch in den Kaffee schütteln und dann umrühren. Dreht man in die andere Richtung, trennt sich die Milch vom Kaffee nicht. Jedenfalls in diesem Universum. Soweit mir bekannt, ist das auch das "P versus NP"-Problem, bei dem man davon ausgeht, das N ungleich NP ist und es somit Einwegfunktionen gibt, was aber noch nicht beweisen wurde. Aber wir gehen hier davon aus.
Da es allerdings "Rainbow Table" gibt, bei dem Menschen den Hashwert von Passwörter (oder mögliche Passwörter) schon vorab errechneten, damit man so trotzdem Rückschlüsse auf das Passwort ziehen kann, wenn man in einen Server eingedrungen und die Liste von Hashwerten zu den Passwörtern erbeutet hat. Deshalb werden diese die Passwörter idealerweise "gesalzen", das heißt, dass ein Passwort mit einer Zeichenkombination erweitert wird, die auch auf dem Server meines Wissens nach gespeichert wird.
Gibt man nun sein Passwort auf einer Internetseite an, wird dann daraus inkl. der Zeichenkombination ("salz") der Hashwert gebildet und verglichen und wenn das Ergebnis korrekt ist, ist der Zugang gewährt.

Bei Passkeys kommt die asymmetrische Verschlüsselung zum Einsatz, die man auch von PGP oder auch Kryptowährungen und deren Wallets her kennt. Nun wird ein privater Schlüssel erzeugt, welches nur dem Besitzer bekannt ist. Also im Unterschied nicht beiden. Aus diesem Schlüssel wird dann der öffentliche Schlüssel abgeleitet. Auch hier gilt, dass es nur eine Richtung gibt. Das heißt, man kann vom privaten Schlüssel den öffentlichen erzeugen, allerdings nicht vom öffentlichen auf den privaten Schlüssel kommen. Man kann durch den öffentlichen Schlüssel validieren, dass der private Schlüssel dazugehört. Während der öffentliche Schlüssel dann auf dem Server liegt und keine Gefahr darstellt, liegt der private Schlüssel nur bei mir. Wenn ich mich nun anmelden will, sendet der Server mittels öffentlichem Schlüssel eine Art Prüfung, um zu sehen, ob der private Schlüssel auch wirklich dazugehört. Dieser kann es dann bestätigen. Das funktioniert wie bei der Signatur von E-Mails bei PGP. Danach hat man den Zugang und die Tür ist offen. Da der private Schlüssel aber auch Informationen zur Website hat und somit auch der öffentliche Schlüssel, funktioniert kein Phishing mehr. Auch nicht, weil ein anderer öffentlicher Schlüssel keine Genehmigung oder Antwort vom privaten Schlüssel bekommen würde.

Nun ist mir allerdings nicht klar, inwieweit mein Ausführungen hier korrekt sind. Beim schreiben merkte ich allerdings schon, dass mir einige Details fehlen und das ein oder andere nicht ganz sinnig erscheint.

Deshalb bitte ich darum, ob sich das jemand mit Ahnung ansehen und mich in den Punkten kordieren könnte. Würde bestimmt auch anderen für das allgemeine Verständnis von Verschlüsselung helfen.

Dazu habe ich allerdings auch paar explizite Fragen:

1. Ich erwähnte oben die Hashfunktionen. Warum nutzt man denn nicht so etwas wie "MD5" oder "SHA512", womit man auch Software verifiziert?

2. Wenn dem Serverbetreiber der "salz" bekannt ist, weil er den braucht und somit irgendwo gespeichert haben muss, ist dass dann nicht auch ein Sicherheitsproblem bei Einbruch in den Server?
Oder könnte der Betreiber dies nicht auch nutzen, womit das Versprechen, man kenne die Passwörter nicht zwar gilt, aber man mit Aufwand und "Rainbow Table" rankommen könnte?

3. Wir bei der asymmetrische Verschlüsselung der öffentliche Schlüssel vom privaten Schlüssel auch über eine Hashfunktion abgeleitet oder wie funktioniert es im Detail (es reicht mir, wenn es in einfachen Worten erklärt wird)?

4. Sind somit die öffentliche Schlüssel nur die Hashwerte der privaten Schlüssel?

5. Wenn wie in 3. beschrieben eine Hashfunktion zum Einsatz kommt, wo genau ist der Vorteil von asymmetrischer Verschlüsselung?
Liegt der Vorteil nur daran, dass die privaten Schlüssel dann viel länger sind und keinen Sinn ergeben und somit "Rainbow Tables" sehr viel schwieriger bis unmöglich zu erstellen sind?

Wie ihr seht, verstehe ich das alles noch nicht so genau, möchte es aber gerne.
Ich hoffe, ihr könnt mir hierbei helfen und mir unter die Arme greifen.

PS: Ich hoffe, es ist nicht zu viel Text.

[duda]

Asymmetrische Verschlüsselung

Bei der asymmetrischen Verschlüsselung spricht man auch von einem "Schlüsselring". Verschlüsselt wird immer mit dem öffentlichen Schlüssel(teil), entschlüsselt wird immer mit dem privaten (geheimen) Schlüssel(teil). Öffentlicher und privater Schlüssel (public and private key) bilden immer eine untrennbare Einheit.

Praxisbeispiel:
Möchte ich asymmetrisch verschlüsselt kommunizieren, muss mir zwingend der öffentliche Schlüssel(teil) (public key) meines Kommunikationspartners zur Verfügung stehen. Ich verwende diesen öffentlichen Schlüssel(teil) zum Verschlüsseln, mein Kommunikationspartner verwendet seinen privaten (geheimen) Schlüssel(teil) zum Entschlüsseln der Nachricht. So ist sichergestellt, dass wirklich nur der bestimmungsgemäße Empfänger der Nachricht diese entschlüsseln kann. Das gilt natürlich nur dann, wenn das Schlüsselpaar (insbesondere der private, geheime Schlüsselteil) unkompromittiert ist und bleibt.

Die Vertraulichkeit kann noch zusätzlich aufgewertet werden, indem man die asymmetrisch verschlüsselte Nachricht signiert (unterschreibt, elektonische Unterschrift). Die Signatur erfolgt mit dem eigenen (privaten) Schlüssel(teil). Die Verifizierung beim Empfänger erfolgt mit dem dazu passenden öffentlichen Schlüssel(teil), der auch hierzu zwingend und unkompromittiert zur Verfügung stehen muss.

Die aktuell (noch) als relativ sicher geltende Schlüsselstärke (Minimum): 4.096 bit (4K-Schlüssel)

[duda]

1. Ich erwähnte oben die Hashfunktionen. Warum nutzt man denn nicht so etwas wie "MD5" oder "SHA512", womit man auch Software verifiziert?

Secure Hash Algorithm

MD5 und SHA1 gelten schon seit geraumer Zeit als "vulnerable" (anfällig, gefährdet, verwundbar, verletzlich). Vor diesem Hintergrund sind diese Hash-Algorithmen sozusagen EoL (End of Life) und sollten daher nicht mehr verwendet werden.

Die Hash-Algorithmen SHA-2 und SHA-3 gelten derzeit jedoch (noch) als relativ sicher.

[cane]

1: Hash Verfahren haben unterschiedliche Eigenschaften:

- Die SHA-Famile (SHA256, SHA384, SHA512) kann sehr schnell für große Datenblöcke berechnet werden. Deshalb werden diese Verfahren eingesetzt, um die Echtheit von Daten zu verfizieren (bei Stromverschlüsselung wie TLS oder Blockverschlüsselung von Festplatten oder Zertifikaten...)

- Für das Hashen von Passwörtern ist genau diese Eigenschaft der SHA-Famile ungünstig. Ein Angreifer könnte in den Besitz der Hashes gelangen und mit Brute Force so lange alle Buchstabenkombinationen durchprobieren, bis eine Kombination findet, die den gleichen Hash erzeugt. Je schneller eine Hashfunktion berechnet werden kann umso leichter ist der Brute Force Angriff.

Deshalb hasht man Passwörter mit Verfahren, die den Aufwand für den Angreifer in die Höhe treiben, aber für einen einzelnen Hash über kleine Datenmengen mit erträglicher Verzögerung berechnet werden können (bcrypt, Argon2). Außerdem sollte Berechnung der Hash Funktion für Passwörter nicht einfach parallelisierbar sein, damit man die Power von Grafikkarten nicht für Brute Force Angriffe nutzen kann.

Der "Salt" wird auf dem Server gespeicher (im Klartext). Er dient dazu, die Länge des gehashten "Passwortes" zu vergrößern, um Angriffe mit Rainbow Tables zu erschweren. Es wird "Salt+Passwort" gehasht. Der Angreifer braucht aufgrund des "Salt" wesentlich größere Rainbow Tables um das gleiche Passwort zu knacken - "Salt" treibt also den Aufwand für einen speziellen Angriff in die Höhe.

2: Asymetrische Krypto und Hashverfahren sind völlig unterschiedliche Dinge.

- Eine Hashfunktion kann (sollte) nur in eine Richtung berechenbar sein aber nicht die org. Daten aus dem Hashwert wiederherstellen können.

- Bei asymetrischer Krypto will man verschlüsseln und entschlüsseln, signieren und Signatur prüfen. Diese Verfahren müssen also in beide Richtungen funktionieren (und möglichst effizient in beide Richtungen).

- Bei asymmetrischer Krypto ist der öffentliche Schlüssel kein Hash des privaten Schlüssel. Bei RSA wird der öffentliche Schlüssel nach einem komplizierten Verfahren vom privaten Schlüssel abgeleitet - aber das gilt nur spezifisch für RSA, ist keine Gesetzmäßigkeit. Bei anderen Verfahren könnte es prinzipiell auch anders herum sein oder beide Schlüssel könnten aus einem Prozess gemeinsam entstehen... Krypto ist eine komplizierte Sache.

Passkey benötigt ein kryptografisches Verfahren, das in beide Richtung funktioniert (Signatur berechnen und Signatur verifizieren mit einem individuellen Schlüssel für jeden Benutzer), also symmetrische Kryptografie. Krypptografische Grundlage für Passkey ist der FIDO2 Standard.

[py]

Krypto ist eine komplizierte Sache.

Das habe ich auch gemerkt und es ist viel komplizierter als es teilweise so schön simpel dargelegt wird. Zwar ist das gut für die Intuition, allerdings merkt man beim genaueren Nachdenken, dass das Puzzle nicht ganz vollständig ist. Deshalb Danke an euch für eure antworten!

Bei asymetrischer Krypto will man verschlüsseln und entschlüsseln, signieren und Signatur prüfen. Diese Verfahren müssen also in beide Richtungen funktionieren (und möglichst effizient in beide Richtungen).

Heißt aber nicht, dass man vom öffentlichen Schlüssel auf den privaten schließen kann oder? Denn das würde ja gegen eine Einwegfunktion sprechen und damit gegen das P-NP-Problem. Oder wie kann ich das verstehen? Denn Wikipedia schreibt folgendes:

In der Kryptologie ist Komplexität im Gegensatz zu den meisten anderen Bereichen eine erwünschte Eigenschaft. Die Sicherheit einiger asymmetrischer Verschlüsselungsverfahren basiert allein auf diesem Faktor. Ein NP-Algorithmus kann ein beliebiges asymmetrisches Kryptosystem brechen, indem er den geheimen Schlüssel ,,errät" und mit dem Verfahren, das der eigentliche Empfänger der Nachricht benutzen würde, dieses effizient entschlüsselt und so den Schlüssel verifiziert. Ein Beweis von P = NP würde also bedeuten, dass die Aussicht besteht, diese Kryptosysteme in der Praxis zu brechen. Entsprechend steht die Lösung des P-NP-Problems in Zusammenhang mit der offenen Frage, ob es Einwegfunktionen gibt. Falls es sie gibt, würde P ≠ NP folgen

https://de.m.wikipedia.org/wiki/P-NP-Problem

Passkey benötigt ein kryptografisches Verfahren, das in beide Richtung funktioniert (Signatur berechnen und Signatur verifizieren mit einem individuellen Schlüssel für jeden Benutzer), also symmetrische Kryptografie. Krypptografische Grundlage für Passkey ist der FIDO2 Standard.

Aber werden Passkeys nicht immer als Aushängeschild für asymmetrische Verschlüsselung genannt? Wie können sie dann symmetrisch sein?
Oder gibt es davon mehrere Definitionen?

So ganz verstehe ich das noch nicht.

[cane]

Heißt aber nicht, dass man vom öffentlichen Schlüssel auf den privaten schließen kann oder?

Wenn man mathematisch ganz exakt sein will, dann ist es bei RSA theoretisch möglich, aus dem öffentlichen Schlüssel den privaten Schlüssel zu berechnen.

Dafür muss man ein diskretes Logarithmusproblem lösen, was bei hinreichend großen Zahlen alle aktuellen Computer der Welt überfordert und einige hunderttausend Jahren dauern würde, wenn man den Empfehlungen zur Schlüssellänge folgt.

Quantencomputer werden das diskretes Logarithmusproblem recht einfach lösen können (vermutet man, bisher nicht praktisch bewiesen), und dann wird RSA Krypto kaputt sein. Die Nachfolger von RSA, die auch Quantencomputern wiederstehen können, wurden jetzt vom NIST in der PQC Competition ermittelt. RSA soll zukünftig durch Kyber ersetzt werden. 

Aber werden Passkeys nicht immer als Aushängeschild für asymmetrische Verschlüsselung genannt?

Sorry - kleiner Tippfehler, große Wirkung.

Ich meinte natürlich, dass Passkey asymmetrische Krypto einsetzt einsetzt!

Die Einführung der Asymmetrie bei FIDO/U2F war der große Vorteil gegenüber symmetrischen Auth.-Verfahren wie Passwort oder OTP (One Time Passwort). Auch wenn ein Angreifer den Server kompromottiert, bekommt er niemals die nötigen Daten für den Login. Nur der Anwender hat den privaten Schlüssel.

(Bei FIDO/U2F und FIDO2 liegt der private Key außerdem auf einem Hardware Token und nicht auf dem Rechner des  Anwenders - hochsicher).

Aus FIDO/U2F wurde FIDO2 und daraus wurde Passkey abgeleitet. Alle drei sind kompatibel.

Im Gegensatz zu FIDO2 (Hardware Security Token für privaten Schlüssel gefordert) dürfen private Passkeys auf dem Computer gespeichert werden und sie werden bei Apple und Google Smartphones in die Cloud synchronisiert, damit man sie auf einem anderen (neuen) Smartphone wiederherstellen kann.

Passkey soll einfacher benutzbar sein (mit Smartphone) als FIDO2, wo die maximale Sicherheit im Vordergrund stand.

[duda]

Die Einführung der Asymmetrie bei FIDO/U2F war der große Vorteil gegenüber symmetrischen Auth.-Verfahren wie Passwort oder OTP (One Time Passwort).

Kaum ein Sicherheits-Feature wird in der Breite mehr missverstanden als die Zwei-Faktor-Authentifizierung. Ein solches fatales Missverständnis begleitet mich gerade mal wieder in meinem beruflichen Umfeld.

[AlphaElwedritsch]

Kaum ein Sicherheits-Feature wird in der Breite mehr missverstanden als die Zwei-Faktor-Authentifizierung.

Was kann da denn falsch verstanden werden? Ein zweiter Faktor zum Ersten... Kann nicht folgen

[duda]

Was kann da denn falsch verstanden werden?

Das kann bspw. ein OTP (One Time Passwort) sein, welches systemgleich erzeugt und per E-Mail (natürlich auch systemgleich) übertragen wird. Das Ganze selbstverständlich unverschlüsselt und unter Windows-Peripherie (Microsoft-Azure-Application-Gateway/v2). Und dieses Konstrukt wird dann als "Zwei-Faktor-Authentifizierung" (2FA) bezeichnet und mit der Zielsetzung "Erhöhung der Sicherheit" begründet.

Ich würde sagen: Thema verfehlt, Sechs!