JHCode Verschlüsselungssoftware - Bitte Testen!

Coder · Beiträge: 1383 Erhaltene Danke: 1 WinXP D2005 PE

Hi,
nicht ganz richtig aber falsch.
Es gibt nicht 20 Möglichkeiten für 20 'e' sondern für Jedes der 20 'e' 256 Möglichkeiten.
Außerdem ist das Datenformat der Daten, die zu verschlüsseln sind bzw. entschlüsselt wurden, beliebig.
Man stelle sich einen Menschen vor, der gleichzeitig einen Teil der Information spricht und einen anderen Teil der Information an eine Tafel schreibt.
Diese beiden Teile der Information werden durch eine unten durchlaufende Schrift und einen Kundigen der Gebärdensprache als Bild im Bild komplettiert.
Die Aufzeichnung ist natürlich komprimiert.
Dann wurde diese Datei verschlüsselt. - Und jetzt viel Spaß bei der Kryptanalyse !!!"
Vertauschung und Ersetzung habe ich nicht erfunden, aber nur auf Bytes optimiert ist der ausführbare Schlüssel 512 Bytes groß.
Wie soll ein Mensch damit umgehen?
Das besondere an meinem Verfahren ist es, dass es einen Quellschlüssel gibt, der sicher verwahrt bzw. versandt werden kann.
Für den Schlüsselrohling reicht eine Literaturangabe (readme.txt von Software "ccccc" Version n.nn).
Es könnte aber auch der zuletzt verschlüsselt übertragene Text sein.
An diesem Text wird dann noch eine Veränderung vorgenommen, die vorher abgesprochen war, auf einem getrennten Weg übermittelt wird und/oder eine Information einbezieht, über die nur beide Seiten verfügen.
Die Abbildung des Quellschlüssels auf den ausführbaren Schlüssel ist ziemlich chaotisch.
Deshalb haben schon kleine Änderungen am Quellschlüssel große Auswirkungen auf den ausführbaren Schlüssel.
Da es keine Einschränkungen für den Quellschlüssel gibt, besteht Anlass zu der Annahme, dass auch jeder der 7 mal 10 hoch 1013 verschiedenen ausführbaren Schlüssel erreichbar ist (256 Fakultät mal 256 Fakultät).

Der Kontrollblock, der unverschlüsselt aufsteigend alle Werte von 0 bis 255 enthält, beinhaltet aber nicht den Schlüssel.
Es gibt keinen Zusammenhang zwischen einer bestimmten Ersetzung und einer bestimmten Vertauschung.
Wenn ein fascher Wert auf der falschen Position aber in der Reihenfolge richtig landet, funktioniert der Kontrollblock nicht.
Dies ist aber sehr unwahrscheinlich, weil es dann auf mindestens einer anderen Position auch noch so laufen muss.
Wenn man eine Tabelle hat, kann man die andere herleiten. Für eine Tabelle gibt es aber 256! Möglichkeiten.
Also kann man mit diesem Verlust an Sicherheit leben.

MfG Jörg

Quake User · Beiträge: 159

Zum Thema Patent:

- kann es sein, dass die Offenlegungsschrift DE10221867 gemeint ist?
- das ist eine A1
- Aktenzeichen 10121867.2
- Anmeldetag 05.05.2001
- Offenlegung 14.11.2002
- das ist bis dahin eine Anmeldung und kein erteiltes Patent.
- anmelden kann man Vieles
- für diese Schrift ist ein Prüfungsantrag gestellt

Noch zur Dikussion:
selbst ein erteiltes Patent ist KEIN Qualitätsmerkmal. Ein Patent wird erteilt wenn etwas neu ist und noch einige weitere Kriterien erfüllt.
OB eine Verschlüsselung sicher ist KANN UND DARF EIN PATENTAMT NICHT TESTEN.

Frag doch mal deinen Freund, Dipl. Math. Jörg Hartmann, ob er sich nicht an der Diskussion beteiligen möchte. Ich würde mich darauf freuen. Er hat viel Zeit in diese Projekt investiert und kann sicher einiges schneller klären.

negaH · Beiträge: 17

Zitat:

nicht ganz richtig aber falsch.
Es gibt nicht ...

....verschiedenen ausführbaren Schlüssel erreichbar ist (256 Fakultät mal 256 Fakultät).

Möchtest du eine ernsthafte Analyse und kannst du mit Kritik auch umgehen ?

Wenn ja, dann antworte nicht mit leeren Phrasen wie man Quellschlüssel, Dateien als Schlüssel benutzen kann oder das es das Besondere an dem Verfahren ist das man beliebige Dateien damit verschlüsseln kann. Hast du dir mal anerkannte Verfahren wie AES, Blowfish, IDEA angeschaut ? Nein ? Dann wüsstest du auch das man mit allen sichderen Verfahren beliebige Daten bzw. Dateiformate verschlüsseln kann. Das man das Schlüselmanagement dabei beliebig gestalten kann, also auch aus Textdateien Schlüssel erstellen kann, ist ein Normalzustand.

Ergo: alles leere Phrasen die dein Verfahren in nichts von anderen unterscheidet und schon garnicht sicherer macht als diese. Denn statt auf die Essenz deines Verfahrens einzugehen, zu beweisen das mein Angriff garnicht funktionieren kann, argumentierst du am Thema vorbei.

Beschreibe doch erstmal das Verfahren auf eine Weise das man es auch nachvollziehen kann. Es könnte ja durchaus sein das Leser wie ich deine "Dokumentation" des Verfahrens gründlich mißverstanden haben.
Beschränke dich dabei aber bitte nur auf den Algorithmus, ohne irgendwas von Passwörtern aus Dateien erzeugen zu könen oder ähnlichem Quatsch. Das ist nämlich zur Analyse des Verfahrens absolut irrelevant. Erstmal musst du die Stärke des Verfahrens erklären können.

Wie gesagt: ich behaupte das ich mit einer Nachricht aus 256 Datenblöcken a 256 Bytes so wie oben konstruiert jeden beliebigen Schlüssel direkt aus dem erzeugten Output knacken kann. Beweise mir nun mathematisch das ich damit falsch liegen muß.

Die Frage ist nun ob du überhaupt Interesse an einer konstuktiven Diskussion hast.

Gruß Hagen

negaH · Beiträge: 17

So, ich habe mir jetzt das Patent durchgelesen und kann nun exakt das nachholen was der Threadersteller hätte tuen müssen.

Das Verfahren arbeitet sehr simpel. Wir haben zwei Tabellen aus 256 Bytes. Eine Tabelle, ich nenne sie man Substitutionstabelle kurz "Subst" und eine "Transpositionstabelle" ich nenne sie mal "Trans".

Eine Grundbedingung ist das in beiden Tabellen die Bytes 0 bis 255 jeweils 1 mal vorkommen müssen. Also das was ich oben schon sagte wenn es keine schwachen Schlüssel geben soll. Das bedeutet pro Tabelle gibt es 256! also exakt

85 78177 75342 84265 41190 82271 68123 26251 57781 52027 94856 19859 65565 03772 69452 55314 75893 77440 29136 04514 08450 37588 53423 36584 30615 71968 34693 69647 53222 89288 49742 60256 79637 33256 33687 86442 67520 76267 94560 18796 88679 71521 14330 77020 77526 64645 14647 09187 32610 08328 76325 70281 89807 73671 78145 41702 50523 01860 84953 19068 13825 74810 70252 81755 94594 76987 03466 57127 38139 28620 52347 56808 21886 07012 03611 08315 20935 01947 43710 91017 26968 26286 16062 63662 43502 28409 44191 40842 46159 36000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000

Schlüsselkombinationen. Betrachtet man beide Tabellen als Passwort so gibt es 256!^2 Schlüssel.

Gut, aber das macht das Ding eben nicht kryptographisch sicher. Ich erkläre hier einenAngriff der mit 100% Erfolg ein beliebiges Passwort, sprich den Inhalt beider Tabellen errechnen kann. Das dauert nur wenige Millisekunden.

Der Angriff basiert auf einer Choosen PlainText Attacke, man kann also bei unbekannten Passwort die Nachricht die verschlüsselt werden soll dem Benutzer unterjubeln.

Der Algo besteht aus nachfolgenden wenigen Delphi Quelltextzeilen

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

type
  TDataBlock = array[Byte] of Byte;

function Encrypt(const Data,Subst,Trans: TDataBlock): TDataBlock;
var
  I: Integer;
begin
  for I := Low(Data) to High(Data) do
   Result[Trans[I]] := Subst[Data[I]];
end;

Das ist alles. Subst und Trans ist unser 512 Bytes Passwort und in Subst und Trans muß jeder Wert zwischen 0 bis 255 exakt einmal vorkommen, kann aber in beliebiger Reihenfolge vorkommen.

Wir senden dem Besitzer des Schlüssels eine Nachricht der er für uns verschlüsseln soll. Diese Nachricht besteht exakt aus 257 * 256 = 65792 Bytes. Die ersten 256 Bytes sind 0, die nächsten 256 Bytes sind alle 1 danach 256 Bytes mit 2 usw. bis 255. Der letzte, 257'te Datenblock besteht aber aus den Bytes 0,1,2,3..255.

Nachfolgender Sourcecode kann nun aus der verschlüsselsten Nachricht die wir vom Besitzer des Schlüssel ja wieder bekommen seinen Schlüssel auf direktem Wege knacken !!

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:

type
  TDataBlock = array[Byte] of Byte;

  TForm1 = class(TForm)
    M: TMemo;
    procedure FormCreate(Sender: TObject);
  private
  public
    procedure Print(const Msg: String; const Data: TDataBlock);
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

function Encrypt(const Data,Subst,Trans: TDataBlock): TDataBlock;
var
  I: Integer;
begin
  for I := Low(Data) to High(Data) do
    Result[Trans[I]] := Subst[Data[I]];
end;

function MakeKey: TDataBlock;
var
  I,J,T: Integer;
begin
// Schlüsselpart mit 0 bis 255 füllen
  for I := Low(Result) to High(Result) do
    Result[I] := I;
// Schlüssel per Zufall vermischen
  for I := Low(Result) to High(Result) do
  begin
    J := Random(256);
    T := Result[I];
    Result[I] := Result[J];
    Result[J] := T;
  end;
end;

procedure TForm1.Print(const Msg: String; const Data: TDataBlock);
var
  I: Integer;
  S: String;
begin
  S := Msg + StringOfChar(' ', 8 - Length(Msg)) + ': ';
  for I := Low(Data) to High(Data) do
    S := S + IntToHex(Data[I], 2);
  M.Lines.Add(S);
end;

procedure TForm1.FormCreate(Sender: TObject);
var
  Subst,Trans: TDataBlock;
  I,J: Integer;
  Data,MySubst,MyTrans: TDataBlock;
begin
  Randomize;
  
// Schlüssel erzeugen
  Subst := MakeKey;
  Trans := MakeKey;

  Print('Subst', Subst);
  Print('Trans', Trans);

//  Schlüssel knacken, wir lassen eine Nachricht verschlüsseln die aus
// 256 Datenblöcken a 256 Bytes besteht. Dabei ist der 1. Datenblkock mit 0 gefüllt,
// der 2. Datenblock mit 1, der 3. mit 2 usw.
  for I := Low(MySubst) to High(MySubst) do
  begin
    FillChar(Data, SizeOf(Data), I);
    MySubst[I] := Encrypt(Data, Subst, Trans)[0];
  end;
// der letzte, 257'te Datenblock besteht aus 0,1,2,..255
  for I := Low(Data) to High(Data) do
    Data[I] := I;
  Data := Encrypt(Data, Subst, Trans);
// mit hilfe von MySubst, der geknackten Subst Tabelle ermiteln wir MyTrans
  for I := Low(MySubst) to High(MySubst) do
    for J := Low(Data) to High(Data) do
      if Data[J] = MySubst[I] then
      begin
        MyTrans[I] := J;
        Break;
      end;
// wir können direkt die Subst-Tabelle aus dem verschlüsselten Output errechnen
  Print('MySubst', MySubst);
  Print('MyTrans', MyTrans);
end;

Beispiel:

markieren

Quelltext

1:
2:
3:
4:
5:

Subst   : 300AFC864A661A2921E9344C14E4C895018862BA0736058C3EB5278F3FA848C404C09B9F400DC21819D6F4EC5F00AF7813B2F0355416F876A608EA4BA2708433BF7DA0E6118172AC63795C53B315B145DE8364F5AB3A6DB85DB6289CEDAE9ACA90F69857F9068DF112A4097A38EF96226AF3AA671E939DCD5BD27F266EB949FEF71DD12D020397CE1C681756379EDA3BC5CF7B758E5AE1445523DC8774A599A74FD020B7422E73BBDBC7946C0C8B5E39CCE3258046C98AF2D5431BD9BEC30EFF607E773261412F91D7CBADE5E8C6E26BDDA11F100F4E926582D8E0A9BCFD472BA33DD3E7505871C152890B852451597CDF31D4FB4DBD2AB43CEEB069EB6F2CFA
Trans   : 034C0B2BDE9CB20D5BCA27312450DFD78889978758696EAD26A513B96AA757E344EE6BE9CBF1189534FAF035B5A91A61A18F297D75A4AA7F91114F52BF0F4D813ED23D9668930A2F51EFEA72E6F825DBA3E5CDC683C716A2C5326566F6CE9A0999B0E408F73A4336767B63D8AEAF221C33B7D479775A2C7EF98DBD3B5C8B8ED5B3E29DAB9E604098943C37B8C3C2530C17675473BB2DEBACBA4EC8ED2E428C8523381F82BE90F45E5D5F065604021B10D3304A9F156F9245FC8A6CA6E084054648F301E8F2FECFDC146249D6E74BECA89BC4DA21D07CBC80E1553FB6DD742012B46D411DD9712AC9FD19C00ED1F50739CC70B186597A1EC1A0280047FB6478FF

MySubst : 300AFC864A661A2921E9344C14E4C895018862BA0736058C3EB5278F3FA848C404C09B9F400DC21819D6F4EC5F00AF7813B2F0355416F876A608EA4BA2708433BF7DA0E6118172AC63795C53B315B145DE8364F5AB3A6DB85DB6289CEDAE9ACA90F69857F9068DF112A4097A38EF96226AF3AA671E939DCD5BD27F266EB949FEF71DD12D020397CE1C681756379EDA3BC5CF7B758E5AE1445523DC8774A599A74FD020B7422E73BBDBC7946C0C8B5E39CCE3258046C98AF2D5431BD9BEC30EFF607E773261412F91D7CBADE5E8C6E26BDDA11F100F4E926582D8E0A9BCFD472BA33DD3E7505871C152890B852451597CDF31D4FB4DBD2AB43CEEB069EB6F2CFA
MyTrans : 034C0B2BDE9CB20D5BCA27312450DFD78889978758696EAD26A513B96AA757E344EE6BE9CBF1189534FAF035B5A91A61A18F297D75A4AA7F91114F52BF0F4D813ED23D9668930A2F51EFEA72E6F825DBA3E5CDC683C716A2C5326566F6CE9A0999B0E408F73A4336767B63D8AEAF221C33B7D479775A2C7EF98DBD3B5C8B8ED5B3E29DAB9E604098943C37B8C3C2530C17675473BB2DEBACBA4EC8ED2E428C8523381F82BE90F45E5D5F065604021B10D3304A9F156F9245FC8A6CA6E084054648F301E8F2FECFDC146249D6E74BECA89BC4DA21D07CBC80E1553FB6DD742012B46D411DD9712AC9FD19C00ED1F50739CC70B186597A1EC1A0280047FB6478FF

Gruß Hagen

negaH · Beiträge: 17

PS: die Patentrecherche hat weit lnger als 10 Minuten gedauert, diese 10 Minuten hat das einhämmern des obigen Sources gedauert

Übrigens kann man natürlich einen Angriff noch weiter optimieren. Zb. können wir uns den vorletzten Datenblock der die Zahl 255 enthält komplett entfernen, da wir ja durch die 255 vorhergehenden Datenblöcken ja schon 255 der 256 möglichen Einträge der Subst-Tabelle ermittelt haben. Das letzte fehlende Byte ergibt sich als logische Konzequenz, eg. per Ausschlußverfahren.

Aber das dürfte bei weitem nicht die letzt mögliche Optimierung gewesen sein.

Nach meiner Einschätzung gibt es nur zwei Erklärungen

a.) der Patentinhaber hat keine Ahnung von der Kryptographie (sorry aber grundlegende Aspekte wurden mißachtet und ich möchte weiß Gott keine Person hier beleidigen!)

b.) das Verfahren selber dient nur als "Kernpunkt" eines Verfahrens-Patentes, also nur um ein anerkanntes und triviales Allgemeingut zu patentieren. Es ist also eines der sogennaten Trivial-Patente zum Zwecke des Geldverdienens.

Gruß Hagen

uall@ogc · Verfasst: Sa 23.09.06 12:52

Wenn ich also abschließend mal zusammenfassen darf (ob ich es nun so richtig verstanden habe).
Man nehme ein unsicheres Verfahren (Vigenere Verschlüsselung).
Mit einem Passwort der Länge 1, kann z.b. durch Häufigkeitsanalyse diese Verschlüsselung ohne Probleme geknackt werden. Nun hat sich der Threadersteller (bzw der Freund) gedacht, man nimmt einfach ein langes Passwort (256 Zeichen), demnach müsste es schwieriger sein, den Code zu knacken. Die 256 Zeichen werden durch das Programm (und dem Passwort) selbst erstellt.

Schlussendlich ist aber die Sicherheit eines Verfahrens nicht durch die Kardinalität des Passwords festgelegt (in dem Fall 256!), sondern auf die Umkehrbarkeit des Algorithmusses.
Und mit dem Plaintext Verfahren geht das also schonmal ziemlich schnell.

(Hoffe das ist so richtig, wenn nicht korrigiert mich. Aber so ist es für andere einfacher zu verstehen)

Btw. das mit dem Patent ist klar. Aber irgendwie müssen die ja schauen ob sowas ähnliches nicht schon Patentiert ist und dafür müsste es ja jemanden geben der sich damit auskennt. Desweiteren müssten die Leute dort ja auch wissen, ob sowas überhaupt patentiert werden darf. Sonst kann ich mir ja auch irgend einen komplizierten Alg. ausdenken der einfach ein Textersetzungsverfahren ist und wenn ich das Patent habe, darf niemand mehr ein Programm schreiben was Teile eidnes Textes ersetzt.

Aber wenn das Patent erst angemeldet wurde und noch nicht gültig ist, wirds ja vielleicht noch geprüft.

_________________
wer andern eine grube gräbt hat ein grubengrabgerät
- oder einfach zu viel zeit

Quake User · Beiträge: 159

uall@ogc hat folgendes geschrieben:

...
Btw. das mit dem Patent ist klar. Aber irgendwie müssen die ja schauen ob sowas ähnliches nicht schon Patentiert ist und dafür müsste es ja jemanden geben der sich damit auskennt. Desweiteren müssten die Leute dort ja auch wissen, ob sowas überhaupt patentiert werden darf. Sonst kann ich mir ja auch irgend einen komplizierten Alg. ausdenken der einfach ein Textersetzungsverfahren ist und wenn ich das Patent habe, darf niemand mehr ein Programm schreiben was Teile eidnes Textes ersetzt.

Aber wenn das Patent erst angemeldet wurde und noch nicht gültig ist, wirds ja vielleicht noch geprüft.

Also richtig ist:
- es wird geprüft ob das, was patentiert wird neu ist
- dafür gibt es Patentprüfer, die sich sehr spezialisiert haben (meist auf 2 Themen)
- ob etwas funktioniert kann der Prüfer nicht prüfen. Wie soll er das tun?
- ob etwas patentiert werden darf, weiß der Prüfer natürlich
- eine öffentliche Meinung, ob etwas "GUT" ist steht dem Prüfer nicht zu
- es wird Nichts patentiert, was nicht eine gewisse erfinderische Höhe besitzt. Und hier kommen wir zum Kern. Eben das wird in diesem Thread bestritten.
- was soll dann aber dieses Patent nützen? Niemand wird ein Programm kaufen wenn die Technologie schlecht ist.
Ein Patent ist ein Schutzrecht, keine Qualitätsprüfung.

Was also durch uns zu klären währe ist,
1. ob das Verfahren WIRKLICH neu ist oder bspw. nur eine einfache, triviale Kombination aus anderen bekannten Verfahren
2. ob jeder Fachmann auch leicht auf eine solche Lösung kommen würde oder eine erhebliche geistige Leistung notwendig war.

jhart51 · Verfasst: So 24.09.06 22:43 Titel: Anmerkungen zum Angriff mit speziellen Daten

Die selbst gestellte Aufgabe ist perfekt gelöst.

Der Hintergrund der Überlegungen ist auch klar.

Aber ist es wirklich realistisch davon auszugehen, dass ein derartiger Angriff funktioniert.
Der Angreifer muss doch ziemlich tief in die "Intimsphäre" seines Opfers eindringen, um die
genannten Voraussetzungen zu schaffen. - Und mit der Einhaltung der Vorausstzungen lebt oder
stirbt ja der gesamte Algorithmus.

Wenn aber ein derartiger Angriff nicht funktioniert, wird die Kryptanalyse deutlich komplizierter.

Die Analyse der Häufigkeiten für die Ersetzung und das Suchen nach bekannten Mustern für die Vertauschung
schließen sich gewissermaßen gegenseitig aus. Um fehlende Ersetzungen zu ergänzen braucht man die
richtigen Vertauschungen - die richtigen Positionen der Bytes untereinander - und für das Erkennen
eines bekannten Musters fehlen die richtigen Ersetzungen.

Vertauschung und Ersetzung - besonders in Kombination - sind also meiner Meinung nach völlig zu
unrecht in Verruf geraten.

Dies erkannt zu haben und dann den Nutzer mit den beiden speziellen Tabellen zu belasten,
wäre aber keine Leistung.

Meine eigentliche Leistung sehe ich darin, dass ich einen Weg aufgezeigt habe, wie der Zugang zu diesen
Tabellen in der gesamten möglichen Vielfalt vom Nutzer sicher aufbewahrt bzw. versandt werden kann.
Es gibt abzählbar unendlich viele verschiedene Texte an denen abzählbar unendlich viele Veränderungen
vorgenommen werden können. Der Quellschlüssel könnte auch einen anderen Datentyp haben. Wichtig ist nur,
dass er absolut identisch reproduzierbar ist. Weil es keine Einschränkungen für den Quellschlüssel gibt,
besteht Anlass zu der Annahme, dass auch jeder ausführbare Schlüssel erreichbar ist.

Die eigentliche Ver- bzw. Entschlüsselung läuft erschreckend einfach ab.
Aber hierin sehe ich keinen Nach- sondern einen Vorteil.
Ein Fehler bei Übertragung einer verschlüsselten Datei ist nicht größer als ein gleichwertiger Fehler
bei der Übertagung der unverschlüsselten Datei. Bei anderen Verfahren sind die nachfolgenden Daten
häufig völlig unbrauchbar.
Erst kürzlich habe ich mal ein Projekt erzeugt was eine Datei von genau 1.0 GB erzeugt.
Für ein weiteres Projekt habe ich aus JHCode die Anweisungen herausgezogen, die diese Datei kopieren,
aber den Eingabepuffer direkt als Ausgabepuffer verwenden. Auch die Zeitmessung wurde übernommen.
Im Vergleich zu JHCode war dieses Projekt nur ca. 1 % schneller. Die Zeit für die Eingabe des
Schlüssels ist aus verständlichen Gründen nicht in der Zeitmessung von JHCode enthalten.

Gruß Jörg

negaH · Beiträge: 17

Hi Jörg,

du machst schlicht einen Fehler indem du unwesentliche Merkmale des Verfahrens als was Besonderes darstellst, aber die tatsächliche Sicherheit des Verfahrens in keinster Weise per math. Beweis untermauerst.

Zitat:

Aber ist es wirklich realistisch davon auszugehen, dass ein derartiger Angriff funktioniert.

Ja ist es. Siehe oben mein Angriff funktioniert, praktisch und in der realen Welt !! Reicht das nicht ? Du kannst nicht die reale Welt so zurechtbiegen das dein Verfahren dann sicherer wird, nein du musst dein Verfahren so ändern das es in der realen Welt sicher wird. Kannst du in deinem Beweis zur Sicherheit des Verfahrens einfach mal davon ausgehen das eine Chosen Plain Text Attacke absolut ausgeschlossen ist ? Nen, kannst du nicht ergo ist es deine Aufgabe das Verfahren an Hand aller bekannten Kryptoanalyseverfahren als sicher zu beweisen. Das machen alle anderen Konstukteure von Verschlüsselungen ja auch.

Zitat:

Wenn aber ein derartiger Angriff nicht funktioniert, wird die Kryptanalyse deutlich komplizierter.

Aha, dann beweise mir deine Aussage, bitte per zwingender Logik und mathem. Beweis und der so entstehenden Komplexität. Das ist deine Aufgabe, und vorher wird kein ernsthafter Anwender deinen Algo. benutzen.

Die obige Aussage ist nämlich falsch. Du kannst nicht diesen Angriff einfach "weg-denken" und nun hoffen das das Verfahren gegen alle anderen Kryptoanalysen resistent sein muß. Umgekehrt wird ein Schuh draus: wenn das Verfahren schon bei einem so simplen Angriff versagt wird es mit hoher Wahrscheinlichkeit auch bei wesentlich ausgefeilten, moderneren und komplexeren Angriffen versagen.

Zitat:

Die Analyse der Häufigkeiten für die Ersetzung und das Suchen nach bekannten Mustern für die Vertauschung
schließen sich gewissermaßen gegenseitig aus.

Wie kommst du darauf ? das ist falsch ! Gerade das die Entropie = Häufigkeiten der Symbole der Eingangsdaten direkt wiederzufinden sind in den Ausgangsdaten ermöglicht es den Kryptoanalytikern mit Hilfe der Häufigkeiten auch die Transpostions-Tabelle zu knacken.

Hast du meinen Code oben analysiert ? Ich ermittele auch erst nur die Substitutionstabelle und im 2. Schritt mit Hilfe der geknackten Tabelle die Transpositionen. Das geht auch zb. per Häufigkeitsanalyse.

Zitat:

Vertauschung und Ersetzung - besonders in Kombination - sind also meiner Meinung nach völlig zu
unrecht in Verruf geraten.

Wer behauptet denn sowas ? Kein ernsthafter Kryptograph käme auf diese Idee. Nein, das was heutzutage annerkannte Meinung ist ist das diese beiden simplen Techniken alleine benutzt nicht mehr ausreichen um einen sicheren Algo. zu konstruieren. Dh. aber nicht das moderne Verfahren auf diese Technologien verzichten wollen, warum auch ? Man lernt doch aus der Geschichte und benutzt dieses alte Wissen in Kombination mit neuem Wissen um was noch Besseres zu konstruieren.

Und exakt der Punkt das du eben nur simple Transpositionen und Substitutionen direkt mit Hilfe des Passwortes durchführst ermöglichte es mir, nach dem Begreifen was dein Verfahren macht, direkt zu erkennen das das Verfahren unsicher sein muß !!

Zitat:

Meine eigentliche Leistung sehe ich darin, dass ich einen Weg aufgezeigt habe, wie der Zugang zu diesen
Tabellen in der gesamten möglichen Vielfalt vom Nutzer sicher aufbewahrt bzw. versandt werden kann.

Ja, und der wäre ? Denn diesen Weg habe ich nicht im angehängten WinWord und auch nicht im veröffentlichten Patent so richtig verstanden oder nachvollziehen können. Worin besteht den nun dieser "Weg" und welche Vorteile bringt er gegenüber den bekannten Verfahren ?

Zitat:

Die eigentliche Ver- bzw. Entschlüsselung läuft erschreckend einfach ab.

Absolut kein Indiz für irgendwas. RC4 ist auch erschreckend einfach aber eben auch sicher. Das Verfahren sollte so einfach wie notwendig konstruiert sein, aber niemals so einfach das ein Anfänger, wie ich, es in par Minuten knacken kann.

Zitat:

Aber hierin sehe ich keinen Nach- sondern einen Vorteil.

Und welchen Vorteil siehst du denn ? Das man zwar ein einfaches Verfahren hat das aber dann absolut unsicher ist ?

Zitat:

Ein Fehler bei Übertragung einer verschlüsselten Datei ist nicht größer als ein gleichwertiger Fehler
bei der Übertagung der unverschlüsselten Datei. Bei anderen Verfahren sind die nachfolgenden Daten
häufig völlig unbrauchbar.

1.) stimmt diese Aussage nicht. Die meisten Verfahren sind sehr wohl selbstsynchronisierend.

2.) je nach Anwendungszweck möchte man eine Alles oder Nichts Verschlüsselung. Der Verlust der Selbstsynchronisation ist also in solchen Fällen absolut erwünscht, verhindert er doch effizient eine partielle Kryptoanalyse.

Es kann also, muß aber nicht von Vorteil sein wenn sich der Cipher selbstsynchronisieren kann. Übrigens ist für dieses Feature garnicht der Algo. ansich verantwortlich sondern der benutzte "äußere" Feedback Modus des Ciphers. Dieser ist universell und als inneren Kern lässt sich jeder sicherer Blockcipher einsetzten.

Desweiteren kommt es in deinem Verfahren nur auf Grund dessen das die Entropie der PlainText Naschricht identisch mit der Entropie der CipherText ist zu einer Selbstsynchronisation. Du benutzt also zur Argumentation eines Vorteils des Verfahrens einen eklatanten Sicherheitsfehlers des Verfahrens. Anders ausgedrückt: weil das Verfahren auf der einen Seite unsicher ist ergibt sich auf der anderen Seite der Vorteil der Selbstsynchronisation. Aber welche dieser beiden Eigenschaften ist die wichtigere ?

Schlußendlich: Ich behaupte das ich den Cipher auch
1.) per Known Plain Text Attack, also ohne Passwort aber mit teilweise bekannten PlainText
2.) per differentieller Kryptoanalyse, also 2 Nachrichten werden mit einem leichten Unterschied (Tippfehler) verschlüsselt und man knackt nur auf Basis der 2 abgefangenen CipherText Nachrichten, ohne Passswort und ohne PlainText, nur mit dem Wissen das man sich bei 1 Buchstabe vertippt hat. Übrigens schon im 2.WK entwickelt.
3.) nur durch Häufigkeitsanalyse
4.) durch Cipherblock Ersetzungen eine verschlüsselte Nachricht manipulieren kann. Dh. man hat x Nachrichten abgefangen, kennt grob den inneren Aufbau der PLainText Nachricht (zb. Banküberweisungen) und mit geschicktem Austauschen von Blöcken innerhalb dieser Nachrichten die Banküberweisung so manipulieren kann das der neue Empfänger zb. ich selber bin,

knacken kann. Ich kenne also noch mindestens 4 Angriffe die ich als realistisch erachte.

Gruß Hagen

F34r0fTh3D4rk · Verfasst: Mo 25.09.06 10:23

naja selbst wenn das mit dem patent was wird, werden sich die leute net drum reißen den algo zu benutzen, wenn er denn nichts taugt. hättest du vorm antrag hier gepostet, wäre es vermutlich besser gewesen.

mfg

negaH · Beiträge: 17

Beispiel:

TEA ist ein Cipher der sehr simpel ist und weit sicherer als dein Verfahren sein wird. Hier mal ein Source

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

  Sum := 0;
  X := PlainText.UInt64.Lo;
  Y := PlainText.UInt64.Hi;
  K := Cipher.State.Key;
  for I := 0 to Cipher.State.Rounds -1 do
  begin
    Inc(X, (Y shl 4 xor Y shr 5) + (Y xor Sum) + K[Sum and 3]);
    Inc(Sum, TEA_Delta);
    Inc(Y, (X shl 4 xor X shr 5) + (X xor Sum) + K[Sum shr 11 and 3]);
  end;
  CipherText.UInt64.Lo := X;
  CipherText.UInt64.Hi := Y;

Und TEA ist noch längst nicht so sicher wie anerkannte Verfahren wie AES,IDEA zb.

Gruß Hagen

negaH · Beiträge: 17

Zitat:

naja selbst wenn das mit dem patent was wird, werden sich die leute net drum reißen den algo zu benutzen, wenn er denn nichts taugt. hättest du vorm antrag hier gepostet, wäre es vermutlich besser gewesen.

Darum gehts doch garnicht. Meiner Menung nach deckt das Patent gleich 2 Ansprüche ab:

1.) das Verschl. Verfahren ansich als Haupt-anspruch, und dieser ist hinfällig weil unsicher, bzw. kein Mensch wird sowas benutzen wollen.

2.) den verklausulierten und nachgeschobenen Neben-anspruch der eine spezielle Form der Schlüsselaufbereitung abdeckt. So wie ich das erkennen konnte handelt es sich um eine simple 2-Faktor-Verschlüsselung. Das ist schon längst anerkanntes Allgemeingut und im Grunde nicht patentierbar. Es sei denn man bekommt auf Grund der "fachlichen Inkompetenz" des Patentamtes ein solches Patent durchgedrückt. Dieses Patent wird damit zum Trivial-Patent und defakto alle Mehr-Faktor-Verfahren müssten Lizensen erwerben.

Gruß Hagen

F34r0fTh3D4rk · Verfasst: Mo 25.09.06 11:03

ich sagte ja deshalb auch

Zitat:

naja selbst wenn das mit dem patent was wird, werden sich die leute net drum reißen den algo zu benutzen, wenn er denn nichts taugt. hättest du vorm antrag hier gepostet, wäre es vermutlich besser gewesen.

negaH · Beiträge: 17

darum geht es aber garnicht.

Millionen von Menschen nutzen schon heute Verfahren die in diesem Patent abgedeckt würden. Das ist Allgemeingut. Schafft man es ein solches Patent durchzudrücken so hat man quasi unterm *popo* weg ein Wissen patentiert das schon längst frei benutzt wird. Der Patentinhaber hat aber das juristische Recht nun von alle diesen Nutzern Lizensen verlangen zu können.

Schaffe ich es den Vorgang des Urinierens zu patentieren dann habe ich das juristische Recht für die nächsten 20 Jahre von allen die urinieren wollen eine Lizens verlangen zu können. Das sind die Auswirkungen der Trivial-Patente und das Ziel ist es immer schnell Geld zu verdienen und NICHT neues Wissen schützen zu lassen.
Der Schutz von neuen Wissen damit derjenige der es erdacht hat auch davon profitieren kann, also der Sinn von Patenten, wird damit absolut ins Gegenteil verkehrt.

Also auch wenn KEINER dieses Patent nutzen möchte, so deckte dieses Patent schon Verfahren der realen Welt ab die tagtäglich benutzt werden. Ergo: der Patentinhaber hat das Recht dafür Geld verlangen zu können.

Allerdings möchte ich hiermit darauf hinweisen das ICH nicht der Ansicht bin das der Patentinhaber dieses Ziel mit seinem Patent verfolgt hat !!
Ich gehe eher davon aus das der Patentinhaber lange an seiner Idee gefeilt hat und so überzeugt von seiner Erfindung war das er sie patentieren ließ. Das macht Sinn und ich würde auch so vorgehen wollen, ändert aber nichts an der Sache das das eingereichte Verfahren auf Grund fehlender Analysen und Beweise denoch unsicher ist. Diesen "Fehler" erachte ich als nur allzu menschlich.

Um so deutlicher wird der Gedanke das in der Kryptographie nur dann ein Verfahren annerkannt sicher gelten kann, wenn sich unabhängig voneinander eine große Gruppe von Kryptograühen und Kryptoanalytikern über das Verfahren hergemacht haben, und es nicht geschafft haben es zu knacken !

Aber zur Anmeldung eines Patentes benötigt man sowas im Grunde nicht.

Gruß Hagen

F34r0fTh3D4rk · Verfasst: Mo 25.09.06 11:19

aber er patentiert damit doch nur diese kombination bekannter verfahren oder net ?
angenommen ich lasse mir folgendes patentieren:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

function bla(astr: string): string;
var
  a, b: integer;
begin
  a := 5;
  b := 15;
  result := astr + inttostr(a + b);
end;

dann kann ich ja auch net von leuten geld verlangen die inttostr benutzen, zugegeben schlechtes beispiel, aber in einem größeren rahmen doch denkbar, oder nicht ?

negaH · Beiträge: 17

Nein tut er nicht.

Das gemeine an Trivial-Patenten ist es das man quasi eine neuartige "Maschine" als was reales patentiert und direkt an diese Neuerung als notwendige Bedingung damit sie funktioniert eben Trivial-Wissen als Neben-anspruch mitpatentiert. Das ist laut Patentrecht durchaus möglich und das Patentamt hat nicht die Pflicht daraufhin zu prüfen. Man bekommt also immer erstmal ein solches Patent (natürlich gut und juristisch ausformuliert) durchgesetzt. Erst nachdem man dieses Patent innehat setzt der jruristische Rechtsstreit sich in Gang. Denn wenn der Patentinhaber nun sein Patent gegen Dritte durchzusetzen versucht hat diese dritte Partei natürlich das Recht Klage dagegen zu erheben. Logischerweise benötigt man dazu auch einen finanziellen Background, den die meisten Menschen garnicht haben. Wird aber nicht geklagt so gilt der jruistische Anspruch des Patentinhabers und die dritte Partei muß zahlen !

Das Patentamt überprüft nur zwei Dinge

1.) korrekte Form der Patentschrift, und diese Form ist sehr weit gefasst. Man kann fast ohne jegliche Form ein Patent beantragen.
2.) ob der Hauptanspruch des Patentes schon patentiert wurde. Allerdings muß man hier wissen das das Patentamt heutzutage garnicht mehr in der Lage ist, aus "fachlicher Inkompetenz" oder Mangels von Manpower und Zeit, dies exakt zu überprüfen.

Es liegt also eher in der Hand des Patentinhabers entsprechende Anwälte auf Patentrecherche zu schicken und eventuell andere Ansprüche zu berücksichtigen. Einfach weil ein Patent eben Geld kostet und man verhindern möchte das man dieses Geld zum Fenster hinaus wirft. Denn sollte es ein älteres Patent geben das den gleichen Anspruch erhebt so wird das eigene Patent autom. hinfällig. Das investierte Geld ist also futsch.

Gruß Hagen

PS: dies war und ist keine juristische Belehrung nach dem derzeitig noch gültigen Rechtsberatungsgesetz Abs. 1 und erhebt keinen Anspruch auf Vollständigkeit noch Richtigkeit. Für eine sachkundige Beratung empfehle ich dringenst sich an einen eingetragenen Patentanwalt zu wenden !!

Quake User · Beiträge: 159

F34r0fTh3D4rk hat folgendes geschrieben:

naja selbst wenn das mit dem patent was wird, werden sich die leute net drum reißen den algo zu benutzen, wenn er denn nichts taugt. hättest du vorm antrag hier gepostet, wäre es vermutlich besser gewesen.

mfg

Nein, währe es nicht. Wenn Du erst veröffentlichst, ist es Allgemeinwissen und nicht mehr patentierbar.

negaH · Beiträge: 17

Nochwas ist mir aufgefallen.

Der propagierte Schlüsselraum von 256!^2 ist ebenfalls falsch. Defakto ist der Schlüsselraum nur 256! groß. Denn wenn wir davon ausgehen das er 256!^2 ist und wir die sich ergebende Sicherheit eines abgeschwächten Systemes errechnen dann ergäbe ist nur 256!.

Dazu muß ich ein bischen tiefer gehen:

Ein sicheres System wird oft Kryptoanalysiert indem man zu Testzwecken das verwendete System abschwächt und dann schaut welche Sicherheitsschranken sich ergeben.

In unserem Falle schwächen wir das System indem wir die ersten 256 Bytes des Schlüssels vorgeben und die restlichen 256 Bytes aber nicht kennen. Also wir kennen die Trans oder Subst Tabelle aber nicht den Rest.

Hm, wie oben in meinem Angriff schön zu sehen kann man dann den restlichen Schlüssel mithilfe eines Datensatzes aus den Bytes 0 bis 255 auf direktem Wege knacken.

Das heist: die Schlüsselgröße deckt einen hypothetischen Schlüsselraum von 256!^2 ab, aber der effektiv sichere Schlüsselraum ist nur 256!.

Das bedeutet das eine Brute Force Attacke, also das druchprobieren der Schlüssel defakto nur den oberen oder unteren 256 Bytes des Passwortes knacken muß um die restlichen 256 Bytes auf direktem Wege berechnen zu können.

Jetzt könnte man argumentieren -> 256! ist ja immer noch eine rießige Menge und wir verstecken uns hintr dieser großen Zahl und nehmen mal an das wäre sicher. Falsch gedacht, so geht ein Kryptograph niemals vor !!

Denn ALLE als sicher anerkannten Verfahren benutzten immer ALLE Bits eines Schlüssels und bleiben denoch sicher. Selbst wenn man ein par Bits davon kennt.

Ein Verfahren das das mögliche Set aller Schlüssel -> eg. Schlüsselraum, nicht vollständig ausnutzen kann, weil es ansonsten direkt knackbar sein würde, ist demzufolge von schlechter Qualität.

Übrigens dürfte es egal sein welche der 256 Bytes in den Tabellen bekannt sind, wichtig ist nur das der Index dieser bekannten Bytes sich nicht überschneidet. Man könnte also auch nur 128 bytes von Trans und 128 Bytes von Subst kennen und könnte den Rest direkt berechnen.

Deshalb gilt: man muß einen 256!^2 Schlüsselraum benutzen aber dieser wird nur mit 256! effektiv sicher sein. Man hat somit 256 Bytes von den 512 Bytes an Keymaterial sinnlos verschenkt.

Gruß Hagen

negaH · Beiträge: 17

Praktisch bedeutet dies für das Verfahren das man mit einem nur 256 Bytes großen Schlüssel und einer geschickten Schlüsselableitungsfunktion beide internen Tabellen berechnen könnte, und dann dieses neue Verfahren immer noch so sicher wäre wie das alte. Aber eben mit dem Unterschied das man nun nur noch einen 256 Bytes Schlüssel benötigen würde.

Dreh und Angelpunkt ist dann aber die Schlüssel-ableitungs-funktion, denn man muß beweisen können das sie sicher ist und auch wirklich alle Schlüsselbits gleichverteilt und nicht invertierbar in die beiden Tabellen gemappt werden.

Nun betrachten wir diese 256! die sich als Schlüsselraum eines 256 Bytes Passwortes ergeben. Oben habe ich schon mal 256! als Zahl gepostet. Diese Zahl ist ca. 1684 Bits groß. Umgerechnet heist dies also das 256! rund 2^1684 ist. Unser Schlüssel ist 256 Bytes = 2048 Bits groß und demzufolge wäre mit so einem Schlüssel ein effektiver und maximaler Schlüsselraum von 2^2048 möglich.

Wir sehen auch hier das das Verfahren das zur Verfügung stehende Keymaterial nicht vollständig ausnutzt und so wertvolle Schlüsselbits nicht in Sicherheit umrechnen kann.

Dh. heist wir benötigen 2^2048 um eine effektive Sicherheit von nur 2^1684 erreichen zu können. Das können alle heutigen Verfahren weitaus besser. Ich kenne eigentlich nur die DES Verschlüsselung als einzigstes Verfharen das eine ähnliche Reduktion des effektiven Schlüsselraumes durchführt.

2^2048 / 2^1684 == 2^364 ==

37576 68132 43813 31646 23168 95486 29392 43801 09207 82533 11793 13166 55544 51534 44018 33735 09541 91839 74156 29924 85109 59616

das ist eine so gewaltige Zahl, immerhin gilt schon eine gute 128 Bit Verschlüsselung als sicher !

Fazit: die Indizien häufen sich und je mehr man das Verfaren analysiert desto mehr Indizien und Beweise wird man für dessen Unsicherheit finden.

Aus einer maximal möglichen Sicherheit von 2^4096 wird durch simple Analyse eine effektive Sicherheit von nur noch 2^1684. Man hat also über 58% des Keymaterials verschenkt. Und das betrifft ja nur rechnerisch die ausgenutzte Komplexität des Schlüsselraumes und noch längst nicht die sich reale ergebende Komplexität auf Grund des verwendeten Algorithmus.

Gruß Hagen

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme