Das deutsche Python-Forum

naheliegend hat geschrieben: ↑Donnerstag 21. Januar 2021, 18:00 Man würde ja nicht nach dem entschlüsselten Wert suchen, sonder nach dem verschlüsselten.
[...]
Ober habe ich einen Denkfehler?

Du gehst davon aus dass wenn man einen Wert verschlüsselt jedesmal der gleiche verschlüsselte Wert herauskommt. Ein Algorithmus der sich so verhält wäre allerdings nicht semantically secure. Ein guter Algorithmus wäre dies allerdings und damit wäre dann deine Annahme falsch.

@sparrow: Das geht dann halt nicht, bzw erst nach dem entschlüsseln im Code.

@naheliegend: Genau. Du raubst damit der Datenbank ihrer Funktion. Das macht vielleicht für Passwort-Hashes Sinn, aber nicht für normale Nutzdaten.

DasIch hat geschrieben: ↑Donnerstag 21. Januar 2021, 19:31

naheliegend hat geschrieben: ↑Donnerstag 21. Januar 2021, 18:00 Man würde ja nicht nach dem entschlüsselten Wert suchen, sonder nach dem verschlüsselten.
[...]
Ober habe ich einen Denkfehler?

Du gehst davon aus dass wenn man einen Wert verschlüsselt jedesmal der gleiche verschlüsselte Wert herauskommt. Ein Algorithmus der sich so verhält wäre allerdings nicht semantically secure. Ein guter Algorithmus wäre dies allerdings und damit wäre dann deine Annahme falsch.

Ich dachte nur Hashfunktionen seien kollisionssicher. Wie soll denn symmetrische Verschlüsselung funktionieren, wenn immer was anderes herauskommt?

@naheliegend: Wir bleiben mal bei deinem Beispiel:

Hans -> encryp. -> 4fsdo23

Das heißt, aus deinem Hans mit 4 Zeichen wird eine verschlüsselte Variante mit 7 Zeichen. Und wenn du jetzt alle Vornamen haben willst, die "Hans" enthalten? Hans-Jürgen, Olaf-Hans und Hans-Peter-Hans? Wenn die "Verschlüsselung" wirklich nur ein Austausch einzelner Zeichen ist, dann kann man sie sich auch sparen. Oder soll das dann auch wieder in der Software gemacht werden? Dann kann man sich auch die Datenbank sparen.

naheliegend hat geschrieben: ↑Donnerstag 21. Januar 2021, 20:59 Ich dachte nur Hashfunktionen seien kollisionssicher. Wie soll denn symmetrische Verschlüsselung funktionieren, wenn immer was anderes herauskommt?

Hashfunktionen sind nicht kollisionssicher. Der Output bei Hashfunktionen ist auf eine bestimmte Größe beschränkt, deswegen muss es nachdem pigeonhole principle zu Kollisionen kommen. Diese Einschränkung gibt es bei symmetrischer Verschlüsselung nicht, deswegen gibt es keine Kollisionen. Ob jedesmal was anderes herauskommt ist völlig egal, schliesslich kann prinzipiell unendlich viel rauskommen.

Wenn du im Detail wissen willst wie symmetrische Verschlüsselung funktioniert, würde ich dir empfehlen da einen entsprechende Kurs zu nehmen o.ä., dazu gibt es ja genug Material.

Konkret hier dürfte dich allerdings das Thema IV und auch nonce interessieren.

sparrow hat geschrieben: ↑Donnerstag 21. Januar 2021, 22:28 @naheliegend: Wir bleiben mal bei deinem Beispiel:

Hans -> encryp. -> 4fsdo23

Das heißt, aus deinem Hans mit 4 Zeichen wird eine verschlüsselte Variante mit 7 Zeichen. Und wenn du jetzt alle Vornamen haben willst, die "Hans" enthalten? Hans-Jürgen, Olaf-Hans und Hans-Peter-Hans? Wenn die "Verschlüsselung" wirklich nur ein Austausch einzelner Zeichen ist, dann kann man sie sich auch sparen. Oder soll das dann auch wieder in der Software gemacht werden? Dann kann man sich auch die Datenbank sparen.

Warum kann man sich das denn sparen? Man bräuchte doch den Schlüssel um das zu decodieren..

Und wenn der Hacker den Schlüssel abgreift (Zugriff auf das System hatter er ja schon, daran scheitert es nicht), dann entschlüsselt er dein Passwort & benutzt es gleich bei einem anderen Account, weil viele Leute das gleiche Passwort überall benutzen.

Speichert man hingegen den hash, dann ist das deutlich schwieriger, denn das eingegebene Passwort des users wird einfach gehasht verglichen.

@nahegliegend:

Relationale Datenbanken sind darauf optimiert, bestimmte Dinge für dich zu tun. Die sind eigentlich nicht dafür gedacht ein "dummer" Ablageort für Daten zu sein. Jetzt mal unabhängig von Transaktionssicherheit und ACID beinhalten Datenbanken die Möglichkeit Daten zu selektieren. Möchte ich alle Einträge haben, bei denen "Hans" irgendwo im Vornamen steckt, dann kann ich die Datenbank das fragen, die Datenbank antwortet mit allen Datensätzen, die das entsprechend enthalten. Vorteil: die Selektion wird auf dem Datenbankserver ausgeführt - in der Anwendung kommt nur an, was man braucht. Es werden also nicht alle fantastrillionen Datensätze über das Netz gehievt.

Damit die Datenbank auch nach deiner "Verschlüsselung" noch über die Möglichkeit verfügt, das effektiv zu können, muss "Hans" in der Datenbank immer gleich heißen. Billigst: indem man immer den nächsten Buchstaben aus dem Alphabet wählt. Das ist dann dein "Schlüssel". Und das kann man sich sparen. Wenn man nämlich das als Schutz für seine Daten sieht, dann möge man bedenken: es gibt gute Statistiken über die Häufigkeit und Verteilung von Buchstaben in Namen.

Natürlich könnte man jetzt in der Anwendung sicherere Verschlüsselungen anwenden. Aber wie willst du dann sicherstellen, dass "LIKE '%HANS%'" noch funktioniert?
Oder willst du das der Datenbank dann beinbringen? Dass sie dann für die Query jedes Feld entschlüsselt, damit es auch nicht zu perfomant wird?
Mal ganz abgesehen davon, dass das Verfahren zum Ver- und Entschlüsseln ja eh in der Anwendung steckt.

danke sparrow