In diesem Tut gehts garnet um Kryptographie selbst, sondern um ein paar Grundkonzepte, was das Framework dafür bereitstellt, und wie mans verwendet.
Insgesamt kann man sagen, die Kryptographie hat einen sehr hohen Stand der Technik erreicht, sowohl was das Knacken angeht als auch das Verschlüsseln. Der Stand der Verschlüsselungs-Technik ist im Framework enthalten, und zum Stand der Technik gehört, dass dann nicht geknackt werden kann, wenn man den Stand der Technik richtig anwendet
Aber man muß sich einiges klar machen, sonst öffnet man Angreifern Tür und Tor. Ich selbst bilde mir auch erst seit 2 Tagen ein, die Konzepte hinreichend verstanden zu haben, nämlich erst nach der Auseinandersetzung mit diesem Thread, genaugenommen dieser Post - vielen Dank an picoflop!
,Sicher habich was übersehen, aber dieser Post ist doch tatsächlich die einzige Stelle im Internet, wo mal erklärt wird, was ein Salt ist, und was ein IV ist, und was der Unterschied, und wozu gut.
Ich fund haufenweise zu Kryptografie, aber immer fehlte das eine oder annere Detail, dasses sich zu einem sinnvollem Ganzen zusammengefügt hätte.
Aber dazu später.
Zunächst mal klarmachen viel grundlegenderer Grundlagen:
Kryptographie hat nix mit Strings oder Texten zu tun.
Durcheinandergewürfelt werden rohe Bytes, und zwar in der grundlegendsten Form, in der Bytes auftreten können, nämlich als Stream.
Die Bytes können Text bedeuten - aber auch alles andere. Was die Bytes bedeuten, geht die Kryptographie jedenfalls schon nix mehr an.
Also Codesamples, die Ver-/Ent-schlüsseln anhand von Textboxen demonstrieren, sind schonmal verdächtig. Denn ein CipherText ist reiner Byte-Salat, und so garnet in einer Textbox darstellbar. Wenns gut gemacht ist, wird der Byte-Salat zur Anzeige nochmal umgeformt in einen Base64-String, aber das verschleiert immer noch die Mächtigkeit des Konzepts, nämlich dass jede Art von Daten verarbeitbar ist - weit mehr als nur Strings.
Man redet zwar von Klartext und Cyphertext, aber damit sind keine Texte gemeint, sondern amorphe Byte-Folgen. Der einzige Text, den Kryptografie kennt, ist das Passwort, und manchmal ist auch dieses nicht-textuell.
Authentifikation versus Verschlüsselung
Es ist fundamental wichtig, Authentifikation und Verschlüsselung klar auseinanderzuhalten. Für beides braucht man ein Passwort, aber was vor sich geht ist total unterschiedlich (und wird total oft durcheinandergebracht).
Bei beidem wird aus dem Passwort ein Schlüssel generiert ("abgeleitet"). Bei Authentifikation hieß es früher häufig, ein Hash werde gebildet, aber das ist heutzutage nicht mehr Stand der Technik.
Das Ableiten des Schlüssels ist unumkehrbar, also aus einem Passwort kann man einen Schlüssel ableiten, aber es gibt kein Verfahren, um aus einem Schlüssel das Passwort rückzuschließen (jedenfalls nicht, wenn mans richtig gemacht hat).
Beim Autentifizieren wird eiglich nichts mit dem Schlüssel angefangen, er wird nur gespeichert. Das Passwort wird nicht gespeichert - nirgends!
Um sich zu autentifizieren gibt man ein Passwort ein, und darauf wird mit identischem Verfahren ein Schlüssel abgeleitet. Stimmt der gespeicherter Schlüssel mit dem frisch abgeleiteten überein, so ist man autentifiziert.
Verschlüsseln
Beim Verschlüsseln wird ebenso ein Schlüssel aus dem Passwort abgeleitet - mit dem dann aber ver-/ent-schlüsselt wird.
Noch einmal die Begriffe:
Das Passwort ist nicht der Schlüssel, sondern der Schlüssel wird erst davon abgeleitet.
Dieses Ableiten ist keine Verschlüsselung, sondern ist eben das Ableiten eines Schlüssels - es gibt keinen anderen korrekten Begriff dafür. Es ist schon deshalb kein verschlüsseln, weil ein Schlüssel schon vom Wort her etwas ist, mit dem man etwas auf- und zu-schließen kann. Kann man nur "zuschließen", dann ists halt kein Schlüssel (sondern ein Nagel, oder ein Schweißgerät ;)).
Es ist auch kein Verhashen, denn der angewandte Vorgang ist nach Stand der Technik komplizierter.
Schlüssel-Ableitung: das Salt
Das Salt ist eine der Gemeinheiten, die die Kryptographen sich ausgedacht haben, um den Rückschluß vom Schlüssel zum Passwort zu verunmöglichen.
Die Idee ist, einen beliebig generierten zusätzlichen Schlüssel zu erstellen, und diese Byte-Folge in die Ableitung des Schlüssels aus dem Passwort mit einzuarbeiten.
So wird erreicht, dass aus demselben Passwort, mit demselben Algorithmus, unterschiedliche Schlüssel abgeleitet werden!
Ähm - wie soll man sich dann autentifizieren, wenn beim Ableiten jedesmal ein annerer Schlüssel rauskommt 8|.
Naja das Salt muß man halt mitliefern.
Klingt bisserl bescheuert: Erst ein Salt generieren, dann überaus kunstvoll einen Schlüssel ableiten, in dem Passwort und Salt hineinverarbeitet werden, und dann das Salt doch wieder öffentlich mitliefern?
Ja, genau. Das Salt ist eben kein zusätzliches Passwort, sondern ein Hilfsmittel, um zu bewerkstelligen, dass keine 2 Schlüssel sich gleichen, nichtmal vom selben Passwort abgeleitet :P.
Es gibt nämlich Angriffe auf Passworte, die sich zunutze machen würden, wenn sich aus einem Passwort zweimal der gleiche Schlüssel ableitete.
Verschlüsselung: der IV
IV ist Abkürzung für "Initialization-Vector". Und ist ein ebenso dummes Byte-Array, wie zuvor schon Schlüssel und Salt.
Der IV ist eine Notwendigkeit beim Verschlüsseln (wie schön, dass wir das jetzt eindeutig von Autentifizierung und Schlüssel-Ableitung abgrenzen können! ;)).
Stand der Technik sind nämlich symmetrische Verschlüsselungen vom Typ "BlockChiffre mit Feedback". Dabei werden die Daten aufgeteilt und blockweise ver-/ent-schlüsselt. Die Verschlüsselung der einzelnen Blöcke wird aber variiert, nämlich aus dem Ergebnis des Vorgänger-Blocks wird ein "Zusatzschlüssel" abgeleitet, der in die Verarbeitung des nächsten Blocks mit einfliest (das "Feedback"). Sodass zwei aufeinanderfolgende identische Blöcke trotzdem unterschiedliche CipherTexte ergeben.
Naja, und weil der erste Block keinen Vorgänger hat, muß man ihm quasi ersatzweise den Initialisation-Vector (IV) vorgeben.
Also ungefähr die gleiche Idee wie mit dem Salt beim Ableiten des Schlüssels. Und auch dieselbe scheinbare Paradoxie: Erst wird der IV hochsicherheitsmäßig zufalls-generiert, und dann musser in aller Öffentlichkeit mitgeliefert werden, damit erfolgreich entschlüsselt werden kann.
Es wieder einfach machen
Das mit dem Salt und dem IV ist schon sehr umständlich und unintuitiv. Für eine Autentifikation muß man dann ja nicht nur Username und Schlüssel speichern, sondern zusätzlich noch dieses ominöse Salt.
Und einem verschlüsselten Text müsste immer sowohl Salt als auch IV beigelegt sein, sonst kanner auch mit richtigem Passwort nicht gelesen werden.
Die hier vorgestellte Lösung (Download hier, aber Erläuterung im nächsten Post) ist einfach und glaub nichtmal unüblich: Die öffentlichen Zusatz-Daten werden den eigentlichen Cipher-Daten einfach unverschlüsselt vorangestellt - sind ja doch nur Byte-Folgen.
Also dem für die Autentifizierung abgeleiteten Schlüssel wird sein Salt vorangestellt, und dem CipherText werden sowohl IV als auch Salt vorangestellt.
Und schon lassen sich wieder einfach zu benutzende Methoden coden, die ein Passwort gegen einen Schlüssel abgleichen (Autentifikation) bzw. die mit einem Passwort einen Ciphertext entschlüsseln - ohne dass der hier besprochene Zusatzkram irgendwo in der Benutzung auftauchen würde
verblüffend, elegant, aber leider zu schwach
Insgesamt kann man sagen, die Kryptographie hat einen sehr hohen Stand der Technik erreicht, sowohl was das Knacken angeht als auch das Verschlüsseln. Der Stand der Verschlüsselungs-Technik ist im Framework enthalten, und zum Stand der Technik gehört, dass dann nicht geknackt werden kann, wenn man den Stand der Technik richtig anwendet
Aber man muß sich einiges klar machen, sonst öffnet man Angreifern Tür und Tor. Ich selbst bilde mir auch erst seit 2 Tagen ein, die Konzepte hinreichend verstanden zu haben, nämlich erst nach der Auseinandersetzung mit diesem Thread, genaugenommen dieser Post - vielen Dank an picoflop!
,Sicher habich was übersehen, aber dieser Post ist doch tatsächlich die einzige Stelle im Internet, wo mal erklärt wird, was ein Salt ist, und was ein IV ist, und was der Unterschied, und wozu gut.
Ich fund haufenweise zu Kryptografie, aber immer fehlte das eine oder annere Detail, dasses sich zu einem sinnvollem Ganzen zusammengefügt hätte.
Aber dazu später.
Zunächst mal klarmachen viel grundlegenderer Grundlagen:
Kryptographie hat nix mit Strings oder Texten zu tun.
Durcheinandergewürfelt werden rohe Bytes, und zwar in der grundlegendsten Form, in der Bytes auftreten können, nämlich als Stream.
Die Bytes können Text bedeuten - aber auch alles andere. Was die Bytes bedeuten, geht die Kryptographie jedenfalls schon nix mehr an.
Also Codesamples, die Ver-/Ent-schlüsseln anhand von Textboxen demonstrieren, sind schonmal verdächtig. Denn ein CipherText ist reiner Byte-Salat, und so garnet in einer Textbox darstellbar. Wenns gut gemacht ist, wird der Byte-Salat zur Anzeige nochmal umgeformt in einen Base64-String, aber das verschleiert immer noch die Mächtigkeit des Konzepts, nämlich dass jede Art von Daten verarbeitbar ist - weit mehr als nur Strings.
Man redet zwar von Klartext und Cyphertext, aber damit sind keine Texte gemeint, sondern amorphe Byte-Folgen. Der einzige Text, den Kryptografie kennt, ist das Passwort, und manchmal ist auch dieses nicht-textuell.
Authentifikation versus Verschlüsselung
Es ist fundamental wichtig, Authentifikation und Verschlüsselung klar auseinanderzuhalten. Für beides braucht man ein Passwort, aber was vor sich geht ist total unterschiedlich (und wird total oft durcheinandergebracht).
Bei beidem wird aus dem Passwort ein Schlüssel generiert ("abgeleitet"). Bei Authentifikation hieß es früher häufig, ein Hash werde gebildet, aber das ist heutzutage nicht mehr Stand der Technik.
Das Ableiten des Schlüssels ist unumkehrbar, also aus einem Passwort kann man einen Schlüssel ableiten, aber es gibt kein Verfahren, um aus einem Schlüssel das Passwort rückzuschließen (jedenfalls nicht, wenn mans richtig gemacht hat).
Beim Autentifizieren wird eiglich nichts mit dem Schlüssel angefangen, er wird nur gespeichert. Das Passwort wird nicht gespeichert - nirgends!
Um sich zu autentifizieren gibt man ein Passwort ein, und darauf wird mit identischem Verfahren ein Schlüssel abgeleitet. Stimmt der gespeicherter Schlüssel mit dem frisch abgeleiteten überein, so ist man autentifiziert.
Verschlüsseln
Beim Verschlüsseln wird ebenso ein Schlüssel aus dem Passwort abgeleitet - mit dem dann aber ver-/ent-schlüsselt wird.
Noch einmal die Begriffe:
Das Passwort ist nicht der Schlüssel, sondern der Schlüssel wird erst davon abgeleitet.
Dieses Ableiten ist keine Verschlüsselung, sondern ist eben das Ableiten eines Schlüssels - es gibt keinen anderen korrekten Begriff dafür. Es ist schon deshalb kein verschlüsseln, weil ein Schlüssel schon vom Wort her etwas ist, mit dem man etwas auf- und zu-schließen kann. Kann man nur "zuschließen", dann ists halt kein Schlüssel (sondern ein Nagel, oder ein Schweißgerät ;)).
Es ist auch kein Verhashen, denn der angewandte Vorgang ist nach Stand der Technik komplizierter.
Schlüssel-Ableitung: das Salt
Das Salt ist eine der Gemeinheiten, die die Kryptographen sich ausgedacht haben, um den Rückschluß vom Schlüssel zum Passwort zu verunmöglichen.
Die Idee ist, einen beliebig generierten zusätzlichen Schlüssel zu erstellen, und diese Byte-Folge in die Ableitung des Schlüssels aus dem Passwort mit einzuarbeiten.
So wird erreicht, dass aus demselben Passwort, mit demselben Algorithmus, unterschiedliche Schlüssel abgeleitet werden!
Ähm - wie soll man sich dann autentifizieren, wenn beim Ableiten jedesmal ein annerer Schlüssel rauskommt 8|.
Naja das Salt muß man halt mitliefern.
Klingt bisserl bescheuert: Erst ein Salt generieren, dann überaus kunstvoll einen Schlüssel ableiten, in dem Passwort und Salt hineinverarbeitet werden, und dann das Salt doch wieder öffentlich mitliefern?
Ja, genau. Das Salt ist eben kein zusätzliches Passwort, sondern ein Hilfsmittel, um zu bewerkstelligen, dass keine 2 Schlüssel sich gleichen, nichtmal vom selben Passwort abgeleitet :P.
Es gibt nämlich Angriffe auf Passworte, die sich zunutze machen würden, wenn sich aus einem Passwort zweimal der gleiche Schlüssel ableitete.
Verschlüsselung: der IV
IV ist Abkürzung für "Initialization-Vector". Und ist ein ebenso dummes Byte-Array, wie zuvor schon Schlüssel und Salt.
Der IV ist eine Notwendigkeit beim Verschlüsseln (wie schön, dass wir das jetzt eindeutig von Autentifizierung und Schlüssel-Ableitung abgrenzen können! ;)).
Stand der Technik sind nämlich symmetrische Verschlüsselungen vom Typ "BlockChiffre mit Feedback". Dabei werden die Daten aufgeteilt und blockweise ver-/ent-schlüsselt. Die Verschlüsselung der einzelnen Blöcke wird aber variiert, nämlich aus dem Ergebnis des Vorgänger-Blocks wird ein "Zusatzschlüssel" abgeleitet, der in die Verarbeitung des nächsten Blocks mit einfliest (das "Feedback"). Sodass zwei aufeinanderfolgende identische Blöcke trotzdem unterschiedliche CipherTexte ergeben.
Naja, und weil der erste Block keinen Vorgänger hat, muß man ihm quasi ersatzweise den Initialisation-Vector (IV) vorgeben.
Also ungefähr die gleiche Idee wie mit dem Salt beim Ableiten des Schlüssels. Und auch dieselbe scheinbare Paradoxie: Erst wird der IV hochsicherheitsmäßig zufalls-generiert, und dann musser in aller Öffentlichkeit mitgeliefert werden, damit erfolgreich entschlüsselt werden kann.
Es wieder einfach machen
Das mit dem Salt und dem IV ist schon sehr umständlich und unintuitiv. Für eine Autentifikation muß man dann ja nicht nur Username und Schlüssel speichern, sondern zusätzlich noch dieses ominöse Salt.
Und einem verschlüsselten Text müsste immer sowohl Salt als auch IV beigelegt sein, sonst kanner auch mit richtigem Passwort nicht gelesen werden.
Die hier vorgestellte Lösung (Download hier, aber Erläuterung im nächsten Post) ist einfach und glaub nichtmal unüblich: Die öffentlichen Zusatz-Daten werden den eigentlichen Cipher-Daten einfach unverschlüsselt vorangestellt - sind ja doch nur Byte-Folgen.
Also dem für die Autentifizierung abgeleiteten Schlüssel wird sein Salt vorangestellt, und dem CipherText werden sowohl IV als auch Salt vorangestellt.
Und schon lassen sich wieder einfach zu benutzende Methoden coden, die ein Passwort gegen einen Schlüssel abgleichen (Autentifikation) bzw. die mit einem Passwort einen Ciphertext entschlüsseln - ohne dass der hier besprochene Zusatzkram irgendwo in der Benutzung auftauchen würde
@RodFromGermany' stellt einen sehr eleganten Algo vor, mit dem man einen String in Byte-Salat verwandeln kann und zurück.
Aber - wichtig!! - als ernstgemeinte Verschlüsselung leider unbrauchbar: Also Dilletanten kann man damit abwehren, aber bereits ein Kryptographie-Amateur wird dem auf die Schliche kommen.
Aber - wichtig!! - als ernstgemeinte Verschlüsselung leider unbrauchbar: Also Dilletanten kann man damit abwehren, aber bereits ein Kryptographie-Amateur wird dem auf die Schliche kommen.
Dieser Beitrag wurde bereits 9 mal editiert, zuletzt von „ErfinderDesRades“ ()