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

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

  • L

    Hoi,

    Github
    https://github.com/linuxrocksrulers/TEA3 (nur main.c)
    Mein code ist opensource. Feel free to fork. (GNU GPLv3)

    Beschreibung
    Hab meinen eigenen Verschlüsselungsalgorithmus geschrieben, basierend auf diesem vorherigen hier(link geht auf einen anderen forum post). Mein neuer algo geht allerdings in drei schritten vor: erst wird der alte TEA2/TRA algo angewendet. Danach wird das tea2-verschlüsselte mit der tabelle raw gexor'd. Danach wird TEA3 angewendet.
    TEA3 ist TEA2/TRA mit einer zusätzlichen coordinate(z natürlich).

    `TEA2/TRA:

    x = in[i]

y = out[i-1]

out[i] = table[x,y]

    XOR:

    xord[i] = table[i] xor out[i]

    TEA3:

    x = in[i]

y = out[i-1]

z = xord[i]

out[i] = table[x,y,z]

    UND dann hat out[] das verschlüsselte.

    `

    Auftrag...
    Nun habe ich probleme mit der entschlüsselung :). TEA2/TRA hat TyRoXx gelöst, wofür ich ihm sehr sehr dankbar bin. Leider/zum glück hat er es auch gecrackt... also hab ich XORing hinzugefügt und den 3. Schritt hinzugefüht. Jetzt breuch ich nochmal hilfe beim rückgängig-machen. ich komm einfach nicht drauf. Siehe ende des posts für die function zur TEA2/TRA entschlüsselung. oder github eben.

    ~Zum namen...~
    Anfangs hieß mein algo TRA: Tabular irgendetwas (vergessen...)
    Dann ungefauft auf TEA2 als ich TEA3 schreib. Ich nenn ihn immer noch TEA2/TRA weil es so cool aussieht.
    TEA3 ist dann eben TEA2/TRA mit drei Koordinaten.

    für code siehe github. habs aber trotzdem nochmal reinkopiert.

    ///// <<ENCRYPTION>>
// TEA2/TRA encryption. TyRoXx has proved this crackable. thus addeed xor encryption and tea3, and new name: TEA2/TRA --> TEA3
int tea_encrypt_tea2tra(tab_t table, byte* out, int count, byte* a, byte* b)
{
	out[0] = table[tea_resolve(a[0],0,0)];
	int i;
	for (i=1; i<count; i++)
	{
		out[i] = table[tea_resolve(a[i],b[i-1],0)];
	}
	return count;
}

int tea_encrypt_rawxor(tab_t table, byte* out, int count, byte* a)
{
	int i;
	for (i=0; i<count; i++)
	{
		out[i] = table[i%256*256*256] ^ a[i];
	}
	return count;
}

// a(x): normally the plaintext
// b(y): normally 'out'.
// c(z): xord data from step#2.
// this then is the function i need help with.
int tea_encrypt_tea3(tab_t table, byte* out, int count, byte* a, byte* b, byte* c)
{
	int i;

	out[0] = table[tea_resolve(a[0],0,c[0])]; // exclude b from specification
	for (i=1; i<count; i++)
	{
		out[i] = table[tea_resolve(a[i],b[i-1],c[i])];
	}
	return count;
}

// encrypts data found at inf via table into outf.
// loads a specifc-sized chunk (1KB/1024bytes) and encrypts.
int tea_encrypt(FILE* inf, FILE* outf, tab_t table)
{
	int chunkindex;

	byte* in   = malloc(CS);
	byte* out  = malloc(CS);
	byte* xord = malloc(CS);
	int count;

	while(!feof(inf))
	{
		count = fread(in,1,CS,inf);
		if (count<=0) continue;

		tea_encrypt_tea2tra(table,out,count,  in, out);
		tea_encrypt_rawxor(table,xord,count,  out);
		tea_encrypt_tea3(table,out,count,     in, out, xord);

		fwrite(out,count,1,outf);
		chunkindex++;
	}
	//printf("EOF hit. Stop.\n");

	fclose(inf);
	fclose(outf);
	return 0;
}
///// <<//ENCRYPTION>>

    int tea_decrypt_tea2tra(tab_t table, byte* out, int count, byte* a)
{
	int i, p;

	if (count<=0) return 0;

	for (p=0; p<256; p++)
	{
		if (table[tea_resolve(p,0,0)] == a[0])
		{
			out[0] = p;
		}
	}

	for (i=1; i<count; i++)
	{
		byte aux = a[i-1];
		for (p=0; p<256; p++)
		{
			if (table[tea_resolve(p,aux,0)] == a[i])
			{
				out[i] = p;
			}
		}
	}

	return count;
}

    Ja, ich liebe Tee 🙄

    0
  • L

    Also der schlüssel ist 16MB groß. Es ist ein 256x256x256 großer würfel. eine art 3D sudoku, wo vertikal,horizontal,längikal(?) jeder wert 0..255 nur einmal vorkommen kann. Wie bei sudoku gibts aber diese 9 sub-sudokus nicht. Also kommt zB in würfel[0..255][10][20] (bewegen entlang der x axis) jeder wert von 0..255 bestimmt einmal, aber auch nur einmal vor.
    Der ganze algorithmus ist sozusagen substitution, aber nicht per linear aber 3D eben mit einem XOR schritt.
    Beim TEA2/TRA (1.) schritt wird nur auf der würfel[0..255][0..255][0] ebene bewegt (Also Dem 1. face/Gesicht des würfels. 3D-functionalität wird weggeschnitten.).

    Bump.

    0
  • C

    Ich bin zwar kein Experte für Kryptografie, aber wer einen Verschlüsselungs-Algorithmus erfindet, sollte schon selber wissen, wie er diese Verschlüsselung umkehren kann 😉

    (auf der anderen Seite mußt du auch bedenken, daß du diesen riesigen Schlüssel irgendwo speichern (und eingeben) mußt, um damit arbeiten zu können)

    0
  • O

    Normalerweise sollte ein Schlüssel wesentlich kleiner sein als die Datei, die man verschlüsseln will. Idealerweise so, dass man ihn sich merken kann und der einzig mögliche Angriff die Gummischlauch - Kryptoanalyse ist. Bei dir definitiv unmöglich.

    0

  • Was genau ist denn die Frage? Du hast dir einen symmetrischen Verschlüsselungsalgorithmus überlegt und weißt nicht, wie du das Chiffre zurückrechnen kannst? Und die Implementation der Verschlüsselung hast du auch nicht selbst gemacht, sonder ein gewisser TyRoXx? Und zu allem Überfluß der hat auch noch gezeigt, dass dein Verfahren angreifbar ist?

    Jester edit: wir hatten schonmal Ärger mit dem chef, das würden wir gern vermeiden.

    0
  • K

    Was hat das alles mit C++ zu tun?

    Außerdem: Wer sich für Kryptographie interessiert, sollte sich zunächst mal ein schlaues Buch dazu holen. Am besten eins, welches nicht nur aus einer geschichtlichen Aufzählung früherer Verfahren besteht, welche man heute müde belächeln würde, sondern ein Buch, was dem Leser auch klar macht, wie schwierig es ist, sichere Kryptoverfahren zu konstruieren und wie wichtig Standards sind. Die Standards gibt es auch für Protokolle. Also, einfach ein paar Standardbausteine wie DSA, AES, RSA irgendwie aneinander kleben, bringt auch nichts. Da braucht man kompetente Leute, die wissen, was sie tun.

    0
  • L

    DocShoe schrieb:

    Was genau ist denn die Frage? Du hast dir einen symmetrischen Verschlüsselungsalgorithmus überlegt und weißt nicht, wie du das Chiffre zurückrechnen kannst? Und die Implementation der Verschlüsselung hast du auch nicht selbst gemacht, sonder ein gewisser TyRoXx? Und zu allem Überfluß der hat auch noch gezeigt, dass dein Verfahren angreifbar ist?

    Ich hab alles selbst geschrieben. "ein gewisser TyRoXx" ist ein erfahrenes forum mitglied hier, und hat nur die idee zum decryption gegeben. 100% des sources auf github stammt von mir.

    0
  • C

    Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x) in das Forum Mathematik und Physik verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
  • Mod

    Also du hast eine Verschlüsselung entwickelt? Und du hast das nicht systematisch gemacht, sondern einfach drauflos? Und jetzt weißt du nicht, wie du zurück kommst?

    Dann beschreib mal den Algorithmus verständlich. Lieber zu viel erklären als zu wenig. Und bitte nicht "so wie das mein Sourcecode macht" als Erklärung.

    Und sei dir im Klaren, dass jetzt schon klar ist, dass das nicht sicher ist.

    0
  • V

    DocShoe schrieb:

    Warum wird K.RYPTOCHEF zensiert?

    Weil seine Vollbitverschlüsselungstheorien als Trollerei anzusehen sind.

    0
  • -

    CStoll schrieb:

    Ich bin zwar kein Experte für Kryptografie, aber wer einen Verschlüsselungs-Algorithmus erfindet, sollte schon selber wissen, wie er diese Verschlüsselung umkehren kann 😉

    (auf der anderen Seite mußt du auch bedenken, daß du diesen riesigen Schlüssel irgendwo speichern (und eingeben) mußt, um damit arbeiten zu können)

    Ach komm "CStoll" halt Dich nicht zurück. Kannst ihm ruhig sagen das dieser Cypher nichts Wert ist. Den:

    @lk

    1. Der Algorithmus ist zu 100% unsicher! Denn so wie Du ja geschrieben hast weist Du nicht ob er sicher ist oder nicht.

    2. Du entwickelst ein Cypher und kannst ihn nicht umkehren!? Er kann einfach nicht sicher sein. Denn dahinter ist überhaupt kein Konzept und nichts! Wie kannst Du nur im entferntesten glauben dass dieser Cipher sicher ist?

    2. Sollte man eine Menge verstehen von Kryptographie, Mathematik, Protokollen etc. .., (und dass ist hier leider nicht der Fall).

    3. Entsteht so ein Algorithmus zuerst auf dem Papier. Danach wird zbsp. in (meistens) C/Assembler implementiert und optimiert... danach kommt immer ein Paper!

    4. Wenn du Programmieren lernen willst such dir eine anderes Gebiet, als Crypto-Progrämmchen zu schreiben die sowieso nichts Wert sind. 😉

    5. Wenn Du Dich aber intressierst für Algorithmen, Crypto ,Verfahren etc. Dann empfehle ich Dir viele Bucher zu kaufen, damit Du Dich so richtig in die Materie einarbeiten kannst (und dies hat wenig mit programmieren zu tun). Für all dies zu erreichen kannst du ohne Probleme 1.Jahrzehnt deines Lebens verbraten.

    Designed by Volkard 👍

    _____  _____
                                <     `/     |
                                 >          (
                                |   _     _  |
                                |  |_) | |_) |
                                |  | \ | |   |
                                |            |
                 ______.______%_|            |__________  _____
               _/                                       \|     |
              |                   TEA2/TRA                    <
              |_____.-._________              ____/|___________|
                                |            |
                                | + 23/08/11 |
                                |            |
                                |            |
                                |   _        <
                                |__/         |
                                 / `--.      |
                               %|            |%
                           |/.%%|          -< @%%%
                           `\%`@|     v      |@@%@%%    - mfj
                         .%%%@@@|%    |    % @@@%%@%%%%
                    _.%%%%%%@@@@@@%%_/%\_%@@%%@@@@@@@%%%%%%

    Sorry für meine harten Worte... 🤡

    0
  • L

    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?

    0
  • Mod

    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?

    0
  • L

    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?

    0
  • C
    Mod

    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.

    0
  • Mod

    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.

    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.

    0
  • -

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

    0
  • 3

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

    Mein Algorithmus, entwickelt in 5 Sekunden.
    😃

    0
  • R

    @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

    0
Anmelden zum Antworten