Ist meine Verschlüsselung unsicher

[Paukov]

Hi,
ich habe vor ein paar Tagen eine kleine Verschlüsselung fertiggestellt. Bei dieser wird zweimal ein 8-stelliges Passwort eingegeben. Danach wird der Text aufgeteilt und jedem Zeichen aus dem Text eine Zahl aus einer Datenbank zugeteilt. Diese Zahl wird anschließend mit dem ersten und dann mit zweiten Passwort multipliziert. So werden dann die neu entstandenen Zahlen aneinander gereiht. Wenn man den Text entschlüsseln will, benötigt man die zwei Passwörter. Wenn diese korrekt sind, werden die einzelnen Zahlen durch die Passwörter dividiert. Danach wird mit der entstandenen Zahl das zugehörige Zeichen gesucht. So wird der Text rekonstruiert. Jetzt meine Frage: Kann man anhand dieser Erklärung sagen, ob meine Verschlüsselung einigermaßen sicher ist oder nicht. Und wenn sie nicht sicher ist, bitte nicht zu hart mit mir ins Gericht gehen, ich bin weder Kryptologe noch irgendwie mit der Materie vertraut. Diese Verschlüsselung war mein erster Versuch.
LG
Paul

 

[Tumbleweed]

Kryptokram macht man nicht selbst. Das ist rocket science. Von daher ist die Antwort - "ja".

 

[Nilson]

Auch wenn die Zahlen größer sind ist das ganze nicht anders als jedem Buchstaben eine Zahl zuzuordnen

-> Zu jedem Buchstaben gehört eine Zahlenkombination. Man muss nur gucken welche häufig vorkommen (ist dann Leerzeichen, e, a etc.) und kann dann so den Text entschlüsseln.

Z.B. e -> fester Wert aus db * PW1 * PW2 = ist immer noch ein fester wert.

 

[Sweepi]

Zum Einstieg:

http://youtu.be/KxTh45_VhFk

Erster Selbsttest für eine Verschlüsselung ist, ob man den Output von einem Zufallszahlengenerator unterscheiden kann.
(Als nicht ein Mensch durch draufschauen , sondern z.B. durch eine statistische Auswertung.)

 

[pikostar]

Das ganze ist ja nur eine Abwandlung der http://de.wikipedia.org/wiki/Caesar-Verschlüsselung

Also relativ leicht zu knacken.

 

[Paukov]

Ich weiß, aber ich meine könnte man daraus dann schließen welcher Buchstabe das ist ?

 

[Nilson]

Nicht direkt, aber mit ein wenig Aufwand leicht zu knaken.

 

[Paukov]

Ok, danke ;

 

[alex_k]

Per brute Force geht alles. - Es ist letztlich immer eine Frage, wie kompliziert das Passwort (die Passwörter( ist bzw sind.

Ich halte ja auch große Stücke auf Truecrypt 7.1a. - Noch ist niht erwiesen, dass es ein Backdoor hat. - Wovon ich z.B. bei Bitlocker allerdings stark ausgehe....

 

[tnoay]

Ich weiß, aber ich meine könnte man daraus dann schließen welcher Buchstabe das ist ?

ach das meiste hier ist käse.

1) wenn du nicht sagst wie du verschlüsselst
2) wenn du das programm selbst absicherst, damit keiner den programmcode auslesen kann
3) wenn das programm nicht in expertenhand gerät, dann ist es 100% sicher

dann hilft hier nur das erraten des passwortes


wenn ein experte oft genug den passwortgenerator angeschmissen hat kommt er stück für stück dahinter wie es geht, solange keine einweg-funktionen dahinter stecken.

mach eine einweg-funktion rein und dein generator ist ziemlich ultra

 

[TenDance]

Kryptokram macht man nicht selbst. Das ist rocket science. Von daher ist die Antwort - "ja".

Naja, nicht ganz. Nur die im internet üblichen Verfahren. Wenn man mal kurz mit persönlich bekannten Menschen etwas austauscht, ist das one time pad recht simpel und dennoch nicht zu knacken.

 

[Lar337]

Die Verschlüsselung mittels der zwei Passwörter ist nicht sicherer, als dies nur mit einem zu machen.
Du verschlüsselst einfach nur mit dem Passwort PW1*PW2, sämtliche Angriffe zielen also einfach auf dieses PW, ohne jemals PW1 oder PW2 zu kennen.
-> Nicht wirklich sinnvoll, ein PW reicht.
(Die Passwörter aneinander zu reihen und so ein langes PW zu erzeugen hingegen wäre sinnvoll, allerdings könnte man dann auch gleich 1 Langes nehmen...)

@tnoay:
Man muss das Verschlüsselungsverfahren nicht kennen, um diese Verschlüsselung zu knacken.
Man muss nur nach Mustern in dem verschlüsselten Text suchen.
Klar, der Text muss ein hohes Vielfaches der Schlüssellänge betragen (sonst ist das Verfahren sicher - wie jedes One-Time-Pad), aber bei praktisch eingesetzten Verfahren ist das der Fall.
Und dann ist die Verschlüsselung mit einfacher Mustersuche zu knacken.

EDIT:
Übrigens eher peinlich den Beitrag mit "ach das meiste hier ist käse." zu starten, wenn man vom Thema offensichtlich nicht allzuviel versteht -.-

 

[tnoay]

EDIT:
Übrigens eher peinlich den Beitrag mit "ach das meiste hier ist käse." zu starten, wenn man vom Thema offensichtlich nicht allzuviel versteht -.-

könntest du lesen, dann hättst du dir deine belehrungen sparen können.

 

[Daaron]

Das Zeug IST aber zu knacken. Es ist am Ende nur eine Ersetzungschiffre. Du brauchst also nur zu wissen/vermuten, in welcher Sprache der Klartext verfasst ist und dann die Zeichenhäufigkeit anzuwenden.

Daher: Selbstbau-Crypto IST TOTALER SCHWACHSINN!
Wenn man was zu verschlüsseln hat, dann führt kein Weg an GUTEN Crypto-Algorithmen vorbei. Einen Elgamal kann man z.B. mit etwas Übung sogar selbst implementieren.
Wirklich sinnvoll ist aber der Einsatz von AES256. Das Ding ist State of the Art und so robust, dass es von der US-Regierung zur Verschlüsselung von Top Secret - Material zertifiziert ist. Und das Beste? OpenOffice/LibreOffice haben eine Implementierung von AES256 bereits drin. Nie war es leichter, Texte & Tabellen SICHER zu verschlüsseln.

 

[Lar337]

1.) Man muss das Passwort nicht erraten. Wenn nur erraten, also BruteForce helfen würde, dann wäre die verschlüsselung sicher.
Willst du das behaupten?

2.) Es ist zwar richtig, dass man theoretisch auch Teile des Schlüssels bei einem BruteForce Angriff auf diese Verschlüsselung verifizieren könnte, aber man braucht hier keinen Passwortgenerator, da diese Verschlüsselung eben nicht sicher ist.
Man muss sich nur den verschlüsselten Text angucken.

3.) Was hat eine Einwegfunktion mit dem Problem zu tun?

Ich weiß nicht, was ich anders lesen sollte.... Ich habe deinen Post ja vorher richtig durchgelesen und eben deswegen fand ich ja deinen Eingangssatz so belustigend.

 

[tnoay]

OpenOffice/LibreOffice haben eine Implementierung von AES256 bereits drin. Nie war es leichter, Texte & Tabellen SICHER zu verschlüsseln.

für programmierer gibts in java z.b.
http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html

 

[InteGralFormat]

Ich bin kein Kryptologe. Es hört sich aber nicht besonders überzeugend an.

Die Frage ist doch immer: Vor was soll es sicher sein?

Soweit ich weiß, setzen aktuelle Verschlüsselungsverfahren auf mathematische Verfahren, die eine gewisse Rechenkomplexität habenund diese mit einer hohen Anzahl an Kombinationsmöglichkeiten verbinden. Weiterhin noch zufällige Elemente.

Mein erster Gedanke ist: Zwei 8 stellige Passwörter haben erstmal die selben Kombinationsmöglichkeiten, wie ein 16 stelliges. 16 Stellen sind ok. Wobei du natürlich mit einer festen Passwortlänge einem Angreifer (der von der festen Länge weiß) es etwas einfacher machst, mit brute force anzugreifen, da er die ganzen anderen Kombinationsmöglichkeiten kürzerer Passwörter nicht mehr beachten muss. Ggf. kann es das auch einfacher machen, ein PW zu erraten. Bruteforce sollte bei der Anzahl an Kombinationen aber nicht sinnvoll möglich sein.

Jetzt wäre die Frage, wie deine Zuweisung in Form der DB gestaltet ist. Wenn du als Passwort Zahlen, Groß- und Kleinbuchstaben + Sonderzeichen zulässt, bekommst du in etwa eine Liste von vielleicht 10+26+26+30 = 82 Zeichen. Die DB muss eine eindeutige Zuordnung erlauben, um eine Rekonstruktion möglich zu machen. Da hier erstmal kein mathematisches Verfahren dahintersteckt, ist es nichts weiter, als eine Chiffrierung.

Meine Vermutung: Eine DB ist soweit ich weiß keine besonders gute Methode. Die DB muss ja auch irgendwie gesichert sein. Weiterhin bleibt ja die Menge der verwendeten Elemente eigentlich gleich. Damit machst du es also nicht stärker. Und nicht zu letzt muss (sollte) sicher gestellt sein, dass jede Zuweisung auch die selbe Länge hat. Für die Rekonstruktion wäre dies zwingend notwendig. Ansonsten kann das Programm ja nicht wissen, mit welchen Längen es rekonstrukieren muss. Es wäre schwach, wenn unterschiedliche Passwörter unterschiedlich lange Schlüssel generieren, da dies den Angriff deutlich leichter machen kann.

Der nächste Schritt: Multiplikation mit dem PW .. kann ich mir nichts drunter vorstellen? Eine Zahl mit einer Zeichenkette multiplzieren? Wie genau setzt du das um?

Aber auch hier bringt das mMn nicht viel. Das ist ja im Endeffekt nichts anderes, als eine weitere direkte Zuordnung. Und auch hier besteht das Problem mit der Länge.

Ich sehe besonders das Problem, dass du nicht sichergestellt hast, dass die erzeugte Verschlüsselung nur gleichlange und eindeutige Ergebnisse bringt. Und auch bei der Multiplikation muss sichergestellt werden, dass jedes PW einen anderen Faktor bringt, da das Verfahren sonst nicht eindeutig ist. Man müsste sozusagen belegen, dass nicht mehrere PW die selben Verschlüsselung zustande bringen.
Ohne dieses Wissen kann man wohl kaum beurteilen, ob es Schwachstellen gibt, die den Zugang erleichtern würden.


Jetzt wieder die Frage nach der Sicherheit: Vor was soll es sicher sein?
Sicherheit definiert sich, soweit ich weiß so, dass das Verfahren auch dann sicher ist, wenn der Angreifer das Verfahren kennt.
Sicherheit wird heute weniger geknackt, als anderweitig umgangen. Wenn es sich also um eine Hausaufgabe handelt, bei der ein bruteforce angriff abgewehrt werden soll, dann reicht eine Chiffrierung mit 16 Zeichen mMn locker, insofern man keinen professionellen Angreifer hat.
Wenn du damit deine Daten verschlüsseln willst - vergiss es

 

[Paukov]

Auf die Frage der Sicherheit: Es sollte vor Leuten die sich ein bisschen mit Programmierung auskennen einigermaßen sicher sein bzw. einen zu großen Aufwand darstellen um es zu entziffern.
Wegen Multiplikation des Passwortes mit einer Zeichenkette: Ich habe es vielleicht ein bisschen blöd geschrieben, das Passwort wird nicht mit einer Zeichenkette aus Buchstaben multipliziert, also:
Man hat einen Text mit dem Inhalt: "Ich mag Kuchen mit Speckstreifen". Dieser Text wird in seine einzelnen Teile aufgeteilt:
Teil 1: "I"
Teil 2: "c"
Teil 3: "h"
Teil 4: " " etc.
Dann wird der Inhalt jedes einzelnen Teils an die Datenbank gesendet, die sieht folgendermaßen aus:
Zeichen - ID
a - 111
b - 112
c - 113 etc.
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.
Alle Zahlen werden dann zu einem Text zusammengefasst und ausgegeben.
Wenn ich den Text jetzt mit dem Passwörtern 12345678 und 23456789 chiffriere, erhalte ich diesen Code:
249336958924738062-76162160507788746-249047368960830120-81953959785947586-250495318780369830-289589963907942-248757778996922178-81953959785947586-249916138852553946-252522448527725424-76162160507788746-249047368960830120-242386799790947454-250784908744277772-81953959785947586-250495318780369830-249336958924738062-252232858563817482-81953959785947586-251943268599909540-251074498708185714-242386799790947454-76162160507788746-249916138852553946-251943268599909540-252232858563817482-251653678636001598-242386799790947454-249336958924738062-248468189033014236-242386799790947454-250784908744277772-
Die ID's für die Zeichen sind in meiner Datenbank anders, als oben beschrieben.

Achja, und Hausaufgaben chiffrieren triffts ganz gut, ich wollte die Verschlüsselung für meine Klassenwebseite als kleine Spielerei einbauen .
P.S. Danke für deinen langen Text und die ganzen Tipps, ich hätte nicht gedacht dass sich so viele Leute wirklich meine Verschlüsselung vorstellen, sie analysieren und mir Schwachpunkte aufzählen .
EDIT: Natürlich ist es kein festgelegtes Passwort im Programm, es wird jedes mal selbst vom Benutzer ausgewählt, falls es da Missverständnisse gab .

 

[tnoay]

@Nilson
ja, hast recht

bei einem entsprechend langem text kann auch ein archäologe entschlüsseln

 

[Nilson]

Nunja, wenn ich "h" schreibe weißt du ka auch nicht ob das ein "h" oder ein Verschlüsseltes "B" ist. Je länger der Text desto einfach wird es mit deiner Methode Zahlenkombinationen Zeichen zuzuordnen (jeder Buchstabe hat einen festen Code). Das ist kein Programieraufwand, dafür braucht nur Kenntnisse in der (Deutschen) Sprache und einen genügen Langen Text oder eine Anzahl an Texten.