Okay, hab meinen verschlüsselungsalgorithmus(TEA3), aber entschlüsseln... ?

lk

TEA2 ist unsicher, das weis ich. Man kann nach der heufigkeit der differenzen von ciphertext[i+1] - ciphertext die buchstaben ableiten. zB bei großen detuschen texten wäre das heufigste das 'e'. Ansonnsten ist die wertedistribution im ciphertext recht OK (wenn man eben nur eizelne werte betrachtet). Ich hab mir langgierige wiedererklärungen gespart und den verweis "basieren auf .." angegeben, wo 2D TEA2 beschreiben wird. Dasselbe auf 3D TEA3 zu imaginieren sollte auch echt einfach sein.

...Also hab ich einen XOR schritt inmitten eingefügt, womit die 'e'-cryptanalisys wertlos sein sollte. Ich hatte angst man könne dan hinter den schlüssel kommen also hab ich die tabelle um eine weitere dimension erweitert --> 3D; und um noch einen schritt, der das XOR mit der tabelle verstecken sollte.
Da XOR absolut sicher ist (siehe unten fürs zitat), sollte mein algorithmus unbrechbar sein. Jetzt verstecke ich das XOR.

Warum das arbeiten mit einem sudoku-würfel gut ist:
Bei einer 1D "linie" (256byte key) gibt es einen "weg".
D.h., dass es für jeden Wert im plaintext genau ein substitutions-wert gibt:
Simple 1D replace verschlüsselung (1-weg): ciphertext[i] := key[ plaintext[i] ]
Nun habe ich das auf 2-weg 2D (--> TEA2) erweitert. Jetzt wirds spannend. Zuerst wird aus den 256 1-wegen einer ausgewählt (x). Nun wird aus dem vorher verschlüsseltem der 2-weg ausgewählt. Hierbei sollte man beachten: Die ~~tabelle~~ würfel ist sudoku-artich organisiert, und jeder neue "weg" öffnet eine neue spanne an zufällig sortierten 0..255 werten, die überhaupt nicht voneinander anhängen. Die Aufwendigkeit steigert sich also mit jedem wert um das 256-fache. Nach dem auswählen des 2. weges wird sich dem vorher verschlüsseltem wert bedient ( ciphertext[i-1] ). So baut sich nicht nur ein multiple-way verfahren auf, sondern auch ein "stream"; jeder nächste zu verschlüsselnde wert basiert zu 100%^(!) auf dem davor. 3-wege verschlüsselung wird auch zuerst der 1. weg ausgewählt (x), das ist der plaintext[i] . Jetzt wird der zweite weg ausgewählt, das ist wie beim obsolete 2D verfahren der [c]ciphertext[i-1][c], somit hat das schonmal die wie vorherangegebenen stream- und multiple-way eigenschaften. (Leider kann man es wegen der stream eigenschaft mittels der 'e'-cryptanalyse cracken. Im dritten weg der vom zweiten schritt abhängig ist wird dies versteckt). Nun endlich im dritten weg (z) wird die dritte Dimension des Würfels benutzt, dH aufwendigkeit=256^3. Der dritte weg ist einfach nochmal eine erweiterung des weges. Ermittelt durch das resultat aus dem 2. (xor-) schritt. Hier wird nochmal die zufälligkeitseigenschaft betont (wegen XOR), die stream eigenschaft betont und uncryptanalisabel gemacht. Multiple-way ist besonders stark da XOR ein perfektes resutat liefert, und wie schon gesagt jeder nächste weg den vorherigen nochmal mit 100%-security überschreibt; und dieser ist das perfekte ergebnis von XOR also sollte das uncrackbar sein. (z=xord[i-1]). Dazu, wie man sehen kann, wird auf dem buchstaben vom vorherigen buchstaben zugegriffen, also nochmal streameigenschaft betont.

Wikipedia schrieb:

With a key that is truly random*****, the result is a one-time pad, which is unbreakable even in theory.

***** Irgendwie musste ich ja der XOR schritt realisieren, also nehme ich einfach die bytes der tabelle, die ja leider bisschen geordnet sind. Das ist nur ein prototyp, und wird sich ändern. Wie man XOR entschlüsselt weis ich sehr gut und irgendwas wird mir einfallen, das ist nicht das thema; der 3. schritt, TEA3 (3D) ists.

> http://en.wikipedia.org/wiki/XOR_Cipher

Das einzige, wo man diesen algorithmus noch angreifen kann ist der sudokuartige aufbau des würfels.

PS: Wenn ihr wollt kann ich ein "paper" in latex schreiben und es hier veröffentlichen... deutsch oder Englisch?

SeppJ

Ich habe eine tolle Idee für dich: Da du ja schon weißt, dass XOR bei hinreichend großer Schlüssellänge (und zufälligem Schlüssel! Dein Schlüssel ist nicht zufällig!) unbrechbar ist, warum nutzt du dann nicht XOR? Ach ja, ist praxisuntauglich, weil der Schlüssel so lang ist. Hmm, worum geht's bei deinem Algorithmus noch mal?

lk

SeppJ schrieb:

Ich habe eine tolle Idee für dich: Da du ja schon weißt, dass XOR bei hinreichend großer Schlüssellänge..

16MB sollten praxistauglich sein. Das ändert sich auch noch.

SeppJ schrieb:

(und zufälligem Schlüssel! Dein Schlüssel ist nicht zufällig!)

Nicht ganz. Wie schon erwähnt weis ich das, der XOR-teil ist gröstenteils nur ein prototyp.

SeppJ schrieb:

..unbrechbar ist, warum nutzt du dann nicht XOR?

Hä, tu ich doch?

SeppJ schrieb:

Ach ja, ist praxisuntauglich, weil der Schlüssel so lang ist.

Ja, der schlüssel ist lang. Was ich am meisten bei anderen programmieren hasse, ist dass sie alle etwas unbedingt verlangen dass man es so umbendingt machen solle. ist aber jetzt sowas, dass das eher meine sache ist! Vielleicht wollte ich ja auch "key extensioning" machen, wie dies bei AES der fall ist, also aus einem kleinem schlüssel mehrere varienten abbilden. Aber dann verschwende ich möglichkeit also lass ich das 16MB-verfahren auf jeden fall auch in ruhe.
Also: Das ist schon meine sache, ehrlich! Bitte!

SeppJ schrieb:

Hmm, worum geht's bei deinem Algorithmus noch mal?

Darf ich dich jetzt trollen, ja?

Christoph

lk schrieb:

Das einzige, wo man diesen algorithmus noch angreifen kann ist der sudokuartige aufbau des würfels.

Da dein Key im allgemeinen deutlich kleiner ist als der Plaintext und Ciphertext, wird es höchstwahrscheinlich auch andere Angriffsmethoden geben. XOR ist nur dann theoretisch sicher, wenn der Key völlig zufällig generiert wurde und genauso lang ist wie die Nachricht. Das ist bei dir nicht der Fall, egal wie man es dreht und wendet. XOR kann bestimmte Angriffe natürlich trotzdem erschweren oder unmöglich machen (unter gewissen Annahmen). Aber die Analyse deines Algorithmus ist halt viel schwieriger.

Da du im Mathe-Forum schreibst, denke ich doch, dass du eine mathematische Analyse machen möchtest. Sätze wie "Dazu, wie man sehen kann, wird auf dem buchstaben vom vorherigen buchstaben zugegriffen, also nochmal streameigenschaft betont" sind nicht mathematisch, das ist Marketing-Sprache. Was bedeutet es mathematisch, die Streameigenschaft zu betonen? Gegen welche Angriffe schützt das?

Es ist sicher eine gute Übung einen Algorithmus zu schreiben, der einen Text unleserlich macht und wieder zurückwandeln kann. Aber das dann "Verschlüsselung" zu nennen, das ist seit Erfindung der modernen Kryptografie halt sehr schwierig geworden, deswegen stößt du auf so viel Widerstand.

SeppJ

lk schrieb:

SeppJ schrieb:

Hmm, worum geht's bei deinem Algorithmus noch mal?

Darf ich dich jetzt trollen, ja?

Du verstehst noch nicht einmal die Einwände von jemandem der mal ein paar Buchkapitel und ein paar Wikipediaseiten gelesen hat. Ich wollte dir was wichtiges sagen über deinen Algorithmus, aber du schmetterst es einfach ohne Nachzudenken ab, weil du nicht verstehst, worauf ich hinaus wollte. Und wenn das schon bei Einwänden von Laien der Fall ist, dann ist dir einfach nicht zu helfen.

-lowbyte- 0

lk schrieb:

SeppJ schrieb:
..unbrechbar ist, warum nutzt du dann nicht XOR?

Hä, tu ich doch?

Nein! Du machst dies mit ganz falschen Vorstellungen. Was Du hier machst kannst Du in keinem Fall mit XOR oder einem One-Time-Pad vergleichen! Das One-Time-Pad gehört zu den polyalphabetischen Substitutionsverfahren, und ist nur dann sicher wenn der Schlüssel wie schon erwähnt wirklich zufällig ist, und danach auch verworfen wird (sonnst ist er durch Differentielle Kryptoanalyse zu brechen). Zudem hat ein OTP nicht wirklich etwas mit einem symmetric Cipher zu tun. Zudem ist dein Schlüssel viel zu gross. 16Mb das ist ja Wahnsinn und völlig unbrauchbar. Denn stell Dir mal vor du müsstest 1000 key's Speicher... doch völlig verrückt oder!? Nein so kannst Du dass auf keinen Fall machen. Wie willst Du Denn Schlüssel generieren? Denn Du hast ja kein Key-expansion!
Zudem..hast du schon-mal die Geschwindigkeit gemessen? Denn ich habe noch kein Cipher gesehen der so unperformant ist wie Deiner. Warum allozierst Du zur Laufzeit dynamisch Speicher? Und dass in einem Cipher? Langsam^10.
Sorry mein lieber aber so haut das nicht! Wenn du eines Tages wirklich einen Cipher entwickeln möchtes dann folge unserem Rat, und meinem Punkt.5 in meinem letzten Post.
Mehr will ich jetzt auch gar nicht mehr schreiben denn es bringt nichts.

-lowbyte- 0

Noch etwas...
Soein Cipher zu entwickeln benötigt sicher mehrere Monate, und nicht nur ein paar Programmierstündchen...

314159265358979

Pseudocode:
srand(key);
for(jedes zeichen)
zeichen += rand();

Mein Algorithmus, entwickelt in 5 Sekunden.

Rhombicosidodecahedron

@lk
Ich habe mir vielleicht zu viele Gedanken gemacht, aber ...

Die Implementierung:

Abgesehen, dass es nach der Implementierung bislang nur 172 800 unterschiedliche Tabellen generiert werden konnten (sie basiert ja auf srand und rand und daher pro Sekunde eine Schlüssel) und der peinlichen Implementierung sowohl des shuffle Algorithmus-es bei der Tabellenerstellung als auch dessen Anwendung, lässt sich die Verschlüsselung vermutlich sehr stark zusammenfassen:

int tea_encrypt_tea2tra_rawxor_tea3(tab_t table, byte* out, int count, byte* in)
{
    int last = 0, current = 0, i = 0;

    for (; i<count; i++)
    {
        current = table[tea_resolve(in[ i], last, 0)];
        out[ i] = table[tea_resolve(in[ i], last, table[i%256*256*256] ^ current)];   
        last = current;
    }

    return count;
}
// nicht getestet, sollte aber so stimmen.

Und noch einem weiteren Fehler, dessen Tragweite ich nicht abschätzen kann, der aber sichtbar wird, wenn man mehrere 10000 male das gleiche Zeichen verschlüsselt.

Tabellengenerierung und somit Ver- und Entschlüsselung

Vereinfacht sei der Würfel auf eine Kantenlänge von 4 vereinfacht mit nur einer Runde.
Und vom Ausgangspunkt:

x[e]rarr[/e]
y z
[e]darr[/e]
z = 0:    z = 1:    z = 2:    z = 3:
0 1 2 3   1 2 3 0   2 3 0 1   3 0 1 2
1 2 3 0   2 3 0 1   3 0 1 2   0 1 2 3
2 3 0 1   3 0 1 2   0 1 2 3   1 2 3 0
3 0 1 2   0 1 2 3   1 2 3 0   2 3 0 1

Nachdem x(0, 1) vertauscht wird:

z = 0:    z = 1:    z = 2:    z = 3
1 0 2 3   2 1 3 0   3 2 0 1   0 3 1 2
2 1 3 0   3 2 0 1   0 3 1 2   1 0 2 3
3 2 0 1   0 3 1 2   1 0 2 3   2 1 3 0
0 3 1 2   1 0 2 3   2 1 0 3   3 2 0 1

Nachdem y(0, 1) vertauscht wird:

z = 0:    z = 1:    z = 2:    z = 3
2 1 3 0   3 2 0 1   0 3 1 2   1 0 2 3
1 0 2 3   2 1 3 0   3 2 0 1   0 3 1 2
3 2 0 1   0 3 1 2   1 0 2 3   2 1 3 0
0 3 1 2   1 0 2 3   2 1 0 3   3 2 0 1

Nachdem z(0, 1) vertauscht wird:

z = 1:    z = 0:    z = 2:    z = 3
2 1 3 0   3 2 0 1   0 3 1 2   1 0 2 3
1 0 2 3   2 1 3 0   3 2 0 1   0 3 1 2
3 2 0 1   0 3 1 2   1 0 2 3   2 1 3 0
0 3 1 2   1 0 2 3   2 1 0 3   3 2 0 1

Nun wird jeweils ei Zeichen 0 1 2 3 verschlüsselt.

in:                                             0 1 2 3
tea_encrypt_tea2tra: tra = table[in,0,0]     :  3 2 0 1
tea_encrypt_rawxor:  xor = table[0,0,0] ^ tra:  0 1 3 2
tea_encrypt_tea3:    out = table[in, 0, xor ]:  3 1 2 2

Ergebnis: Tolle Verschlüsselung
Für meinen Fall kann also keine eindeutige Verschlüsselung existieren. Bei mehr Zeichen setzt sich der Fehler fort und nach einigen Zeichen ist wohl jeder Geheimtext denkbar.
~~Wahrscheinlich~~ für tea3 ebenso~~. Müsste man mal durchtesten.~~
Ergebnisse für srand(0) und #define TABGEN_PASSES 256 auf Win7x64:

0 => 2F   1 => 63   2 => 2F   3 => 62   4 => F9   5 => 65   6 => EE   7 => 79
 8 => 36   9 => 18   A => 4E   B => 2A   C => 3A   D => E3   E => F9   F => 79
10 => EC  11 =>  1  12 => 1B  13 => 19  14 => 61  15 => C7  16 => 58  17 => F9
18 => D2  19 => 69  1A => 98  1B => 4E  1C => 99  1D => 51  1E => 8E  1F => 9C
20 => 66  21 => 16  22 => AC  23 => 4A  24 => 83  25 => 99  26 => A0  27 => 65
28 => D4  29 => 25  2A => 19  2B => A2  2C => B1  2D => 93  2E => 52  2F => FD
30 => F4  31 => 2F  32 => 79  33 => 29  34 => 19  35 => 99  36 => 22  37 => E8
38 => 5B  39 => DA  3A => CA  3B => 99  3C => 78  3D => 73  3E => 14  3F => D6
40 => 25  41 =>  C  42 => 19  43 => BD  44 => DD  45 =>  C  46 => 6F  47 => D5
48 => ED  49 => 50  4A => 25  4B => 5D  4C => 79  4D => 23  4E => B8  4F => 37
50 => 5D  51 => 40  52 => 26  53 => BC  54 => F3  55 => 67  56 =>  E  57 => B0
58 => 79  59 => 43  5A => D9  5B => 99  5C => 9E  5D => 10  5E => 7B  5F => 61
60 => A7  61 => 3F  62 => D4  63 => AA  64 => ED  65 => EF  66 => 2E  67 => 15
68 => 34  69 => BA  6A => 12  6B => 19  6C => 81  6D => C4  6E => 2A  6F => 79
70 => 22  71 => 1E  72 =>  C  73 =>  C  74 => 84  75 => F7  76 =>  7  77 => 7A
78 => 30  79 => 75  7A =>  4  7B => EC  7C => E6  7D => 80  7E => 43  7F => 6F
80 => DD  81 => F4  82 => FD  83 => 2A  84 => 25  85 => 63  86 => 53  87 => B9
88 => CF  89 => 6B  8A => 87  8B => 80  8C => FC  8D => F9  8E => 9E  8F => C7
90 => 19  91 => 56  92 => 79  93 => F3  94 => FB  95 => F7  96 => 56  97 =>  2
98 => 7A  99 => EF  9A => AF  9B => 25  9C => A3  9D => 79  9E => 5C  9F => DB
A0 => 28  A1 => 89  A2 => F9  A3 => 18  A4 => 19  A5 => C5  A6 => 32  A7 => 58
A8 => DC  A9 => 5E  AA => 3B  AB =>  0  AC => 2A  AD => 19  AE => 19  AF => 11
B0 => 14  B1 => 6B  B2 => AD  B3 => 91  B4 => 88  B5 => D9  B6 => AD  B7 => E7
B8 => CC  B9 => AC  BA => 39  BB => 98  BC => 99  BD => 1C  BE => 19  BF => B4
C0 => C9  C1 => D8  C2 => 52  C3 => D7  C4 => 75  C5 => BC  C6 => 14  C7 => 80
C8 => 43  C9 => E1  CA => BE  CB => FB  CC => DF  CD => 8A  CE => 90  CF => ED
D0 => 26  D1 => 31  D2 => 29  D3 => F9  D4 => 6D  D5 => 5C  D6 => 66  D7 => D5
D8 =>  A  D9 => 5D  DA => 63  DB => F5  DC => 70  DD => 12  DE => CA  DF => BF
E0 => 19  E1 => EB  E2 => 1F  E3 =>  D  E4 => F0  E5 => 9E  E6 => 68  E7 => 1F
E8 => 17  E9 => 7F  EA => 62  EB => 47  EC => E5  ED =>  3  EE => 19  EF => 54
F0 => F9  F1 => 55  F2 => AD  F3 => B8  F4 => 19  F5 => F9  F6 => B3  F7 => 99
F8 => 3C  F9 => 13  FA => 40  FB => 79  FC => FE  FD => F9  FE => CA  FF => 29

Ich programmiere nicht andauernd in C und möchte diesen Chat nicht hijacken, aber warum schließt du den outfile Stream in deinen Methoden, wenn sie ihn gar nicht öffnen???

P.S.: Weißt du was Trisectors sind?

@314159265358979: Warum nicht xor?

Edit 1: Forumsyntaxhighlighting reagiert alergisch auf [i] in c++ code und Einrückung verbessert

314159265358979