Sry, aber so wird das nichts. Entschuldigung, wenn ich das so direkt sage, aber das hier ist blindes Security-Rumgerate und und das führt zu allem nur nicht zu einem sicheren System.
- Mein Post von oben, war durchaus ernst gemeint und nicht nur "guckt mal her, was ich alles im Studium gelernt habe". Wenn man nicht weiß, vor was man sich schützen will, braucht man gar nicht erst anzufangen. Also @Codehunter: Wenn du wirklich an einem sicheren System interessiert bist, poste hier eine Liste der Angreifer, gegen du dich schützen willst. Am besten gleich noch eine der Angriffsszenarien, aber die können wir auch gemeinsam ableiten.
- @sx2008: Sry, aber deine Verschüsselung ist
IMHO *nicht* sicher. Ich bin jetzt kein ausgemachter Security-Experte, und kann deshalb deinen Algo nicht einfach so im Handumdrehen auseinander nehmen, aber eine handgestrickte Stromchiffre zu bauen (und auch noch auf Basis vom md5) und einfach zu behaupten, sie sei sicher, ist gewagt. Krypto ist kompliziert. Verdammt kompliziert. Und selbst echt Experten haben damit mitunter Probleme.
Ich rate dringend davon ab, Alogs selbst zu erfinden. Nur mal so aus dem Bauch heraus, was ich, der ich mich auch nach drei Security-Vorlesungen noch als Krypto-Laie bezeichnen muss, so vermute:
-- md5 ist gebrochen. Damit kann man vielleicht was lustiges anstellen.
-- wenn das Passwort hartkodiert ist, braucht man sich eh keine mühe machen. Da ist Rot13 gut genug. Aber das mit den Angriffsszenarien hatten wir ja schon.
-- ein Problem sind die Zufallswerte, die mitunter nicht leicht sind, kryptographisch zufällig hinzukriegen
-- die Schlüssel-Verlängerung erscheint mir angreifbar
-- über die #0 im paddedPW kann man ggf. leicht nen Gültigkeitstest bauen. Das macht BruteForce *deutlich* schneller
-- ggf. kann man darüber auch was basteln, weil man ja einen teil des Plaintexts kennt
-- ...
Also bitte: Macht keine Krypto selbst. Benutzt einen bekanntermaßen für sicher befundenen Algo wie AES, aus einer Implementierung von jemandem, dem ihr sehr gute Kryptokenntnisse zutraut (negaH...). Das sichere Verwenden einer Library wie des
DEC ist definitiv kompliziert genug und bietet ausreichend Fehlerpotenzial.
Ich will damit niemandes Bemühungen kleinreden: Sich über sowas Gedanken zu machen und ein bisschen mit Krypto rumzuspielen ist gut. Man lernt dadurch viel. Das ist aber nur was zum Spielen, nichts, was man in echten Projekten einsetzen sollte...
Zitat:
Wenn das Masterpasswort schon hartcodiert wäre, dann müßte wenigstens ein "komplizierter" Algorithmus dafür sorgen, dass die als Ausgangswerte verwendeten Daten nochmal ordentlich "verwurschtelt" werden bevor der daraus entstehende Key als Passwort für den eigentlichen "Passwort-Safe" verwendet wird.
Nein. Wenn das Passwort hartcodiert ist, nützt der beste Algo nichts. Das ist Augenwischerei.
Zitat:
Die Idee, die zu verschlüsselnden Daten künstlich zu verlängern kam mir auch schon. Mit langen Keys verschlüsselt wird das eine harte Nuss, selbst für hardwarebeschleunigte Passwortknacker. Allerdings wäre ich nicht auf die Idee gekommen, XOR zum Verschlüsseln zu verwenden.
xor an sich ist nicht schlecht. Das ist das Prinzip von Stromchiffren. Wie RC4 z.B. das Problem dabei nicht das xor, sondern der Keystream..
Zitat:
Eher was schickes aus dem
DEC.
Ja, siehe oben.
Zitat:
Vielleicht sogar 16 verschiedene Verschlüsselungsalgorithmen und das erste Byte des MD5-Hashes vom eigentlichen Masterpasswort entscheidet, welche davon verwendet wird.
Das hat zur Folge, dass die Sicherheit auf das Level des unsichersten dieser 16 Algos sinkt.
Zitat:
Die nächsten vier Bytes entscheiden, wie viele Runden verschlüsselt wird.
Das hat zur Folge, dass das Sicherheitsniveau vom zufall abhängig ist bzw. genau genommen auch wieder so ist, die bei einer Runde. Runden haben nicht den Zweck Veränderung zu schaffen. Sie sollen den Algo langsam machen. Deshalb muss die Anzahl der Runden -- so man so etwas einsetzt -- groß sein und fest.
Zitat:
Aber dieses ganze Prinzip kann man nur dann als halbwegs sicher ansehen, solange der Rechner auf dem die Anwendung läuft nicht kompromittiert ist. Andernfalls gibt es immer Möglichkeiten, die entschlüsselnde Anwendung zu belauschen. Dann bräuchte man die Daten nicht mal aufwendig knacken, man holt sich alles aus dem Speicher der laufenden Anwendung.
Deshalb solltest du dir Gedanken über Angriffsszenarien machen.
mfg
Christian