Ist meine Verschlüsselung unsicher

[Lar337]

sicherlich wahnsinnig schwer zu erraten, der code darf aber natürlichlich nicht verraten werden.

Du bist schon ziemlich resistent gegen Belehrungen, oder?
Wie oft sollen wir denn noch schreiben, dass das Falsch ist.
Es ist falsch, völliger Unsinn, nichr richrig, Quatsch, ... oder was einem sonst noch dazu einfällt.
Es wird auch nicht richtiger, wenn du es noch öfter behauptest!

Es ist völlig egal, ob der Code bekannt ist. Ebenso ist das Verfahren unnötig kompliziert.
Sowohl die Datenbank als auch das zweite Passwort erhöhen die Sicherheit NICHT.

Sämtliche Angriffe, ob Verfahrensbezogen oder Bruteforce, zielen auf das Endpasswort ab.
Also db*PW1*PW2. Und dass dieses mittels 3 verschiedener Quellen erzeugt ist, ändert dabei garnichts. Das kann man komplett weglassen. Ändert genau garnichts.

Übrigens, durch die Trennung mittels Bindestrichen machst du es dem Angreifer nochmals deutlich einfacher.

Ein simples Cäsarchiffre ist genauso sicher/unsicher wie dieses Verfahren, Im Prinzip ist dieses hier ja ein simples Cäsarchiffre, nur dass hier mit dem Passwort noch ein paar lustige Berechnungen durchgeführt werden, die allerdings völlig nutzlos sind.

Du kannst dem Angreifer das zweite Passwort sowie den Inhalt der Datenbank geben. Es bringt ihm nichts, da sie für die Sicherheit irrelevant sind.

EDIT: Das Verfahren entspricht sogar einem Cäsarchiffre mit der Schlüssellänge 1(!).
Da das gesamte PW auf einmal verwendet wird, braucht man garnicht erst groß auf ein Ende der Schlüssellänge warten, was bei einem Cäsarchiffre eigentlich das größte Problem darstellt.
Man kann direkt mit der statistischen Analyse beginnen.
Man braucht zwar einen Text dessen Länge ein vielfaches der Schlüssellänge beträgt, allerdings ist die Schlüssellänge hier EINS.
Daher muss der Text garnicht mal so super lang sein.
Dieser Fehler bei der Implementierung wird auch nur sehr geringfügig durch die Nutzung der Datenbank ausgebessert.
(Andernfalls müsste man nur den häufigsten Buchstaben finden und hätte direkt den Schlüssel, hier wird der Schlüssel zumindest noch durch die DB verdeckt)

(Klar, für BruteForce ist er nicht eins, aber für die statistische Auswertung ist er "quasi eins" )

 

[Green Mamba]

Wenn du in diesem Stil eine (!) aktuell verwendete normale Verschlüsselungs-Algorithmik beschreiben willst, wirst du auf den Umfang eines ganzen Buchs kommen, welches du auch wahrscheinlich nach dem 3. mal durchlesen nicht durchblicken wirst. Das nur mal zum Vergleich der Komplexität.
Das was du da machst ist für eine Spass-Verschlüsselung sicher gut geeignet, Daten schützt du damit nicht wirklich. So etwas entwickelt man nicht mal eben nebenbei. Nicht umsonst tragen viele Verschlüsselungs-Verfahren den Namen ihrer Erfinder.
Ich kann dir nur dazu raten, dich auch mal in echte sichere Verschlüsselungs-Technologien einzulesen. Da bekommst du schnell eine Idee davon was notwendig ist um eine Verschlüsselung wirklich "Bulletproof" zu bekommen.

 

[Lar337]

Allerdings könnte man dieses Verfahren hier zumindest noch vereinfachen und von Fehlern bereinigen.
Dann hätte man ein normales Cäsar-Chiffre.
Dieses hier ist jedoch ein fehlerhaft implementiertes Cäsarchiffre, weshalb es sogar deutlich unsicherer ist, als ein richtiges Cäsarchiffre.

 

[Daaron]

c = 113 * Passwort 1 * Passwort 2

Und wo ist jetzt der Unterschied zu c= 113 * PAsswort3, wobei Passwort3=PW1*PW2? Wozu 2 Passwörter? Dein Verfahren wird dadurch um GAR NICHTS komplexer, besser oder auch nur akzeptabel.

Danach wird ein Bindestrich eingefügt (-) und das nächste Zeichen wird an die Datenbank gesendet.

Du machst es einen Angreifer also sogar noch so einfach, dass er weiß, welche Zahl für ein einzelnes Zeichen steht? Sehr nobel von dir, das machts leicht...
Da PW1*PW2 = PW3, und weder PW1 noch PW2 irgend eine Relevanz haben, müsste man nur eine Primfaktorzerlegung auf n paar deiner Zahlen anwenden, schon hätte man PW3.... aber nicht einmal das muss man tun.

Wer deine Verschlüsselung angreifen will zählt einfach, welche Zahl (-> Zeichen) am häufigsten im Text vorkommt. Jetzt überlegt er, dass der Text wohl in Deutsch sein wird. Im Deutschen dürfte das "e" der mit Abstand häufigste Buchstabe sein, im Endeffekt muss der Angreifer nur anhand der Häufigkeit das gute alte Glücksrad-ERNSTL zuordnen. Der Rest ist Lückenfüllen.

Achja, und Hausaufgaben chiffrieren triffts ganz gut, ich wollte die Verschlüsselung für meine Klassenwebseite als kleine Spielerei einbauen .

Das ist keine Verschlüsselung, das ist Malen nach Zahlen. So ein Code ist vielleicht vor primitiven Wilden sicher, aber jeder, der mal Edgar Allen Poe gelesen hat, wird die Chiffre in ner Stunde oder so knacken.

Wenn du verschlüsseln willst, dann implementiere Elgamal, das Ding ist gut dokumentiert. Setz dich auf den Arsch und arbeite die Wikipedia-Seite dazu durch. Musst ja keinen 128Bit-Schlüssel verwenden, ein kleiner 16Bit-Schlüssel machts deinem Gegenüber schon unmöglich, ohne technische Hilfsmittel an die Lösung zu kommen.

 

[InteGralFormat]

Dann wird die zu dem Buchstaben zugehörige ID gespeichert und mit Passwort 1 und Passwort 2 multipliziert, also:
c = 113 * Passwort 1 * Passwort 2
Danach wird ein Bindestrich eingefügt (-) und das nächste Zeichen wird an die Datenbank gesendet

Wenn ich das richtig sehe, würde es das noch einfacher machen. Du brauchst nur einen Programmcode schreiben, der für jeden erzeugten Code eine ganze Zahl sucht, die ein sinnvolles Ergebnis bringen. Hier käme also letztendlich ausschließlich nur die Chiffrierung zum Tragen.
Da deine Chiffriertabelle aus immer gleichlangen und vor allem geordneten Zahlenverkettungen besteht, wäre es sogar sehr einfach, diese als sinnvoll zu identifizieren. In dem Sinne - eine Chiffriertabelle sollte nicht geordnet sein bzw. keine Folgerungen auf Folge oder Vorgängerglieder erlauben.

Wie schon geschrieben wurde - die Binderstriche sind äußerst schwach. Sie lassen eine Vielzahl an Schlüssen etc. zu.

Vom Prinzip könntest du die Bindestriche weglassen, PW1 auf 16 Zeichen setzen, müsstest sicherstellen, dass für jedes eingegebene Zeichen immer die selbe kodierte Zeichenlänge herauskommt und könntest dann z.B. eine (funktionelle) Schiebung einführen, die durch PW2 bestimmt wird. Dann macht der zweite Schlüssel auch mehr Sinn. Schlüssel 1 wäre dann das PW und Schlüssel zwei beeinflusst das Verschlüsselungsverfahren.

Dazu aber noch ein Gedanke: Sowas bedeutet erstens mehr Rechenaufwand (dadurch wird auch die Qualität der Programmierung wichtiger), du musst sicherstellen, dass das Verfahren eindeutig und damit reversibel bleibt und kann bei langen Datensätzen auch eine Menge Schreibarbeit für die "Register" (Festplatte bzw. RAM) bedeuten.
Ich behaupte jetzt einfach mal, dass bei solchen "einfachen" Verfahren die Änderung der PW-Länge um zwei Zeichen eine verhältnismäßig unendlich höhere Sicherheit bietet, als das Verfahren unnötig (schwach) zu verkomplizieren.

Wie auch schon geschrieben wurde: Statistische Analysen werden so ein Verfahren mitunter knacken können. Mit einer nicht-linearen Schiebung wäre das wahrscheinlich verhinderbar. Ein Beispiel wäre z.B.:

Deine erzeugten Codeblöcke müssen immer 8 Zeichen lang sein. Davon beeinflusst PW2 immer 8 Blöcke (ich nenne das jetzt einfach mal einen BLOCK). Insgesamt umfasst ein BLOCK also 8*8=64 Zeichen.
PW2 muss irgendwie so gewählt oder erzeugt werden, dass es einen Wert zwischen 0 und 64 ergibt. An der Position des Wertes trennst du den Block in eine linke und rechte Hälfte und vertauschst beide.
Dann könntest du mit steigender BLOCKZAHL z.B. die Anzahl dieser Vertauschungen erhöhen. Damit wären für die Verschlüsselung 5 im idealfall unbekannte Faktoren wichtig: Das PW1, PW2, die DB, die BLOCK-Größe und die Anzahl der BLOCKs.

Wenn jetzt deine ersten beiden BLOCKs so aussehen(die Trennzeichen sind hier nur optische HIlfsmittel):

11111111-22222222-33333333-44444444-55555555-66666666-77777777-88888888
44444444-55555555-66666666-77777777-88888888-99999999-00000000-11111111

Und du lässt den Wert des PW2 zu 13 berechnen, würde das geschoben dann so aussehen:

22233333-33344444-44455555-55566666-66677777-77788888-88811111-11122222 (eine Runde, da der erste BLOCK)
77777788-88888899-99999900-00000011-11111144-44444455-55555566-66666677 (zwei Runden, da zweiter BLOCK)

Hoffe, ich hab hier keinen Fehler gemacht Werte nur als Beispiel gewählt.
Es sollte klar sein, dass hier der Rechenaufwand ein exponentielles Wachstum hat und man daher zwingend irgendwo begrenzen muss. Der Verschiebemechanismus ist mMn ebenfalls recht einfach.

Ich hab jetzt nicht sonderlich drüber nachgedacht, wie man dieses Prinzip hier aushebeln kann bzw. mit welchem Aufwand. Würde mich hier auch über Kommentare freuen.

ich hätte nicht gedacht dass sich so viele Leute wirklich meine Verschlüsselung vorstellen, sie analysieren und mir Schwachpunkte aufzählen

He he - ich sag's mal so (und das meine ich wirklich nicht abwertend): Wäre sie nicht so einfach, dann würde es auch niemand verstehen und es gäbe wahrscheinlich nur die Antwort, dass das hier das falsche Forum dafür ist

Nicht umsonst ist die Entwicklung, die Sicherheitsbeweisführung aber auch die Angreifbarkeitsanalyse meist eine Problemstellung an Mathematiker. Das ist nichts, was man als Laie mal so nebenbei macht und versteht.

Kannst dich ja mal einlesen, wie z.B. RSA funktioniert.

 

[Paukov]

He he - ich sag's mal so (und das meine ich wirklich nicht abwertend): Wäre sie nicht so einfach, dann würde es auch niemand verstehen und es gäbe wahrscheinlich nur die Antwort, dass das hier das falsche Forum dafür ist

Nicht umsonst ist die Entwicklung, die Sicherheitsbeweisführung aber auch die Angreifbarkeitsanalyse meist eine Problemstellung an Mathematiker. Das ist nichts, was man als Laie mal so nebenbei macht und versteht.

Ich habe auch nicht gemeint dass meine Verschlüsselung so schwer vorzustellen ist, ich habe eher gemeint dass es mich freut, dass sich Leute wirklich die Mühe machen sich mit meinem Post zu beschäftigen und nicht gleich Kommentare ablassen wie: "Ich brauch mir das nicht einmal durchzulesen, da ich mir sicher bin dass es sowieso nicht funktioniert". Und nochmal danke für den langen Text und die Verbesserungsvorschläge, ich hoffe dass, falls ich noch einmal eine Verschlüsselung hier poste, wieder so viele Leute alles auseinanderpflücken und sagen wo sich überall Schwachstellen befinden (Obwohl, mein jetziges System ist eine einzige Schwachstelle ).

 

[Daaron]

Na ja, du kannst 1001 Algorithmus entwerfen, wenn du keine wirklich fundierten Kenntnisse in höherer Algebra hast, dann bringt dir das gar nichts. Du kannst nicht einmal im Traum sicherstellen, dass auch wirklich für jede Kombination aus Schlüssel & Geheimtext der richtige Klartext heraus kommt und natürlich, dass auch wirklich nru ein Schlüssel funktioniert.

 

[Paukov]

Das ist mir sowieso klar, aber ich komm ein bisschen mit meinen Programmierkenntnissen weiter und es ist sicher nicht falsch sich ein bisschen weiterzubilden .

 

[Daaron]

Allgemein schon, aber bei allem was Crypto angeht gilt: Finger weg, wenn du kein wirklich gutes Mathe-Diplom in der Tasche hast. So als Doktorand kannst du dann langsam darüber nachdenken, eine sinnvolle Verschlüsselung zu entwerfen.

 

[InteGralFormat]

Das ist mir sowieso klar, aber ich komm ein bisschen mit meinen Programmierkenntnissen weiter und es ist sicher nicht falsch sich ein bisschen weiterzubilden .

Genau. Sich selber Problemstellungen suchen und lösen ist immer gut.

 

[Daaron]

Da gibt es aber praktischere Problemstellung als ein Crypto-System zu schreiben. Da könnte man sich viel eher eine praktische Anwendung für den Dijkstra-Algorithmus suchen, damit kann man viel Spaß haben.

 

[InteGralFormat]

Oder mit der Suche nach dem Weltfrieden ... oder malen nach Zahlen. ..

Der TE kann sich seine Probleme doch selber suchen. Und wenn er dran scheitert oder Erfolg hat, dann ist's nicht dein Problem.

 

[tnoay]

wie gesagt, es gibt bibliotheken für programmierer, daran sollte man sich orientieren.

 

[Lar337]

Na ja, du kannst 1001 Algorithmus entwerfen, wenn du keine wirklich fundierten Kenntnisse in höherer Algebra hast, dann bringt dir das gar nichts. Du kannst nicht einmal im Traum sicherstellen, dass auch wirklich für jede Kombination aus Schlüssel & Geheimtext der richtige Klartext heraus kommt und natürlich, dass auch wirklich nru ein Schlüssel funktioniert.

Wieso? In diesem Fall kommt offensichtlich immer das richtige raus.
Und dass nur ein Schlüssel funktioniert ist keine zwingende Voraussetzung.

 

[Daaron]

Wieso? In diesem Fall kommt offensichtlich immer das richtige raus.

Ja, weil die Chiffrierung trivial genug ist.

Und dass nur ein Schlüssel funktioniert ist keine zwingende Voraussetzung.

Aber ne gute Idee... oder sagen wirs anders: Es sollte ne ganze Weile dauern, bis man eine Kollision findet.