Neue (?) Verschlüsselung.... Wie sicher ist sie?

[glkgereon]

Hi,

Nach der Lektüre von "Digital Fortress" (Diabolus) Habe ich mich längere Zeit gefragt, was mit einer "rotating cleartext function" gemeint sein könnte (sofern sie existiert). (Ob Dan Brown selbst eine Idee hat wie soetwas gehen könnte?)
Nach einiger Überlegung stieß ich auf eine (mir völlig neue) Idee der Verschlüsselung.
Hierbei generiere ich zunächst eine (peudo-)zufällige Index-Datei zu einer Wortliste.
Dann ersetze ich nach dem in der Index-Datei angegebenen Schema alle Wörter im Ausgangstext (und beim dekodieren wieder zurück).
"Passphrase" ist bisher lediglich die Index-Datei sowie die Wortliste. Ob es sich lohnt (und wie es gehen würde) einen zusätzlichen Passphrase im üblichen Sinne einzubauen, weiss ich (noch?) nicht.

Naja, genug der Theorie, hier etwas Code:

Delphi-Quellcode:

  TForwarding = packed record
    x: Int64;
    y: Int64;
  end;
  TForwardings = array of TForwarding;
  THeader = packed record
    FileSize: Int64;
    Datas: Int64;
  end;
  TEntry = record
    PointSucc: Boolean;
    PointPrec: Boolean;
    Succ: Int64;
    Prec: Int64;
    Index: Int64;
  end;
  TEntries = array of TEntry;

TForwardings ist der eigentliche Inhalt der Index-Datei. Der Index im Array entspricht dem Index in der Wortliste, X ist der Vorgänger und Y der Nachfolger.
TEntries ist ein Array zum Internen Generieren der Forwardings.
THeader wird vorne in die Datei geschrieben. Hat zwar noch keine wichtige Funktion, aber es ist ganz praktisch im vornherein zu wissen wie viele Forwardings man denn nu hat^^

Die Wortliste verwalte ich ganz einfach in einer TStringList.

Das ganze habe ich in eine Klasse geknallt...
CallPrg, CallInitPrg und CallStatus sind Events der Klasse um den Fortschritt und Status-Texte auszugeben...

Nun zum Generieren des Indexes:

Delphi-Quellcode:

procedure TWordEncryption.GenerateIndex;
var FS: TFileStream;
    Head: THeader;
    FW: TForwarding;
    i: Integer;
    E: TEntries;
    S: Int64;
begin
  CallPrg(0,aGenerate);
  CallInitPrg((WL.Count-1) div 1000,aGenerate);

  CallStatus('Übertrage Wortliste...',aGenerate);
  SetLength(E,WL.Count);
  for i:=0 to WL.Count-1 do
    begin //Erstmal alles reinkopieren
    E[i].PointSucc:=False;
    E[i].PointPrec:=False;
    E[i].Index:=i;
    E[i].Succ:=0;
    E[i].Prec:=0;
    end; 
  CallStatus('Generiere Index-Datei...',aGenerate);
  for i:=0 to Length(E)-1 do
    begin //Nochmal alles durchlaufen
    if (i mod 1000 = 0) then
      begin
      CallPrg(i,aGenerate);
      end;
    S:=Random(Length(E)); //Und zufällig ein Element suchen was noch keinen Vorgänger hat.
    while (E[S].PointPrec) do S:=Random(Length(E));
    E[i].PointSucc:=True; //Wenn man dann eins hat die "Zeiger" (=Indexe) richtig setzen
    E[S].PointPrec:=True; //Und die Status-Bools setzen
    E[S].Prec:=E[i].Index;
    E[i].Succ:=E[S].Index;
    end;

  FS:=TFileStream.Create(FIndexFile,fmShareExclusive or fmOpenWrite);
  Head.FileSize:=Length(WL.Text); //Dann bastlen wir uns noch schnell nen Header
  Head.Datas:=WL.Count;
  FS.Size:=0;
  FS.Position:=0;
  FS.Write(Head,SizeOf(THeader));

  CallStatus('Speichere Index-Datei...',aGenerate);

  for i:=0 to Length(E)-1 do
    begin //...und schreiben alles in die Datei
    FW.x:=E[i].Prec;
    FW.y:=E[i].Succ;
    FS.Write(FW,SizeOf(TForwarding));
    end;

  FS.Free;

  CallStatus('Bereit.',aGenerate);
  CallPrg(0,aGenerate); //Fertig
end;

Nun hat man eine Index-Datei...Soweit so gut.

Nun kommt es zum Kodieren bzw zum Dekodieren.

Delphi-Quellcode:

  TStringDynArray = array of String;
  TCodeDirection = (cdEncode,cdDecode);


function TWordEncryption.CodeIt(Src, Passphrase: String; T: TCodeDirection): String;
/* 
  Src wird (De-)Kodiert
  Passphrase ist zZ noch ohne Funktion
  T ist die Richtung (cdEncode oder cdDecode)
*/
var i,j,k: Integer;
    F: TForwardings;
    Head: THeader;
    FS: TFileStream;
    D: TStringDynArray;
begin
  CallPrg(0,aCode);
  Result:='';
  CallStatus('Lade Index-Datei...',aCode);
  FS:=TFileStream.Create(FIndexFile,fmShareExclusive or fmOpenRead);
  FS.Read(Head,SizeOf(THeader)); //Erstmal wieder auspacken
  SetLength(F,Head.Datas);
  for i:=0 to Head.Datas-1 do
    FS.Read(F[i],SizeOf(TForwarding));
  FS.Free; //Nu ist alles in F drin

  CallStatus('Kodiere Text...',aCode);
  D:=Explode(' ',Src); //In die Einzel-Wörter Splitten
  for i:=0 to Length(D)-1 do
    begin
    CallPrg(i,aCode);
    j:=WL.IndexOf(D[i]); //Den Index des Wortes holen
    if (j<0) or (j>=WL.Count) then
      Result:=Result+D[i]+' ' //Wenn Wort nicht in der Wortliste ist, dann schreiben wirs einfach wieder so rein
    else if T=cdEncode then
      begin //Kodieren
      for k:=1 to i do
        j:=F[j].y; //Wir nehmen und ein i-mal den Nachfolger
      Result:=Result+WL[F[j].y]+' ';
      end
    else if T=cdDecode then
      begin //Dekodieren
      for k:=1 to i do
        j:=F[j].x; //Wir nehmen und ein i-mal den Vorgänger
      Result:=Result+WL[F[j].x]+' '; 
      end;
    end;
  CallPrg(0,aCode); //Fertig.
  CallStatus('Bereit.',aCode);
end

Ja und das war es eigentlich auch schon :-)

Nun meine Frage:
Wie sicher ist so eine "Verschlüsselung"?
Durch herkömmliche Brute-Force Attacken ist sie ja nun kaum zu verwunden, da sie beim richtigen Text keine signifikanten unterschiede zu einer falschen version aufweist. (Es ist immer, mehr oder weniger, sinnvoller Text. Daher bräuchte es wirklich eine Brute-Force welche auf Satzzusammenhang prüft....).

Ich hänge mal
a) die Unit + Beispielprogramm und
b) eine Wortliste an

damit habe ich einen Text verschlüsselt.
Dier Kodierte Fassung ist:
"Fadensonde Disziplinargericht Duschnik Puppenwagen . zugemacht Schaufensterwettbewerb Schriftart umsatzlos !"

kann es wer entschlüsseln?

[Ratte]

a) deine Schlüsseldatei ist relativ groß
b) muss sie auf den Text angepasst sein --> wenn bestimmte Worte beim erstellen des Schlüssels nicht vorgesehen waren, hast du pech gehabt.
c) funktioniert nur bei Texten
d) insbesondere wenn man mehrere Nachrichten hat ann man mit Satzbau evt. einiges erschließen.
e) Wörter mit Satzzeichen dahinter werden nicht verschlüsselt (Satzzeichen sind allgemein ein Risiko bei deinem Verfahren, erlauben Rückschlüsse auf den Satzbau)
f) Die Tatsache dass du Wörter aus der Wortliste mit Wörtern aus der Wortliste verschlüsselst, lässt Rückschlüsse auf die Wortliste zu --> Angreifpunkt
Nette Spielerei. Zur Sicherheit kann ich nicht viel sagen, dürfte aber mit vertretbarem Aufwand zu knacken sein. Allgemein sind mir AES, RSA und Konsorten sympathischer.
mfg,

Ratte

P.S. mal sehen was Cryptomeister negaH dazu sagt, ich hoffe ich hab nix elemtares bei meiner Kurzanalyse übersehen.

[glkgereon]

In der Tat, die Satzzeichen sind (bisher) echt ein Manko...
Allerdings könnte man vielleicht die kodierung der Satzzeichen mit einer Kodierung von Zahlen koppeln (aber da hab ich bisher noch kein brauchbares Ergebnis...)

Die Große Schlüsseldatei ist imho kein Sooo großes Problem, da sie zum einen (wenn man das mal auf Integer reduziert, was völlig ausreicht) nur noch halb so groß ist und sich ziemlich komprimieren lassen sollte (hoffe ich zumindest).

In der Tat funktioniert das ganze nur bei Texten. Das ist klar.

Mit dem Erschließen nach dem Satzbau ist so eine sache...
Angenommen du hast eine Wortliste mit mehreren hunderttausend wörtern, wie meine sie hat.
Dann geht das Index erstellen sowie ver und entschlüsseln noch sehr schnell.
Gleichzeitig ist die möglichkeit der kombinationen aber schon SO groß, das ein prüfen per hand völlig sinnlos ist.
also würde es eventuell reichen, Wörter durch gleichartige (nomen durch nomen, verben durch verben zB) zu ersetzen, und damit einen korrekte Grammatik zu erhalten.
In wie weit diese erstzungen die stärke der verschlüsselung beeinflussen weiss ich nicht...

[Meflin]

Zitat:

Zitat von glkgereon

Nach der Lektüre von "Digital Fortress" (Diabolus) Habe ich mich längere Zeit gefragt, was mit einer "rotating cleartext function" gemeint sein könnte (sofern sie existiert).

Manche Leute merkens leider wirklich nicht, aber Dan Brown schreibt nicht wissenschaftlich korrekt. (Das artet dann manchmal in derart sinnlosen Diskussionen aus dass es nicht fierlich ist.) Löblicherweise bezweifelst du immerhin deren Existenz ;)

Rotating Irgendwasauchimmer fällt definitiv unter die künstlerische Freiheit, die ein Romanautor eben hat, aber so etwas gibt es definitiv nicht! Ich erinnere mich nicht mehr genau wie er es meint dass es funktionieren soll, aber ich meine mich zu erinnern dass das nichtmal theoretisch funktionieren würde :mrgreen:

[glkgereon]

Zitat:

Zitat von Meflin

Zitat:

Zitat von glkgereon

Nach der Lektüre von "Digital Fortress" (Diabolus) Habe ich mich längere Zeit gefragt, was mit einer "rotating cleartext function" gemeint sein könnte (sofern sie existiert).

Manche Leute merkens leider wirklich nicht, aber Dan Brown schreibt nicht wissenschaftlich korrekt. (Das artet dann manchmal in derart sinnlosen Diskussionen aus dass es nicht fierlich ist.) Löblicherweise bezweifelst du immerhin deren Existenz ;)

Rotating Irgendwasauchimmer fällt definitiv unter die künstlerische Freiheit, die ein Romanautor eben hat, aber so etwas gibt es definitiv nicht! Ich erinnere mich nicht mehr genau wie er es meint dass es funktionieren soll, aber ich meine mich zu erinnern dass das nichtmal theoretisch funktionieren würde :mrgreen:

Ich sagte ja, ich habe mich auch gefragt was er damit meint^^
Und so wie ich es verstanden hab heisst das nur das am ende wieder (theoretisch) lesbarer Text rauskommt...was ja geht :-)
Aber dass das was er da schreibt nicht 100%ig korrekt ist ist klar^^

[Dax]

Ich hab mir deinen Code nicht sooo genau angekuckt (;)), aber der Erklärung nach ist das nicht weiter als ein Substitutionsalgorithmus. Du ersetzt einfach ein Wort durch ein anderes. Das ist wie Cäsar-Verschlüsselung, nur statt pro Buchstabe findet die Ersetzung pro Wort statt. Es ist um einiges schwieriger, dieses Ding zu knacken, aber mit genügend Ausgangsdaten wird das ohne Zweifel viel einfacher. Von AES und Konsorten kann man das (finde ich) nicht behaupten.

[negaH]

Keine Ahnung was Dan Brown damit gemeint hat aber wir können mal einen Vergleich der Komplexität (und darum gehts bei der Kryptographie immer!) zwischen deinem Verfahren und einem anerkannten Verfahren wie AES machen.


AES arbeitet mit 128 Bit Schlüsseln und ist ein 128 Bit Blockcipher. Interessant für uns sind die 128 Bit Blockgröße. Das bedeutet das es exakt 2^128 verschiedene Datenblöcke als Inputs geben kann die dann auf exakt 2^128 andere Output Blöcke transformiert werden. Ohne den Passwordstream ist diese Transformation nicht umkehrbar.

Angenommen du benutzt eine Indexdatei die 4 Gb groß ist. Pro Index verbrauchen wir 4 Bytes macht also 1 Milliarde unterschiedlicher Transpositionen beim Mapping von einem Wort zu einem anderen Wort. Wir können also mit max. 1 Million unterschiedlicher Worten arbeiten. Das dürfte damit ca. 4 mal mehr sein als es zb. deutsche Worte gibt (ca. 250000).

Im vergleich heist dies

AES 2^128 mögliche Transpositionen
Dein Verfahren ca. 250.000 mögliche Transpositionen.

Die Komplexität eines guten Verfahrens (nur einfach berechnet OHNE dabei auch die Art&Weise der mathematischen Operation dieser Transpositon zu berücksichtigen !!) ist demnach x := 2^128 / 250.000 mal größer und X als Zahl ausgeschrieben ist

2^128 = 340282366920938463463374607431768211456
250000 ~ 2^19

2^128 / 250000 = 1361129467683753853853498429727072

x := 1361129467683753853853498429727072

Also 1361129467683753853853498429727072 mal ist ein normaler Cipher heute stärker als deine Methode.


Nimmt man also deine Textdatei die verschlüselt werden soll, so kannst du mit deinem Verfahren nur soviele Wörter umkodieren wie es in unserem Sprachschatz tatsächlich gibt. Würde man die gleiche Datei mit AES verschlüsseln so würde es zu jedem möglichen deutschen Wort ca. 1361129467683753853853498429727072 verschiedene Kombinationen geben, statt nur eine 1 zu 1 Transposition.
Damit ist der Symbol-Raum der binären Verschlüsseung mit AES nicht nur weit weit stärker sondern hat noch den Vorteil das es zu keinerlei Veränderung der Dateigröße gibt. In deinem Falle könnte ja ein Wort wie UND in ein Wort wie HAUSFRAU gemappt weden, ergo eine Änderung in der Datengröße. Das gibts bei AES nicht, trotz weit besserer Komplexität, und dies ist ein großer technischer Vorteil vom AES im praktischen Betrieb.

[edit]
Soweit zur Komplexität und meiner Kritik an deinem Verfahren. Nun noch einige Verbersserungsvorschläge die dein Verfahren mehr Sinn verleihen.

Also deine Index-Datei bleibt erhalten und mappt ein Wort zu einem Index der zb. 24 Bit pro Eintrag groß ist. Das wären also 3 Bytes pro Wort. Nun hats du noch eine Wortdatenbank, natürlich effizient sortiert und durchsuchbar. Beim Verschlüsseln wird deine Testdatei geladen und Wortweise zerlegt. Jedes Wort wird in deiner Wortdatenbank gesucht und dessen Index als Zahl ermittelt. Dieser Index dient als Index zum Zugriff auf deine Indexdatei, eher eine SBox-Datei. Du nimmst nun den darin hinterlegten 24 Bit Zahlenwert und speicherst diesen in unsere verschlüsselte Output-datei.

Du hast also eine Textdatei so umkodiert das sie pro Wort nur 3 Bytes benötigt im Output. Du müsstest damit also eine Komprimierung erhalten. Defakto kannst du je nach Wahrscheinlichkeiten der Worte im Text die Größe der Kodierungsbytes dynamisch anpassen, so wie bei der Huffman Komprimierung. Sehr häufige Wörter werden also mit kurzen Codes kodiert und seltene Wörter mit langen Codes. Damit bekommst du eine Komprimierungsrate hin die höher ist als jede ZIP Komprimierung und denoch keine verlustbehaftete Komprimierung ist.

So, fehlt noch unser Passwort. Ohne Passwort funktioniert das Verfahreen wie eben beschrieben, es mappt nur die Wörter in IDs basierend auf unsere Index-Datei. Mit Passwort würde der Index unseres Wortes in der Wortdatenbank erstmal mit einem Passwortstream umkodiert und dann erst als Index in unsere ID-Index-Datei benutzt. Oder besser noch wird man nachdem man unsere ID zum Wort ermittelt wurde diese ID mit dem Passwortstrom umkodiert. Dh. selbst mit bekannter Wortdatenbank und ID-Index-Datei benötigt man noch das Passwort um die verschl. Datei zu entschlüsseln und zu dekomprimieren.

[/edit]

Gruß Hagen

[glkgereon]

Zitat:

Zitat von negaH

Pro Index verbrauchen wir 4 Bytes macht also 1 Milliarde unterschiedlicher Transpositionen beim Mapping von einem Wort zu einem anderen Wort. Wir können also mit max. 1 Million unterschiedlicher Worten arbeiten.

Den teil versteh ich irgendwie nicht so ganz :gruebel:

wieso dividierst du da auf einmal durch 1000?
zudem ist die substitution ja auch noch von der position im Text abhängig (ergo eigentlich noch mal länge des textes... oder?)

[negaH]

Die Länge des Textes ist erstmal irrelevant. Wir analysieren einfach nur die Komplexität beim Mappen eines Wortes in einen anderen Code. Dieser Prozess ist vergleichbar mit dem Mappen eines Datenblockes zu einem anderen Datenblock bei einer Blockverschlüsselung. Wenn wird davon ausgehen das es nur 250000 deutsche Wörter gibt so ist die Komplexität dieser Operation exakt 250000 zu 250000 andere Wörter. Bei AES sind es 340282366920938463463374607431768211456 zu 340282366920938463463374607431768211456 anderen Datenblöcken.

Klar, wir müssten theoretisch sogar noch berücksichtigen das ein Datenblock bei AES ja aus 16 Bytes besteht und ein durchschnittliches deutsches Wort wohl weniger als 128 * 3.6/8 = 58 Zeichen ! Defakto würde eine korrekte Anpassung sogar noch die Komplexität des Verfahrens im Vergleich zu AES noch weiter reduzieren. (3.6 = Entropie der Buchstaben unseres deutschen/englischen Alphabethes in das 256 Symbole umfassende ASCII Charset, die binäre Codierung im AES ist also wesentlich weniger redundant als normale Wörter basierend aus Textzeichen).

Gruß Hagen

[glkgereon]

meiner ansicht nach hinkt der vergleich.

der knackpunkt ist imho gar nicht, wieviele möglichkeiten es gibt das ganze zu dekodieren, sondern die fehlende möglichkeit den korrekt dekodierten Text als solchen zu erkennen.

Was hilft dir die bewiesene unsicherheit eines Verfahrens wenn du keine möglichkeit hast sie auszunutzen?
natürlich wäre es wahrscheinlich recht einfach möglich alle möglichen mappings durchzuprobieren (wobei ich selbst das bezweifle).
aber wie hilft dir nichts. du müsstest per Hand jeden einzelnen Versuch prüfen, da jeder zunächsteinmal sinn ergeben könnte.

[Ratte]

ist bei den anderen Verfahren aber nicht anders. Außerdem kann man vieles mit einer automatischen Rechtschreib bzw, Grammatikkontrolle filtern.

[negaH]

Natürlich nutze ich das aus !

Denn die allerletzte Möglichkeit irgendwas zu knacken ist immer die Brute Force Attacke, das Durchprobieren ! Und entscheidend für diese Methode ist die Komplexität, ergo die Größe des Schlüsselraumes. Und die ist eben bei deinem Verfahren auf den natürlichen Wortschatz unserer Sprache begrenzt.

Abstrahieren wir einfach mal:

Die entscheidene Operation die wir analysieren müssen ist die Transformation von einem Symbol zu einem anderen Symbol. Unsere Datendatei wird also immer zerlegt in solche einzelnen Symbole und diese dann kryptographisch transformiert.

In deinem Falle ist ein Symbol gleich einem deutschen Wort und es gibt max. 250000 solcher Symbole ergo ist unsere "Blockgröße" ca. 18 Bits groß. Wir mappen also 2^18 Symbole in 2^18 andere Symbole.

Bei AES ist ein Symbol so groß wie die Blockgröße des Ciphers, also 2^128 unterschiedliche Symbole werden transformiert auf 2^128 andere Symbole.

Die Komplexität einer Brute Force Attack auf eine EINZISGTE Transformation EINES Symboles beträgt also bei dir 2^18 und bei AES 2^128 !

Nehmen wir nun mal an wir könnten per Supercomputer exakt 2^18 Symbole pro Sekunde durchtesten dann würden wir bei deinem Verfahren exakt 1 Sekunde dafür benötigen. Bei AES aber

1298074214633706907132624082305024 Sekunden = 41161663325523430591470829 Jahre.

Laut Bruce Schneier wirst du also in dieser Zeitspanne circa

1749024623285053782 mal vom Blitz getroffen, und wirst 299490517685796 mal das komplette Universum implodieren sehen falls unser Universum insich geschlossen ist. Du wirst also 299490517685796 mal einen Urknall sehen können und kannst 299490517685796 mal Dinosauriern beim Aussterben zusehen können. So lange müsstest du warten bis dein Supercomputer nur EINE Transformation durchprobiert hat.

Soviel zum Unterschied von 1 Sekunde zu dem Aufwand bei heutigen echten Verschlüsselungen !!

Gruß Hagen

[glkgereon]

ja, das ist schon alles korrekt.
aber du übersiehst (soweit ich nichts übersehe^^) eine feinheit:

bei deinem Cipher kannst du prüfen, ob die entschlüsselung korrekt ist. (oder?).
das kannst du aber hier nicht so einfach, da alle "entschlüsselungen" rein von den daten her korrekt sein könnten.

oder übersehe ich da irgendwas völlig?

[Meflin]

Zitat:

Zitat von glkgereon

oder übersehe ich da irgendwas völlig?

vielleicht, dass die Anzahl der möglichen Entschlüsselungen einfach zu klein ist und diese auch nicht wirklich so viel Sinn ergeben wie du meinst dass sie alle ergeben sollten ;)

außerdem kann man beim aes natürlich überprüfen ob eine Entschlüsselung korrekt ist - wenn man ungefähr weiß was rauskommen soll. nur dass es so viele Möglichkeiten gibt, dass man es *praktisch* nicht überprüfen kann, weil man nicht alle durchprobieren kann. bei deinem verfahren schon. nur bei one time pads kann man nicht nachprüfen ob eine Entschlüsselung korrekt ist!

[glkgereon]

aber im normalfall weiss man ja nicht was rauskommen soll...

[negaH]

Zitat:

bei deinem Cipher kannst du prüfen, ob die entschlüsselung korrekt ist. (oder?).
das kannst du aber hier nicht so einfach, da alle "entschlüsselungen" rein von den daten her korrekt sein könnten.

Ok. Wenn wir ohne das Passwort NICHT überprüfen können ob eine Verschl. korrekt ist, WIE machen wir das dann ? Egal welchen Cipher wir betrachten wir "Probieren alles durch" wir machen eine Brute Force Attacke. Die Frage ist nun, wie groß wäre der Aufwaqnd dieses Angriffes ? Und diese Frage habe ich oben beantwortet.

Dein Verfahren ist einfach zu wenig komplex. Nicht nur zu wenig komplex als Algorithmus betrachtet (das haben wir ja noch garnicht gemacht) sondern einfach schon auf Grund der Daten die wir verarbeiten.

Beispiel: Wir benutzen das Verfahren um ein Passwort in einen Sesionkey zu verwandeln. Das Passwort selber darf nur 1 Symbol groß sein. Bei deinem Verfahren gibts also nur 250000 mögliche Passwörter und bei AES eben 2^128.

Siehe es einfach mal so:

Eine Verschl. ist wie eine Hashfunktion nur das man hier mit Hilfe eines Passwortes den Prozess umkehren kann, im Gegensatz zu einer Hashfunktion. Wenn wir das Passwort NICHT haben dann wird aus unserer Verschl. Funktion defakto eine Hashfunktion. Um eine Hashfunktion zu knacken müssen wir Kollisionen erzeugen. Um einen Cipher zu knacken müssen wir aus den Daten-Symbolen ein Passwort erzeugen. Bei beiden Verfahren ist also erstmal entscheidend wie Komplex unsere Symbol sind, dh. im Endeffekt wieviele unterschiedliche Symbol gibt es in unserem Set und wie werden sie auf andere Symbole transformiert. Bei AES transformiert unsere Verschl.algo. also 2^128 mögliche Symbol in 2^128 andere Symbole. Bei deinem Verfahren aber nur 2^18 in 2^18 andere, das ist bei weitem zu wenig um eine Brute Force Attacke auschließen zu können. Das bedeutet also das eine Brute Force Attacke, als Angriff der die schlechteste Komplexität hat gegenüber anderen Angriffen, durchaus im Bereich des machbaren bei deinem Verfahren liegt. Dies ist inakzeptabel für heutige Verfahren !

Ich habe also noch garnicht konkret angefangen dein Verfahren zu zerlegen, sondern habe einfach nur im Vorhinein analysiert wie maximal komplex dein Verfahren überhaupt sein kann. Ist diese Komplexität nicht größer als 2^128 so kann mann sagen "unsicher".

Gruß Hagen

[glkgereon]

hm...ok, überzeugt^^


aber den ansatz fand ich nett :-)

[negaH]

Zitat:

aber im normalfall weiss man ja nicht was rauskommen soll...

Und ??!! Das versuchen wir ja gerade heraus zu bekommen indem wir es knacken wollen. Und wenn es keinen besseren Angriff gibt so bleibt am Ende nur die Brute Force Attacke. Über diese Methode können theoretisch ALLE Verfahren geknackt werden, die Frage lautet nur WIE LANGE benötigen wir dazu, also wie hoch ist die Komplexität dieses Angriffes.

Nochmal: Wie würden wir also knacken ?

Wir müssen einen Satz aus Symbolen == Worten == Blöcken analysieren. Wir müssen also zb. 10 Wörter im Satz haben damit wie semantisch überprüfen können ob der Satz einen Sinn macht. Wir knacken also 10 * 2^18 Möglichkeiten in deinem Verfahren. Bei AES sinds aber schon 10 * 2^128.

Ergo: zu Pi*Daumen Abschätzung abstrahieren wir und betrachten erstmal nur die Transformations-Komplexität nur EINES Symboles ! Denn alles weitere ist eine rein multiplikative Formel die für alle Verfahren gilt.

Aber gut nun: denn es ist DEINE Aufgabe UNS mathematisch, mit einem stichhaltigen Beweis, davon zu überzeugen das dein Verfahren mindestens gleichsicher ist wie herkömmliche und standardisierte Verfahren.

Gruß Hagen

[negaH]

Zitat:

hm...ok, überzeugt^^
aber den ansatz fand ich nett

Das ist ja auch nicht schlecht. Denn wie will man es denn lernen wenn man es nicht probiert und durchrechnet ?

Eines steht fest, baust du das Ding so um das du die Textdatei auch noch hoch komprimierst, höher als mit normalen Verfahren möglich, dann ist dies doch ein enormer Vorteil (wie oben von mir vorgeschlagen). Die Daten nach dieser Wortbasierten Komprimierung kannst du ja immer noch per AES codieren.

Ein andere Vorteil ist die Frage "können wir als Menschen wie beim AES mit 128 Bit rechnen?" Nein. Ergo: statt einer Wortdatenbank als Datei könnte man das Verfahren so abwandeln das zb. die Bibel als Datenbank dienen könnte. Das heist das dein Verfahren in abgewandelter Form ein Verfahren wäre das auch ohne Rechentechnik durch einen Menschen manuell durchführbar ist. Das kann ein Vorteil sein den Verfahren wie AES nicht bieten können.

Gruß Hagen

[glkgereon]

Zitat:

Zitat von negaH

Eines steht fest, baust du das Ding so um das du die Textdatei auch noch hoch komprimierst, höher als mit normalen Verfahren möglich, dann ist dies doch ein enormer Vorteil (wie oben von mir vorgeschlagen). Die Daten nach dieser Wortbasierten Komprimierung kannst du ja immer noch per AES codieren.

Meinst du nun wirklich komprimieren oder meinst du codieren?
Zudem habe ich mittlerweile das Gefühl das ein "besseres als normale Verfahren" nicht wirklich erreichbar sind, da diese "normalen" Verfahren meisst beweisbar die besten sind. :-/

Zitat:

Zitat von negaH

Ein andere Vorteil ist die Frage "können wir als Menschen wie beim AES mit 128 Bit rechnen?" Nein. Ergo: statt einer Wortdatenbank als Datei könnte man das Verfahren so abwandeln das zb. die Bibel als Datenbank dienen könnte. Das heist das dein Verfahren in abgewandelter Form ein Verfahren wäre das auch ohne Rechentechnik durch einen Menschen manuell durchführbar ist. Das kann ein Vorteil sein den Verfahren wie AES nicht bieten können.

Das hingegen wäre ein interessanter ansatz...dann müsste es aber ja ganz ohne computer gehen.
und wie will man mal eben das 143.857'ste Wort in der Bibel finden? oO

[Ratte]

Zitat:

Zitat von glkgereon

Zitat:

Zitat von negaH

Eines steht fest, baust du das Ding so um das du die Textdatei auch noch hoch komprimierst, höher als mit normalen Verfahren möglich, dann ist dies doch ein enormer Vorteil (wie oben von mir vorgeschlagen). Die Daten nach dieser Wortbasierten Komprimierung kannst du ja immer noch per AES codieren.

Meinst du nun wirklich komprimieren oder meinst du codieren?
Zudem habe ich mittlerweile das Gefühl das ein "besseres als normale Verfahren" nicht wirklich erreichbar sind, da diese "normalen" Verfahren meisst beweisbar die besten sind. :-/

Ich denke er meint wirklich komprimieren. Texte werden ganz ähnlich komprimiert. Die Wörter werden halt durch eindeutige Zahlen ersetzt, diese sind kürzer als der Text (insbesondere wenn sie als binärzahlen und nicht als Strings gespeichert werden).

mfg,
Ratte

[Meflin]

Zitat:

Zitat von negaH

Und wenn es keinen besseren Angriff gibt so bleibt am Ende nur die Brute Force Attacke. Über diese Methode können theoretisch ALLE Verfahren geknackt werden, die Frage lautet nur WIE LANGE benötigen wir dazu, also wie hoch ist die Komplexität dieses Angriffes.

Das stimmt aber auch nicht :P One Time Pads sind per Brute force nicht knackbar, da ja jeder - und auch jeder sinnvolle - Output der in der Zeichenanzahl möglich ist dabei herauskommen wird, inklusive Zitaten aus der Bibel, Gesetzestexten oder was weis ich für ein Mist :mrgreen:

Oder willst du mir da jetzt was anderes erzählen :gruebel:

[negaH]

Zitat:

Meinst du nun wirklich komprimieren oder meinst du codieren?

Ja, komprimieren. Man kann sich nun streiten was "kodieren" nun eigentlich heist im wörtlichen Sinne. Ich für meinen Teil betrachte "Kodierung" als hierarische Übergruppe die dann Woote wie "komprimieren", "konvertieren", "verschlüsseln" usw. beinhaltet. Einen String in ein anderes Format konvertieren oder ein String zu komprimieren oder einen String zu verschlüsseln, ist für mich alles eine Form der Kodierung.

Zitat:

Zudem habe ich mittlerweile das Gefühl das ein "besseres als normale Verfahren" nicht wirklich erreichbar sind, da diese "normalen" Verfahren meisst beweisbar die besten sind. :-/

Hm ;) würde ich so nicht sagen wollen. Die heute bekannten Verfahren sind auf eine spezielle Schranke hin als sicher bewiesen. Diese Schranke setzt sich zusammen aus bekanntem Wissen + verfügbarer Hardware + verfügbarer Energie und ergibt eine minimal notwenige Zeitspanne als Aufwand.

Sogesehen gibt es nur einen BESTEN Cipher und das wäre der One Time Pad. Dieser ist aber praktisch technisch gesehen unsinnig.
Alle anderen, heute praktisch verwendeten Cipher, sind erwiesenermaßen unsicherer als der ideale OTP. Das macht aber nichts da deren Komplexität so enorm hoch ist das sie praktisch nicht knackbar sind (noch nicht heute, es fehlt Wissen + Technik + Energie == Zeit).

Sie sind also "heute" die Besten, aber nicht für alle Zeiten ;) Und da wir das auch wissen, können wir nochmals die Sicherheit erhöhen. Denn wenn wir math. beweisen und ausrechnen können das ein Algo. X heute Milliarden Jahre zum knacken benötigt wird so können wir eben auch interpolieren wie lange wir brauchen würden wenn wir 100 Jahre weiter wären in unserer Entwicklung, sowohl im Wissensstand und der Technologie. Diese Fähigkeit das tuen zu können basiert erstmal darauf das wir die Komplexität eines Algo X ausrechnen und auch beweisen können. Ohne dies ist der Algo. defakto wertlos.

Gruß Hagen

[negaH]

Zitat:

One Time Pads sind per Brute force nicht knackbar, da ja jeder - und auch jeder sinnvolle - Output der in der Zeichenanzahl möglich ist dabei herauskommen wird, inklusive Zitaten aus der Bibel, Gesetzestexten oder was weis ich für ein Mist Mr. Green

Oder willst du mir da jetzt was anderes erzählen

Jain ;) Du hast schon Recht aber deine Ableitung des Möglichen ist meiner Meinung nach falsch.

Man kann auch auf OTPs eine Brute Force Attacke anwenden, nur wird sie definitiv zu keinerlei Erfolg führen ;)

Echte OTPs sind also tatsächlich die einzigste Verschlüsselung (und werden es auch auf Ewigkeit bleiben) die auch durch eine Brute Force Attacke effektiv nicht knackbar sind. Sie stellen damit das maximal machbare und sicherste dar, auch wenn sie praktisch gesehen fast keinerlei Bedeutung haben. Denn wir haben das Problem das ein OTP Password

1.) aus echtem beweisbar niemals reproduzierbaren Zufall bestehen müssen, und es eben keinen beweisbar echten Zufall gibt. Wäre dieser Zufall nämlich beweisbar dann würden wir diesen auch reproduzieren können ansonsten könnten wir nicht beweisen das er wirklich echt zufällig sein muß. Das bezieht sich jetzt auf den mathematische Sichtweise nund NICHT auf physikalische/philosophische Annahmen und Vermutungen !!

2.) dieses Password können wir nicht komprimieren

3.) dieses Password können wir nur durch einen OTP selber geschützt speichern. Würden wir einen normalen Cipher benutzten so reduzieren wir die Effektive Sicherheit dieses OTPs auf die Sicherheit des verwendeten Ciphers. Also können wir nur einen OTP benutzen um ein OTP Password zu schützen und damit auch auszutauschen. Aber dann benötigen wir eine Möglichekit das Pasword des OTPs mit dem wir das OTP Password geschützt haben zu schützen. Die Katze beist sich also in den Schwanz.

Dieser letzte Punkt ist es warum OTPs eben unpraktikabel sind. Wir könne das benutzte Passwort NIERGENDS speichern oder schützen so daß seine effektive Sicherheit NICHT reduziert würde. Das geht nicht mit Hardware noch mit Software noch in unserem Kopf. Denn all dies sind Schutzverfahren deren Knackbarkeit unter der Schranke eines ecten OTPs liegen. Man wird also mit weitaus höherer Wahrscheinlichkeit ein Hirn/SmartCards/Software knacken können als einen echten OTP.

Gruß Hagen

[DGL-luke]

ähm... ich bin nicht so weit mitgekommen glaub ich, aber kann man Bruteforce denn auf dieses Verfahren (das glkgereon hier skizziert) anwenden? ist das nicht ähnlich wie bei OTP - es kann alles mögliche beim BruteForce rauskommen, aber da wir ja keine statistischen Zyklikäten (:mrgreen:) drinhaben, können wir nie herausfinden, welches Ergebnis das richtige ist?

[St.Pauli]

Zitat:

Zitat von negaH

1.) aus echtem beweisbar niemals reproduzierbaren Zufall bestehen müssen, und es eben keinen beweisbar echten Zufall gibt. Wäre dieser Zufall nämlich beweisbar dann würden wir diesen auch reproduzieren können ansonsten könnten wir nicht beweisen das er wirklich echt zufällig sein muß. Das bezieht sich jetzt auf den mathematische Sichtweise nund NICHT auf physikalische/philosophische Annahmen und Vermutungen !!

Kann ich nicht, wenn ich genügend Ausgaben einer zufälligen Quelle habe, beweisen, dass die Wahrscheinlichkeit des folgenden Bits für 0 oder 1 bei genau bei 1/2 liegt?

[DGL-luke]

Ja, aber das trifft auf jeden "guten" Pseudo-Zufall zu.

Und du kannst nicht widerlegen, dass "Gott" oder eine sonstige Intelligenz mit mehr bzw. besseren Möglichkeiten bzw. technischer Ausstattung als wir, die Möglichkeit haben könnte, Heisenberg (gar nicht beachten, nur n Buzzword ;) ) links liegen zu lassen und das Diodenrauschen zu reproduzieren.

[negaH]

Zitat:

Kann ich nicht, wenn ich genügend Ausgaben einer zufälligen Quelle habe, beweisen, dass die Wahrscheinlichkeit des folgenden Bits für 0 oder 1 bei genau bei 1/2 liegt?

Ja kanst du, aber das sagt defakto garnichts aus. Wir können mit einem Pseudo-Zufallsgenerator wie zb. dem Quadratischen Reste Generator, sehr wohl Bitfolgen erzeugen bei denen wir NUR die Aussage treffen können das das nächste Bit mit 50% eine 1 oder 0 sein kann. Das ist reine Statistk des Zufalls bedeutet aber eben nicht das wir diesen Zufall vorhersagen können oder nicht. Im Falle des Quadratischen Restegenerators können wir nur dann eine exakte Vorhersage machen (also den Zufallsstrom berchnen) wenn wir alle Paramater dieses Generators kennen. Kennen wir diese Paramater aber nciht dann ist dieser Pseudo-Zufalls-Generator exakt gleich stark wie ein echter RNG. Gernaugenommen wäre dieser RNG sogar stärker als echter Zufall, denn im gegensatz zum echten Zufall können wir mathematisch ALLES daran beweisen. Wir wissen also das wenn wir die Schranken genügend hoch ansetzen und keinem die geheimen Startparameter verraten das keiner diesen RNG vorhersagen kann, nur wir könnte es. Aus Sicht dieser anderen Personen habe die also den Outpu eines "echten" Zufallsgenerators vor sich, da sie ihn beweisbar nie brechen können.

Mathematisch betrachtet gibt es keinen echten Zufall ! Dies lässt sich per Kontradiktion beweisen. Denn wenn wir beweisen können das ein Zufall wirklich zufällig ist so müssten wir eine Formel finden um dies beweisen zu können. Haben wir aber eine Formel gefunden dann wäre dieser "echte " Zufall maximal nur so sicher wei ein guter und sicherer Pseudo-Zufalls-Generator, ja defakto ist dieser "echte" Zufallsgenerator dann nur noch ein Pseudo-Zufallsgenerator, wir kennen ja seine Formel und die Vorhersagbarkeit hängt dann nur noch von seiner Komplexität und dem Fakt ab ob wir die gheimen Startparameter kennen oder nicht. Das bedeutet ein "echter" Zufallsgenerator der mathem. beweisbar zufällig ist ist damit autom. zu einem Pseudo-Zufalls-Generator degeneriert oder eben weiterentwickelt.

Zitat:

ähm... ich bin nicht so weit mitgekommen glaub ich, aber kann man Bruteforce denn auf dieses Verfahren (das glkgereon hier skizziert) anwenden? ist das nicht ähnlich wie bei OTP - es kann alles mögliche beim BruteForce rauskommen, aber da wir ja keine statistischen Zyklikäten (Mr. Green) drinhaben, können wir nie herausfinden, welches Ergebnis das richtige ist?

Soweit haben wir die Analyse der Sicherheit noch garnicht voran getrieben. Im Falle des Verfahrens kann man sehr wohl eine Abschätzung treffen ob man richtig oder falsch geknackt hat. Denn er mappt ja immer mit der gleichen Lookuptabelle zb. das Wort UND in das Wort ABER. Die Häufigkeiten des Wortes UND in unserer Sprache ist aber eine andere als beim Wort HAUS. Ergo: kommt das Wort ABER im Text hüfiger vor wissen wir das es nicht HAUS sein kann sondern eher ein UND.

Das ist ein stink normaler Angriff wie auf Cäsar Ciphern üblich. Es wurde oben auch schon angesprochen das dieser simple Angriff möglich sein wird. Möchte man aber nun abschätzen wie lange man dafür benötigte, im Worstcase, dann benötigen wir die Größe des untersuchten Schlüsselrauems, eben hier 2^18 statt 2^128.

Gruß Hagen

[negaH]

Zitat:

Und du kannst nicht widerlegen, dass "Gott" oder eine sonstige Intelligenz mit mehr bzw. besseren Möglichkeiten bzw. technischer Ausstattung als wir, die Möglichkeit haben könnte, Heisenberg (gar nicht beachten, nur n Buzzword Wink ) links liegen zu lassen und das Diodenrauschen zu reproduzieren.

Gut, deshalb sagte ich MATHEMATISCH und NICHT physikalisch, ideologisch oder eben philosophisch. Und interresiert Gott oder Elektronen oder Universen oder Heisenberg oder sonstwas nicht im geringsten, wir reden über Mathematik und einem praktischen Anwendungsgebiet dessen, der Kryptographie. Alles ist und sollte dort beweisbar sein, denn beweisbar bedeutet das nötige Wissen zu haben und Wissen zu haben bedeutet NICHT glauben noch vermuten zu müssen sondern es zu WISSEN !

Das Diodenrauschen IST reproduzierbar. Denn wir leben in einem abgeschlossenen System und wenn wir alle Startparameter dieses Systemes kennen würden dann ist alles vorhersagbar. Jede andere Annahme wird uns praktisch gesehen zu nichts nützlichem bringen. Wir müssen also davon ausgehen das es uns schnuppe ist ob Gott in der Lage wäre unsere Daten zu knacken, es interessiert uns nicht denn wir wollen ja nur das andere Menschen nicht unsere Daten knacken können. Es macht keinen Sinn seine Daten durch Verschlüsselung vor einem Gott schützen zu wollen, also macht es auch keinen Sinn in unser System, Gedankengebäude, die Existenz eines Gottes anzunehmen. Das gleiche gilt für Außerirdische oder eben auch für Menschen die beim NSA arbeiten. Denn wenn die unsere Daten knacken können dann wissen wir dies nicht und in unserem System können wir so oder so nur von unserem bestehendem Wissen ausgehen. Dies erklärt meine Einstellung dazu das WISSEN absolut frei sein muß, denn das ist es was uns definiert !!

Ich möchte also nichts widerlegen, sondern das was ich habe und weis als sicher beweisen können. Alles andere ist reine Philosophie oder besser gesagt Spekulation, ergo Vermutungen, Annahmen, Glaube und nicht Wissen.

Und wir können sehr wohl solche abstraktionen akzeptieren, denn wir vergleichen ja nicht das Verfahren Gott mit AES sondern ein Verfahrensvorschlag der auf Software basiert mit zb. AES.

Gruß Hagen

[xaromz]

Hallo,

Zitat:

Zitat von negaH

Das Diodenrauschen IST reproduzierbar. Denn wir leben in einem abgeschlossenen System...

Ich glaube, ich muss dich erschießen. Du weißt zu viel :mrgreen: .
Aber im Ernst: Ich finde diese Diskussion (wie viele andere, in denen Du Dich zu Wort meldest,) höchst faszinierend.

Ist es eigentlich nicht so, dass jede Verschlüsselung, die auf der menschlichen Sprache aufbaut, per se nicht genügend sicher sein kann? Ich habe dafür zwar keinen Beweiß, aber mein Bauchgefühl sagt mir sowas. Die menschliche Sprache ist doch zu regelmäßig, so dass man mit Wahrscheinlichkeiten und Plausabilitätsprüfungen immer Ansatzpunkte findet.

Gruß
xaromz

[negaH]

Zitat:

Ist es eigentlich nicht so, dass jede Verschlüsselung, die auf der menschlichen Sprache aufbaut, per se nicht genügend sicher sein kann?

Vorsicht ;) Was verstehst du unter menschlicher Sprache ? Die Sprache eines Menschen ? Gut dann sind aber die Navaho Indianer ebenfalls Menschen. Aber deren Sprache wurde durch die Amis im 2.WK als Verschlüsselung benutzt und diese wurde bis heute noch nicht geknackt ;)

Gruß Hagen

[Daniel G]

Zitat:

Zitat von xaromz

Ich habe dafür zwar keinen Beweiß, aber mein Bauchgefühl sagt mir sowas.

Dein Bauch hat in der Wissenschaft nichts zu suchen. :mrgreen:

Aber es klingt zumindest logisch. Da die Sprache ja vom Menschen benutzt wird, muss sie automatisch einem bestimmten, nicht allzu komplizierten (was nicht zwangsläufig heißt "nicht komplexen") System folgen. Ergo müsste jede Sprache knackbar sein.

@negaH:
Aber deren Sprache folgt doch sicher auch einem bestimmten System, oder?

[xaromz]

Hallo,

Zitat:

Zitat von negaH

Vorsicht ;) Was verstehst du unter menschlicher Sprache ? Die Sprache eines Menschen ? Gut dann sind aber die Navaho Indianer ebenfalls Menschen. Aber deren Sprache wurde durch die Amis im 2.WK als Verschlüsselung benutzt und diese wurde bis heute noch nicht geknackt ;)

Du hast zwar Recht, dass diese damals nicht geknackt wurde, inzwischen ist diese Sprache aber wohl entschlüsselt, siehe hier. Außerdem: ist das deshalb kryptographisch sicher, weil keiner es entschlüsselt hat? Ich denke doch nicht. Korrigier mich, wenn ich falsch liege.
Mit menschlicher Sprache meine ich die geschriebene Sprache, präziser eine Sprache, die aus Konsonanten und Vokalen besteht (was Ideogramme ausschließt), so wie in dem vorliegenden Fall. Tut mir leid, wenn ich mich hier etwas schwammig ausgedrückt habe. Natürlich könnte auch jemand EAS sprechen, wenn er das aussprechen könnte. Nur kann sich keiner so viele Wörter merken :stupid: .

Gruß
xaromz

[glkgereon]

Zitat:

Zitat von negaH

Soweit haben wir die Analyse der Sicherheit noch garnicht voran getrieben. Im Falle des Verfahrens kann man sehr wohl eine Abschätzung treffen ob man richtig oder falsch geknackt hat. Denn er mappt ja immer mit der gleichen Lookuptabelle zb. das Wort UND in das Wort ABER. Die Häufigkeiten des Wortes UND in unserer Sprache ist aber eine andere als beim Wort HAUS. Ergo: kommt das Wort ABER im Text hüfiger vor wissen wir das es nicht HAUS sein kann sondern eher ein UND.

*MÖÖÖP*
Das ist schlicht und einfach falsch! (*froi* das ich das mal zu hagen sagen darf :-) :mrgreen: )
Denn mit hoher Wahrscheinlichkeit wird ein Und kein zweites mal wieder als das selbe wort kodiert!
(Das kann nur vorkommen wenn die "links" in der Index-Datei eine Schleife bilden (was sie zwangsläudig tuen) und bei einer schleifenlänge von X die beiden unds genau X wörter abstand voneinander haben)

Die Imho einzige möglichkeit diese verschlüsselung zu knacken (wenn man sie noch etwas verbessert, zb nur Nomen durch nomen und verben durch verben ersetzen...) wäre ein durchprobieren aller möglichen Index-Files und aller möglichen Ausgangstexte die in Frage kommen (Die Wortanzahl sowie die Wortliste ist ja gegeben...).

Allerdings hat diese Methode noch einen ganz anderen Haken :-)
Was machst du wenn du NUR den verschlüsselten Text hast?
Du hast weder die Wortliste (also keine Ahnung was für werte überhaupt in Frage kommen)
und auch keine Index-Datei (Und auch keine Ahnung wie groß diese überhaupt sein muss etc.)
Hier sehe ich eigentlich keinen ansatzpunkt, da nichteinmal brute-force greift...

[alcaeus]

Zitat:

Zitat von glkgereon

Das ist schlicht und einfach falsch! (*froi* das ich das mal zu hagen sagen darf :-) :mrgreen: )
Denn mit hoher Wahrscheinlichkeit wird ein Und kein zweites mal wieder als das selbe wort kodiert!

Hui, wenn du dich da mal nicht zu weit rausgelehnt hast. So wie ich das sehe, hat die Index-Datei immer so viele Woerter wie der zu kodierende Text selber. Entweder das, oder du hast nicht genug Code hergegeben. Ich finde z.B. beim besten Willen nicht heraus, wo du WL.Count hernimmst.

So, wenn jetzt diese Index-Datei immer dieselbe Laenge hat, wie der Text, dann wird jedes Wort immer mit demselben Wort ersetzt werden, also z.B. "aber" immer durch "und". Da hast du dann mit einer lexikalischen Analyse seeehr leichtes Spiel.
Mal als Beispiel: wir hatten bei der Info-Klausur im letzten Semester nen RSA-Algorithmus, den wir analysieren und korrigieren sollten; da war ein grosser Fehler drin. Der Fehler war, dass Zeichen fuer Zeichen codiert wurde, und nicht ein Block der grad so gross war, dass er noch in die Berechnung der codierten Zeichen reingepasst hat. Das hat dem Algorithmus jegliche Sicherheit genommen, da ein "e" immer zum Zeichen "x" wurde, ein "s" immer zum Zeichen "y", usw. Erst durch das Kodieren von Bloecken, und nicht einzelnen Zeichen, kann man sowas sicher machen. Bei dem Algorithmus bin ich naemlich mit einer lexikalischen Analyse (oder nichtmal das, ich brauch nur Buchstabenhaeufigkeiten herzunehmen) ziemlich schnell durch.

Dasselbe gilt fuer deinen Algorithmus. Ich sehe momentan nichts, was das Ding so sicher macht. Klar, du behauptest dass man mit Brute Force keinen Ansatz haette, aber den gibt es. Ich dekodiere den Text per Brute Force, was aufgrund der Schluessellaenge bei deinem Algorithmus ein Kinderspiel ist. Sobald ich ihn dekodiert habe, suche ich mir aus allen erhaltenen Texten die 10 haeufigsten Buchstaben raus. Stimmen mindestens 7 mit Erfahrungswerten der deutschen Sprache ueberein, so behalt ich den Text, wenn nicht dann werf ich ihn weg. So kann ich von 250000 moeglichen Texten ziemlich schnell auf wenige Hundert runtergehn. Wenn ich dann nochmal eine Sinnanalyse dranhaeng, dann ist das Verfahren so gut wie geknackt. Ich muss nicht nur durch Brute Force alleine durchkommen, damit ein Algorithmus unsicher ist. Fuer das oben beschriebene Verfahren braeuchte ein normaler, handelsueblicher Rechner weniger als eine Stunde. Eine Stunde ist fuer einen kryptographischen Algorithmus dermassen laecherlich, dass man ihn schon nach der ersten Analyse (die Hagen fuer dich gemacht hat) wegwirft. Nimms mir nicht uebel, es ist zwar gut dass du dich damit befasst, aber du musst einsehen, wenn etwas nicht wirklich was bringt. Die Idee ist an sich auch gut, aber es sind einige Schwachstellen in den Ueberlegungen des Algorithmus, und auch einige in der Implementierung.

Eine der Schwachstellen waere zum Beispiel, dass ich die Index-Datei mitliefern muss um den Text entschluesseln zu koennen. Das heisst, ich muss mir wieder ein sicheres Medium suchen, um die Index-Datei zu uebertragen; schliesslich hat der Algorithmus ja noch keine Passphrase. Da bist du wieder beim Problem der OTPs, das Hagen angesprochen hat. Du wuerdest also wahrscheinlich die Index-Datei mit einem asymetrisches Verfahren verschluesseln; naja, warum dann nicht den ganzen Text? ;)

Wenn du dich wirklich mit Kryptographie und solchen Algorithmen beschaeftigen willst, dann hab ich nur einen Tipp fuer dich: hol dir richtige Buecher. Vergiss Dan Brown. Eigne dir das mathematische Wissen an, das du dafuer benoetigst. Hier geht es vor allem um Beweise, denn ein kryptographischer Algorithmus beruht am Ende nur auf dem mathematischen Beweis, dass er funktioniert und dass er nur in soundsoviel Jahren knackbar ist. Weiters, lies dich in bestehende Verfahren ein. Beginn mit der Codierung (Shannon-Fano, LZ-77, LZW), um einen Einblick zu erhalten, wie das funktioniert. Anschliessend nimmst du dir ein paar Algorithmen vor (z.B. DES, AES, RSA) und arbeitest die durch. Ein paar Hash-Funktionen koennen auch nicht schaden (mein Tipp: MD5 und SHA). Wenn du das durch hast, hast du erstens die mathematischen Vorkenntnisse, zweitens hast du ein Grundwissen zur Codierung und zu solchen Algorithmen, und du siehst worauf andere Leute beim Entwurf ihrer Algorithmen geachtet haben. Eine Stunde damit hilft dir mehr als einen Tag mit allen krypto-technischen Ideen von Dan Brown zusammen.

Greetz
alcaeus

[Ratte]

Seine Schlüsseldatei ist nicht genausolang wie der Text (hat er zumindest geschrieben). Aus dem Source geht das allerdings wirklich nicht hervor.
halb-OT:Welche Bücher empfiehlst du denn so?

[alcaeus]

Zitat:

Zitat von Ratte

Seine Schlüsseldatei ist nicht genausolang wie der Text (hat er zumindest geschrieben). Aus dem Source geht das allerdings wirklich nicht hervor.

Ja, da hab ich mich etwas ungenau ausgedrueckt. Ich meinte dass die Index-Datei genausoviele eindeutige Woerter wie der Text hat, d.h. jedes Wort, das mindestens einmal im Text vorkommt, ist auch im Index. Das aendert aber nichts an der obigen Beschreibung ;)

Greetz
alcaeus

[Daniel G]

Ich bin zwar nicht Hagen (:duck:), aber ich habe mir sagen lassen, dass "Codes" von Simon Singh ein gutes, leicht verständliches Buch sei.



Ich hab's jetzt mal gebraucht bestellt. Wehe, jemand sagt was anderes. :mrgreen:

[Ratte]

Das Buch habe ich. Bietet einen recht guten Überblick über verschiedene Verfahren und insbesondere die Geschichte. Geht aber nicht so genau auf die Arbeitsweise von modernen Verfahren ein. Trotzdem sehr guter Einstieg (finde ich).

Ratte

[OregonGhost]

Zitat:

Ist es eigentlich nicht so, dass jede Verschlüsselung, die auf der menschlichen Sprache aufbaut, per se nicht genügend sicher sein kann?

Zitat:

Da die Sprache ja vom Menschen benutzt wird, muss sie automatisch einem bestimmten, nicht allzu komplizierten (was nicht zwangsläufig heißt "nicht komplexen") System folgen.

Warum kann dann keine Software vernünftig deutsche Sprache sprechen / interpretieren? :roll:
Da würde mich jetzt insbesondere Hagens Antwort mal zu interessieren :mrgreen: