Okay, hab meinen verschlüsselungsalgorithmus(TEA3), aber entschlüsseln... ?
-
Noch etwas...
Soein Cipher zu entwickeln benötigt sicher mehrere Monate, und nicht nur ein paar Programmierstündchen...
-
Pseudocode:
srand(key);
for(jedes zeichen)
zeichen += rand();Mein Algorithmus, entwickelt in 5 Sekunden.
-
@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
undrand
und daher pro Sekunde eine Schlüssel) und der peinlichen Implementierung sowohl desshuffle
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.
Wahrscheinlichfürtea3
ebenso~~. Müsste man mal durchtesten.~~
Ergebnisse fürsrand(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
-
Rhombicosidodecahedron schrieb:
@314159265358979: Warum nicht xor?
Weils dann kein 5-Sekunden-Algortihmus sondern ein 10-Sekunden Algortihmus wäre.
-
Rhombicosidodecahedron schrieb:
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), ...
???
Rhombicosidodecahedron schrieb:
und der peinlichen Implementierung
Rhombicosidodecahedron schrieb:
sowohl des shuffle Algorithmus-es bei der Tabellenerstellung als auch dessen Anwendung, lässt sich die Verschlüsselung vermutlich sehr stark zusammenfassen: ...
Ja sollte stimmen.
Warum eigentlich "sehr stark"?
Ist ja fast alles, was man zum algorithmus wissen muss. sonst nurnoch den aufbau des würfels.Rhombicosidodecahedron schrieb:
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.
Ouch, ja ich sehes. Wenn man i beim XOR schritt nicht nur chunk-local aber global übers ganze verschlüsseln geben sollte, sollte der dritte schritt es noch weiter verziehen und alles sollte wieder wunderbar sein. wie schon gesagt der XOR teil ist nur prototyp.
Rhombicosidodecahedron schrieb:
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: ...Habs nicht wirklich gecheckt... Machst du TEA2 oder TEA3? (TEA2 ist nur die funktion tea_encrypt_tea2tra, ohne die zwei anderen.).
Wenn jeder mögliche Geheimtext denkbar ist, wieso kann ich TEA2 fehlerlos ver-und entschlüsseln? (um TEA3 entschlüsselung gehts ja hier).
Ich versteh nicht wirklich wozu die zufallszahlen da sind, sorry...Rhombicosidodecahedron schrieb:
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???
Ich brauche auch stdin/stdout ab und zu. die zu öffnen ist ein bisschen dumm. falls da doch eine datei ist wird diese in main geöffnet. (--> github source...)
PS: Sehr vielen dank für die interresse
-
ich glaube du wirst es nie kapieren!
dein algorihmus ist für die katze.
lerne bitte die materie! wenn du dann soweit bist, dann weist du selber warum!
-
lb schrieb:
ich glaube du wirst es nie kapieren!
dein algorihmus ist für die katze.
lerne bitte die materie! wenn du dann soweit bist, dann weist du selber warum!Mach du mal was besseres.
Wenn du mir nicht sagst WARUM, WORIN der fehler liegt ist deine Aussage wertlos.
-
lk schrieb:
lb schrieb:
ich glaube du wirst es nie kapieren!
dein algorihmus ist für die katze.
lerne bitte die materie! wenn du dann soweit bist, dann weist du selber warum!Mach du mal was besseres.
Wenn du mir nicht sagst WARUM, WORIN der fehler liegt ist deine Aussage wertlos.Warum sollte man versuchen, dir das zu erklären? Du würdest es eh nicht verstehen.
Setzt dich mal ein paar Monate/Jahre mit der Materia auseinander, dann betrachtest du deinen Algorithmus nochmal.
-
habe ja geschrieben das dein cipher auf differenzielle kryptoanalyse anfällig ist, weil dein schlüssel nicht zufällig ist.von allem anderen mal abgesehen...
-
314159265358979 schrieb:
lk schrieb:
lb schrieb:
ich glaube du wirst es nie kapieren!
dein algorihmus ist für die katze.
lerne bitte die materie! wenn du dann soweit bist, dann weist du selber warum!Mach du mal was besseres.
Wenn du mir nicht sagst WARUM, WORIN der fehler liegt ist deine Aussage wertlos.Warum sollte man versuchen, dir das zu erklären? Du würdest es eh nicht verstehen.
Setzt dich mal ein paar Monate/Jahre mit der Materia auseinander, dann betrachtest du deinen Algorithmus nochmal.Niemand hats versucht.
Das war nur der 2D algorithmus. der neue geht nicht mit differenzieller. wegen XOR.
-
lk schrieb:
Das war nur der 2D algorithmus. der neue geht nicht mit differenzieller. wegen XOR.
Aha! Na, wenn das so ist, dann ist ja alles gut.
Es geht eben nichts über Vollbitverschlüsselung, am besten mit verteilten Master- und Userkeys in Zonentaxonomie.
-
nein! weil dein schlüssel nicht zufällig ist!
und auserdem bezweifle ich das du die diff. kryptoanalyse verstehst!
-
Rein aus Interesse: Wie "gut" ist denn mein "Algortihmus" (mit xor statt +=)? Ich nehme mal an, dass der ziemlich unbrauchbar ist, weil sich die Regelmässigkeit von rand() irgendwie bemerkbar macht.
-
314159265358979 schrieb:
Rein aus Interesse: Wie "gut" ist denn mein "Algortihmus" (mit xor statt +=)? Ich nehme mal an, dass der ziemlich unbrauchbar ist, weil sich die Regelmässigkeit von rand() irgendwie bemerkbar macht.
Man muß nur die 4.2Mrd seeds für srand() ausprobieren. Eine Sache von Sekunden.
-
Da der Algorithmus aber nicht bekannt ist, sollte das doch auch was bringen, oder? Schließlich müsste man ja erst mal draufkommen, dass hier überhaupt mit Pseudo-Zufall gearbeitet wird.
-
314159265358979 schrieb:
Rein aus Interesse: Wie "gut" ist denn mein "Algortihmus" (mit xor statt +=)? Ich nehme mal an, dass der ziemlich unbrauchbar ist, weil sich die Regelmässigkeit von rand() irgendwie bemerkbar macht.
Wenn rand() ein kryptografisch sicherer Pseudozufallszahlengenerator ist, sollte dein Algorithmus meiner laienhaften Auffassung nach sogar sicher sein, vorausgesetzt du verschlüsselt mit jedem Schlüssel nur einen einzigen Text. Verschlüsselst du mehrere Texte mit demselben Schlüssel, ist die Zurückgewinnung des Schlüssels trivial, einfach ein XOR der beiden Ciphertexte machen. Nach dem Prinzip deines Algorithmus arbeiten manche Streamciphers, zum Beispiel AES im CTR-Mode.
Normalerweise ist rand() aber etwas ganz simples wie zum Beispiel ein linearer Kongruenz-Generator. Da kann man mit den richtigen Verfahren sofort die Regelmäßigkeit erkennen und die nächsten Pseudozufallszahlen vorhersagen, das ist also völlig unsicher, auch wenn du den Schlüssel nur einmal verwendest.
edit: Unter Berücksichtigung von volkards Antwort der Zusatz: srand() sollte mehr als 32 Bit des Keys auswerten, damit das eine Chance hat, sicher zu sein.
-
314159265358979 schrieb:
Da der Algorithmus aber nicht bekannt ist, sollte das doch auch was bringen, oder? Schließlich müsste man ja erst mal draufkommen, dass hier überhaupt mit Pseudo-Zufall gearbeitet wird.
Einfach den Code lesen.
-
314159265358979 schrieb:
Da der Algorithmus aber nicht bekannt ist, sollte das doch auch was bringen, oder? Schließlich müsste man ja erst mal draufkommen, dass hier überhaupt mit Pseudo-Zufall gearbeitet wird.
Sehr gut, dass du das ansprichst. Genau *das* ist nämlich der Punkt, an dem sich klassische Kryptografie von moderner Kryptografie unterscheidet.
In klassischer Kryptografie beruhte tatsächlich ein entscheidender Teil der Sicherheit auf der Annahme, dass der Algorithmus geheim war.
In moderner Kryptografie beruht die Sicherheit dagegen auf anderen, stärkeren Annahmen. Annahmen, die man in moderner Kryptografie zum Beispiel findet sind "es gibt eine one-way function" oder "NP != P". Diese Annahmen haben sich bisher als sicherer erwiesen als die Annahme "der Algorithmus ist geheim".
-
@volkard: Stimmt, das habe ich schon mal irgendwo gehört
@Christoph: Mit "NP != P" fange ich relativ wenig an. Ich meine mich erinnern zu können, dass das was mit Laufzeitkomplexitätsklassen zu tun hat.Hm... One-Way Funktion. So eine Funktion wäre dann eine gleichmäßige Abbildung eines großen Wertebereichs auf einen kleineren?
-
Ganz kurz offtopic: Also müsste man "schlüssel" schreiben, die selber den algorithmus irgendwiedefinieren und sich selbst als schlüssel verwenden ?
Okay ich weis das das nicht 100%-ige zufälligkeit ist, aber woher soll ich denn bitteschön wirkliche zufallszahlen herbekommen? 25638 mal Münzen werfen werde ich doch nie im leben tun!
Okay Christoph, das mit dem XOR ist ja natürlich, aber da ist ja das 2D und das 3D teil in beide richtungen... Es sei denn der algorithmus macht garnichts. aber er macht ja etwas... also...
EDIT: Falls alle mich deswegen an die wand nageln, der Würfel wird beim generieren zufällig durchgeschüttelt.