Verschlüsselte Daten sicher?
-
Ich habe eine Datei, in welche verschlüsselte Daten zeilenweise geschrieben werden.
Zur Verschlüsselung wird Blowfish verwendet und der gleiche Schlüssel für jede Zeile.Da die Zeilen nur angehängt werden ist das verschlüsselte Zeichen in den Zeilen gleich wenn der Buchstabe übereinstimmt.
Z.B. ist das Wort in der 1. und 3. Zeile "Das" und die Datei sieht so aus:5F3E246A
35FE2C25
5F3E246A(jeweils der erste Buchstabe).
Ist das eine große Sicherheitslücke bzw. wie kann ich diese verbessern?
-
Simonek schrieb:
Ist das eine große Sicherheitslücke bzw. wie kann ich diese verbessern?
Evtl. schon, weil man dann Haeufigkeitsanalysen machen koennte. Verbessern kannst du's logisch, indem du den ganzen Text ein einem Rutsch verschluesselst.
-
Wenn du die Daten nicht in einem Rutsch verschlüssel kannst hilft es vielleicht, wenn du die Daten modifizierst (zB erstellst du eine Zufallszahl, die du zu den Daten addierst. Die legst du dann als erstes Zeichen ab etc.)
-
Du könntest auch z.B. den Klartext von Zeile 10 verwenden um den Schlüssel für Zeile 11 zu modifizieren.
Dazu müsstest du natürlich alle vorhergehenden Zeilen entschlüsseln um eine Zeile anzuhängen, da der Schlüssel für Zeile 10 ja wieder vom Klartext von Zeile 9 abhängt, damit du da drankommst musst du Zeile 8 entschlüsseln etc.
Alternativ könntest du den Verschlüsselten Text von Zeile 10 verwenden um den Schlüssel für Zeile 11 zu modifizieren, aber ich schätze das wird weniger sicher sein.Was auch öfter verwendet wird ist vor und hinter den eigentlichen Daten eine Reihe von Zufallszahlen mit zu verschlüsseln -- und zwar jeweils einen Block von Zufallszahlen variabler Länge. Natürlich musst du noch irgendwo eintragen wie viele Zufallszahlen vorne und hinten angehängt wurden, das kannst du z.B. im ersten Byte des zu verschlüsselnden Blocks eintragen.
Nach dem entschlüsseln musst du dann nur gucken wie viele Bytes du vorne und hinten wegschneiden musst um an deinen Klartext zu kommen.Dadurch werden dann Verschlüsselte Versionen von "Das" nicht nur unterschiedlich aussehen, sondern auch unterschiedlich lange sein, was auch oft ein Vorteil ist.
-
Macht das auch Sinn für ein Open Source Programm?
Ich denke wenn man weiß, wo die Zufallszahlen gespeichert werden bringt es nicht unbedingt mehr Sicherheit.
Das mit dem verschlüsseln mit dem Klartext der Vorgängerzeile ist eine gute Idee.
Aber wie wirkt sich das auf die Performance aus wenn ich z.B. die 1000. Zeile entschlüsseln will und praktisch von Zeile 1 aus anfangen muss.Da würde je jede weitere Zeile das Programm langsamer machen
-
du kannst die Zufallszahlen ja zufällig positionieren, was wohl auch der Sinn der Sache ist.
Wobei ich meine Methode besser finde, da es die Variabilität der Daten erhöhen dürfte.
-
Simonek schrieb:
Macht das auch Sinn für ein Open Source Programm?
Was genau willst du denn eigentlich wovor schützen? Bei einem Opensource-Programm kann natürlich jeder die Verschlüsselung aus dem Code entfernen und das Ding neu bauen.
-
Simonek schrieb:
Ich denke wenn man weiß, wo die Zufallszahlen gespeichert werden bringt es nicht unbedingt mehr Sicherheit.
Es geht doch darum, dass der Chiffre eines Wortes nicht immer gleich aussieht, um Häufigkeitsanalysen zu verhindern. Die Zufallszahl kann ruhig immer an der selben Stelle eingefügt werden, aber natürlich nicht im Chiffre sondern im Klartext. Dadurch sieht dann der Chiffre des selben Klartextes (fast) immer anders aus.
-
Simonek schrieb:
Macht das auch Sinn für ein Open Source Programm?
Ich denke wenn man weiß, wo die Zufallszahlen gespeichert werden bringt es nicht unbedingt mehr Sicherheit.
Das mit dem verschlüsseln mit dem Klartext der Vorgängerzeile ist eine gute Idee.
Aber wie wirkt sich das auf die Performance aus wenn ich z.B. die 1000. Zeile entschlüsseln will und praktisch von Zeile 1 aus anfangen muss.Da würde je jede weitere Zeile das Programm langsamer machen
Ok, das ganze sieht wie folgt aus:
Du nimmst deinen Klartext: "ABCDEFG" (Länge ist 7)
Jetzt berechnetst du eine Zufallszahl von z.B. 0-15, sagen wir du bekommst 5 raus, d.h. du hängst vorne 5 "Schrottzahlen" dran. Das neue Paket sieht dann so aus: "rrrrrABCDEFG" (Länge 12). Da der Decoder wissen muss wo der Klartext beginnt und aufhört müssen wir die Information auch noch irgendwo mit reinpacken, also reservieren wir dafür noch eine Stelle, sagen wir wir packen das am Anfang rein, sieht das neue Paket so aus: "XrrrrrABCDEFG" (Länge 13). Nun runden wir auf 16 auf, dazu müssen wir hinten noch 3 Zufallszahlen dranpacken: "XrrrrrABCDEFGrrr" (Länge 16). Um nun dem Decoder mitzuteilen dass er vorne 1+5 (X und noch 5) und hinten 3 wegschneiden muss, können wir X einfach als X=5+3*16 speichern, und sind fertig.Das Ganze hat wie schon erwähnt den Vorteil dass a) die Originallänge des Klartextes nicht aus dem Ciphertext ersichtlich ist und b) Angriffe enorm erschwert werden die darauf basieren dass man z.B. Stelle X-Y im Klartext kennt.
@rüdiger: Ein guter Verschlüsselungsalgorithmus verwurstet die Daten sowieso schon selbst, d.h. ob du nur vorne eine Zufallszahl dranstellst, oder die Zufallszahl dranstellst UND dann noch diese auf den Rest vom Klartext draufaddierst, sollte keinen Unterschied machen. Genau für solche Dinge (Klartext verwursten) ist ja der Verschlüsselungsalgorithmus zuständig, das sollte man also nicht vorher noch extra machen müssen.
Wenn man deinen Vorschlag ins Extrem weiterdenkt landet man dort wo man z.B. einen zufäligen Key ausrechnet, den vorne dranstellt, den Klartext dann mit diesem zufälligen Key verschlüsselt (z.B. mit IDEA), und die ganze Wurst (zufälliger Key + 1x verschlüsselter Klartext) dann mit dem fixen Key mit z.B. Blowfish verschlüsselt. Theoretisch könnte man auch 2, 3 ... N solche Runden vorher machen.
Ob das allerdings mehr bringt als wenn man eben gleich nur vorne die Zufallsdaten dranpackt, und sich die "Vorverschlüsselung" ganz spart, ist wie gesagt IMHO fraglich.
-
MFK schrieb:
Simonek schrieb:
Macht das auch Sinn für ein Open Source Programm?
Was genau willst du denn eigentlich wovor schützen? Bei einem Opensource-Programm kann natürlich jeder die Verschlüsselung aus dem Code entfernen und das Ding neu bauen.
Es geht darum Eingaben des Benutzes zu schützen.
Daher ist der Key im Programm nicht selbst vorhanden, sondern wird vom Benutzer eingegeben.@hustbaer: Danke für den ausführlichen Tipp!
Ich werde es mal versuchen umzusetzen
