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

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