[HaBo]
| Cryptography & Encryption Ver- und Entschlüsselung, Algorithmen, Kryptoanalyse ? Kryptographie in der Praxis. Blowfish, Triple-DES, XOR u.a. |
Kobalt-Verschlüsselungsalgorithmus
Diskussion: Kobalt-Verschlüsselungsalgorithmus im Forum Cryptography & Encryption, in der Kategorie Security Area; Anzeige Heyho.Mein Algo. ist jetzt fertig.Wenn ihr wollt könnt ihr ihn euch ansehen oder ihn sogar verwenden (implementieren) .Wer will ...
 |
05.06.07, 19:13
| #1 (permalink) |
| Registriert seit: 29.04.07  Likes: 0 |  Kobalt-Verschlüsselungsalgorithmus Anzeige Heyho.Mein Algo. ist jetzt fertig.Wenn ihr wollt könnt ihr ihn euch ansehen oder ihn sogar verwenden (implementieren) .Wer will kann auch was dazu sagen.Morgen hab ich Präsentation und bin schon recht nervös : ).Sollte jemand gravierende Schwächen finden bittte auch melden. Ihr findet ihn hier Für Beiträge dazu wäre ich dankbar. pi() |
|  |
|
05.06.07, 19:57
| #2 (permalink) | |||
| Moderator   Registriert seit: 30.03.04  Likes: 14 | RE: Kobalt-Verschlüsselungsalgorithmus Hallo, Zitat:
Zitat:
Ich versteh einfach nicht, warum man einen eigenen Algorithmus "entwickeln" sollte. Es gibt soviele, sichere, kostenlose/patentfreie, schnelle und schön zu implementierende Algorithmen, dass die Schreibung eines eigenen Schwachsinnig ist. Zitat:
Selbst Serpent schafft es noch auf fast 45 MBit/s, und die C Implementierungen dieser Algorithmen sind um einiges schneller (z.B. AES-256 in C ca. 640 MBit/s) Mit 1 MB/s oder 8,38 MBit/s (für dich Vorteilhaft gerechnet) kannst du nicht viel vom Hocker reißen. PS: Bitte nicht böse nehmen, soll eher als konstruktive Kritik gelten und andere Abhalten deinen Algorithmus zu verwenden  Sonst viel Glück morgen. Ich lad mir mal den Code runter und schau ihn mir mal an, bin aber auch nicht fit was (moderne) Kryptoanalyse angeht. | |||
|
| |
| HaBOT | - Anzeige - |
|
|
05.06.07, 21:22
| #3 (permalink) |
| Moderator Registriert seit: 30.03.04 Likes: 14 | Hallo, so sry für Doppel Post, aber ich nehm mir das Recht mal raus *h3h3*. So was mir auffiel: Warum ist der perKey ein int-Array, wo aber nur byte-Werte verwendet werden? Warum implementierst du dies über Byte-Arrays und verwendest keine 32-Bit Wörter (integer)? Speed-Tipp: Modulo-Operationen (%) sind extrem langsam, anstatt %8 lieber &7 verwenden, steiger die Performance enorm. Dann anstatt zu Teilen und zu multipilizieren evt. die Bits schieben, also anstatt x/8 lieber x>>3 Negative Bytes: Bytes bei denen man das Vorzeichen beachtet, wie es bei dir der Fall ist, sind sehr sehr komisch. Da in C# das Byte _vorzeichenlos_ ist, habe ich große Probleme deinen Code nach C# zu übersetzen. Normale Algorithmen verwenden kein Vorzeichen. Vorallem bei einem Byte mit einem Vorzeichen gibts keinen Wert '128' sondern nur -128. Da ich die Substitutions-Methode etwas modifizieren musste, wären Testvektoren sinnvoll. Vorrunde: Dieses erhöht nicht die Sicherheit, da diese nicht Schlüsselabhänig ist. Ist ähnlich wie bei der Premutation von DES, die aber nur diente, um die Input-Bits zu "laden". Schlussrunde: "// Schlussrunde, ganz wichtig  "Ist der perKey Schlüssel-Abhänig? Da ich nix zum Key-Setup gefunden habe, kann ich dazu nix sagen, ich denke aber mal dass nur xorKey0-3 den Schlüssel darstellt. Wenn dieser nicht Key-Abhänig ist, bringt die Schlussrunde genauso wenig wie die Vorrunde, da ich den perKey kenne, kann ich die Schlussrunde ganz einfach wieder "abziehen" vom Ciphertext. Lücke! Wenn die XOR-Keys nur 0x00 sind (ohne perKey oder Boxen zu ändern), dann ist der Chiffer-Text ohne die Schlussrunde wie folgt: a = 11 11 11 11 ... b = 4c 4c 4c 4c ... c = 71 71 71 71 ... d = 44 44 44 44 ... Selbst wenn die Schlussrunde Schlüsselabhänig sein sollte, dann ist dieses Ergebnis extrem verdächtig und soetwas darf eigentlich bei keinem guten Algorithmus auftreten. Wie du siehst, ist dein Algorithmus mit sehr sehr hoher Wahrscheinlichkeit unsicher. Denn wenn der Key (die XOR-Keys) alle die gleiche Value haben sowie das Input das gleiche Value hat (alles 00-Bytes), so sind die Variablen a,b,c,d in den Runden immer gleich, also a besteht z.B. nur aus 0x5a-Bytes, b nur aus 0x66 Bytes usw. Da dein Key-Setup so konfuse ist, und der Abend zuende geht, beendige ich den Abend vorerst mit 'Algorithmus gebrochen', da dies so merkwürdig ist, dass es höchst wahrscheinlich eine Lücke darstellt. Erklräung der Lücke Dein Algorithmus zu geradlinig!. Die einzelnen Blöche a,b,c,d beeinflussen sich nicht gegenseitig, also hast du effektiv keine 256-Bit-Blöcke, sondern in Wirklichkeit nur 64-Bit Blöcke. Des Weiteren verwendest du nur 1 Byte-Schift (bzw. 8 insgesamt), und dies nur innerhalb des Blockes. Wenn einer der 64-Bit-Blöcke "homogen" ist, also nur aus 1 Byte besteht (z.B. AB AB AB...), so bringt der Byte-Schift nicht viel, ist dann noch der XOR-Key homogen, geht die Sicherheit komplett überboard. Wenn du schon 256-Bit-Blöcke verwendest, dann sollte eine Veränderung in einem Block auch alle anderen Blöcke beeinflussen. Standard-Mittel hierfür ein ein Feistel-Netz. Bsp: Du Verschlüsselst du Eingabe: AA 00 00 00 .... Die Blöcke a,b,c,d nach den 32 Runden weisen aber nur eine Veränderung jeweils in ihrem ersten Byte auf, wenn überhaupt: Meine Ausgabe: a = 2c 11 11 11 ... b = 60 4c 4c 4c ... c = 71 71 71 71 ... (Keine Veränderung!) d = 6a 44 44 44 ... Und diese minimale Veränderung entstand nur Aufgrund der Vorrunde, die die Blöcke aber nur minimal in Abhänigkeit setzt. Was schön wäre, ein verständliches Key-Setup zu schreiben, also in den Algorithmus Kobalt....java eine Methode SetupKey zu integrieren, der man einfach den 256-Bit Key übergibt, und diesen die Arrays entsprechend modifiziert. Des Weiteren fiel mir noch in expand auf: SBox0=expand(SBox0,xorKey); //Methode expand (byte [] Box,byte [] xorKey) Box[i]=Box[xorKey[i]]; Die SBox hat 128-Einträge, ein Byte kann bekanntlich 256-Werte annehmen. Da das byte unter Java ja scheinbar vorzeichenhaft ist, gibts auch negative Werte, aber welchen Wert liefert Box[-15] zurück?? Fazit Dein Algorithmus ist deutlich zu geradlinig. Kleinste Veränderungen in der Eingabe müssen zu einem deutlich anderem Ciphertext führen. Die Blöcke müssen sich untereinander stark beeinflussen. Verändert sich nur ein einziges Bit im ersten Block, muss dieses alle anderen Bits beeinflussen. Im jetzigen Zustand ist dein Algorithmus sehr unsicher. Verbesserungsmöglichkeiten: - Verständliches Keysetup - Feistel-Netzwerk - Mit 32-Bit-Wörtern arbeiten (aufgrund der Performance) - Bit-Rotationen verwenden - Oder doch gleich einen sicheren Algorithmus benutzen (Blowfish, Twofish, AES, Serpent, die Liste ist lang...) verwenden |
|
| |
|
05.06.07, 22:35
| #4 (permalink) |
| Themenstarter Registriert seit: 29.04.07 Likes: 0 | Hallo. Danke , dass du dir den Algorithmus so genau angesehen hast.Offensichtlich kannst du ziemlich gut programmieren. ad 1 : In dem Programm (Crypt0r) wird aus dem Xor-Schlüssel: 4 S-Boxen 1 P-Box +eben der Xor-Schlüssel ad 2 : Hab mich für ein Substitutions-Netzwerk entschieden, du magst aber vlt recht haben ad3 : Das mit den 32 Bit Wörtern werd ich auch noch machen.Danke für den Tipp. ad4 : Werd ich auch machen.Danke Danke. Das mit dem geradlinig stimmt irgendwie.... .Aber die Key expandierung sollte doch reichen um volle 256 Bit zu erhalten.... . Ja, ich weiß. 1MByte/s ist scheußlich langsam.Werd auf jeden Fall viel tun um das zu verbessern. VIelen vielen Dank für deine Tipps.Ich werd sie sogut wie möglich befolgen. Der Xor-Schlüssel darf nciht 000000usw sein, ich weiß, das ist ein WEAK-KEY. Das mit dem wenn sich ein Bit im KLartext ändert muss sich alles ändern ist zB bei des (ECB) auch nicht so ist mir heute aufgefallen, das hat mich gleich beruigt ^^.Das wenn sich 1 Bit im Schlüssel ändert, sich alles ändert hab ich gottseidank schon zusammengebracht ^^. Der Grund warum ich mir selbst nen algo mache ist, dass ich mich sehr für Kryptografie interessiere.Klar ist mein Algo nicht so gut wie ein "echter".Aber mach mal nen kleinen Vergleich Ich=16 jähriger HTL trottel. Entwickler von zB AES=Nerds, die ihr ganzes Leben vorher Kryptographie und /oder Informatik studiert haben. Außerdem hab ich ihn alleine gemacht  .pi() |
|
| |
|
06.06.07, 12:40
| #5 (permalink) | ||
| Moderator Registriert seit: 30.03.04 Likes: 14 | Hallo, Zitat:
Zitat:
Es gilt die Regel: - Ändert sich 1 Bit im Klartext (von einem Block), müssen sich im Schnitt 50% der Geheimtextbits verändern - Für 1 Bit im Schlüssel gilt das gleiche. Diese 50% kommen daher, dass ein Geheimtextbit eben nur den Wert 1 oder 0 annehmen kann und so behalten im Schnitt eben 50% ihren alten Wert. Würden sich alle Bits ändern, wäre dies auch unsicher, weil der neue Ciphertext dann das negativ des alten wäre, wenn aus 1101011 => 0010100 wird. Aber diese Regel ist sehr sehr wichtig, wenn dies nicht erfüllt ist, dann ist der Algorithmus unsicher. Zum Beispiel gibt es den sogenannten Counter-Modus als Betriebsart (wird bei WPA2 benutzt). Dort verschlüsselt man zuerst 00 00 00... dann .. 00 01 dann ... 02 dann ... 03 usw., also immer um 1 erhöht, ein Counter eben .Den Geheimtext (der Keystream) der dort rauskommt wird dann per XOR mit dem Klartext verknüpft, also wird der Blockalgorithmus zur Stromchiffre. Dieser Keystream darf nicht von absolut zufälligen Zahlen/Bytes zu unterscheiden sein, sprich der Keystream muss selber absolut zufällig aussehen, sonst ist die XOR-Verknüpfung von Keystream und Klartext nicht mehr sicher. Dein Ciphertext/Keystream ist aber kein stück zufällig, dann das 8 mal hintereinander die das gleiche Byte auftritt, bei einem zufälligen Stream ist die Wahrscheinlichkeit 1 zu 10^16, dass dieses 4 mal vorkommt 1 zu 10^67. Wenn der Algorithmus aber sicher ist, also zumindest die oben genannten Regel erfüllt, dann ist der Counter-Modus genauso sicher wie anderen Methoden (zum jetzigen Zeitpunkt) PS: Der Counter (der Startwert) ist nicht geheim und wird offen Übertragen. Weiter Infos zum Counter-Modus PPS: Es bringt eigentlich mehr am Anfang gute Bücher/gute Literatur über Kryptographie zu lesen und dann, wenn man schon den drang hat einen eigenen Algorithmus zu schreiben, erstmal andere Algorithmen anzugucken, wodurch diese ihre Sicherheit "erhalten". Des Weiteren kommt Sicherheit nicht durch komplexität, wenn man sich mal Blowfish und XTEA anguckt, beides super schlanke Algorithmen, die dennoch sicher sind. Die Verschlüsselung von Blowfish sieht im Grunde so aus: Code: for(int i=0;i<16;i++) {
L ^= P[i];
// R ^= f(L); //Die Funktion f(x) ist unten nun eingefügt.
R ^= ((sbox1[(L >> 24)] + sbox2[(L >> 16) & 0xFF]) ^ sbox3[(L >> 8) & 0xFF]) + sbox4[L & 0xFF];
Swap(L,R); //Vertausche L und R
}
Swap(L,R);
R ^= P[16];
L ^= P[17]; | ||
|
| |
|
06.06.07, 15:26
| #6 (permalink) | |
| Registriert seit: 25.11.05 Likes: 0 | Zitat:
aber sieht ja schon massig besser aus, was andere hobby-kryptographen zusammenbasteln. | |
|
| |
|
06.06.07, 19:36
| #7 (permalink) |
| Themenstarter Registriert seit: 29.04.07 Likes: 0 | @menace Danke, ich fühle mich geehrt. @Elderan Du hast natürlich recht.Ich werde sehr bald eine Verbesserung vornhemen. Ich hab den Algorithmus heute in der Schule präsentiert und mein Lehrer (und teilweise die Klasse) waren begeistert .Oh was ist heute für ein schöner Tag....pi() |
|
| |
|
08.06.07, 00:10
| #8 (permalink) | |
| Senior Member  Registriert seit: 07.01.03 Likes: 19 | Zitat:
(sry 4 spamming) | |
|
| |
|
08.06.07, 00:14
| #9 (permalink) |
| Senior Member  Registriert seit: 10.03.07 Likes: 19 | Aber in solch einem Fall ist eine direkte Zuweisung schneller, denn die Schleife muss initialisiert werden, es muss gesprungen werden und bei jedem durchlauf überprüft werden, ob die Bedingung erfüllt ist oder nicht. Für die Performance ist die Lösung ideal! |
|
| |
|
08.06.07, 14:39
| #10 (permalink) | |
| Moderator Registriert seit: 30.03.04 Likes: 14 | Hallo, Zitat:
Denn du hast 8 Lese&Schreibzugriffe, nur um 1 Rotation hinzubekommen. Des Weiteren ist der Zugriff auf Arrays eh immer vergleichsweise langsam, denn einzelne Variablen kann ich im Register behalten, ein ganzes byte-Array nicht. Würde man mit 32-Bit Wörtern arbeiten, bekommt man das gleiche mit: a = (a<<8) | (a>>24); hin. Man sollte aber versuchen, möglichst wenig Sprünge im Algorithmus zu haben. Jeder Funktionsaufruf, bedingte Anweisungen (if, else) und auch Schleifen, verlangsamen den Algorithmus. Da aber Hochsprachen wie Java keinen Preprocessor und man nix per #define festlegen kann, können optimierte Algorithmen extrem unübersichtlich aussehen, weil es keine Funktionsaufrufe gibt und auch keine Schleife. Der Serpent-Algorithmus (Bitslice, also maximal optimiert) kommt dann so gerne mal auf ~2500 Zeilen Code (Java), benötigt aber nur ~500 Zeilen in C Die Verwendung von 64-Bit Variablen auf einer 32-Bit CPU wäre nicht sinnvoll, weswegen man lieber 8 * 32-Bit Integers verwenden sollte. Sonst hier noch ein nettes Paper über die Performance von Algorithmen in Software, bezieht sich aber mehr auf das Design von neuen Algorithmen und offentsichtliche performance Verbesserungen (z.B. statt %4 lieber &3 verwenden) werden auch nicht genannt, dennoch ganz intressant: Fast Software Encryption: Designing Encryption Algorithms for Optimal Software Speed on the Intel Pentium Processor | |
|
| |
|
08.06.07, 15:52
| #11 (permalink) |
| Themenstarter Registriert seit: 29.04.07 Likes: 0 | Boah, also ich bin begeistert.Ich danke für eure Hilfe und mache mich gleich an die Optimierung.Alles Optimierte lade ich dann hoch.Bitte (wenn sinnvoll) noch mehr posten .pi() edit: Hab mal angefangen den Algorithmus folgendermaßen zu verbessern: 128 Bit Block- und Schlüssellänge 16 Runden * und / und % durch << und >> und & ersetzt 32 Bit Worte verwendet folgendes wird noch gemacht: nichtliniarität ganz wichtig: neue Substitution: wenn ich die Substitution nämlich so auch bei int mache, dann habe ich Sboxen die mehr Zeilen haben als der Windows xp-Sourcecode ^^. Habe heute einige Stunden durchprogrammiert (2 kaffee ^^) und einiges weitergebracht. @Elderan: Ich kann dir garnicht dankbar genug sein ^^. |
|
| |
|
08.06.07, 18:52
| #12 (permalink) | |
| Senior Member Registriert seit: 07.01.03 Likes: 19 | Zitat:
als beispiel führe ich z.b. mal das brettspiel reversi an, das auf einem 8*8-brett gespielt wird & nur 1 spielstein pro partei hat. der naive ansatz ist, dieses brett durch ein 2-dimensionales array darzustellen, schneller geht es mit 128 bit (2 long oder 4 int) vielleicht wäre es ganz praktisch, wenn du dir mal anschaust, wie man mit zahlen als bitfolgen umgeht, also z.b. über eine AND-maskierung gewünschte bits filtert oder mit einer OR bits in einer bitfolge setzt (genau das macht Elderan auch mit a = (a<<  | (a>>24))aufpassen sollte man bei bitshifts auch va auf das vorzeichen, ich glaube, das wird bei java bei einem << beibehalten (ist ja alles in 2er-komplement-darstellung), und bei einem <<< nicht. nach rechts schiebt man ausschließlich mit >>. noch 2 generell interessante sachen, auch etwas am the vorbei, aber lesenswert: http://www.fefe.de/devel/optimizer-101.txt (va der part über schleifen & unrolling) http://blog.fefe.de/?ts=bb1e258d (mal cpu-vergleich) ach, und deklarier methoden, die nicht nicht von vererbung / überschreiben betroffen sind, als final. und die konstanten natürlich auch (du hast da paar variablen, die nie überschrieben werden). zugriff auf konstanten (selbst auf primitive datentypen) ist in java (trotz constant table) allerdings trotzdem noch ein gutes stück langsamer als die werte der konstanten im code selbst zu verwenden - nur wird das eben immer unleserlicher.. aber da würde ich im zweifelsfall eine testklasse schreiben (junit ist was tolles *g*) | |
|
| |
|
08.06.07, 19:58
| #13 (permalink) |
| Themenstarter Registriert seit: 29.04.07 Likes: 0 | Cool,danke. Ich hab mir erstmal nur den 2. Link angesehen. Passt zwar nicht (ganz) zum thema aber ist echt arg.Ich hab ne Core2-CPU und bin irgendwie geschockt ^^.Aber im gesamten ist und bleibt der Core2 eben schneller.Und außerdem hab ich in der Schule sehr viel über den Core 2 gelernt (auch ein bisschen über AMD 64), der ist echt besser als der Athlon 64. pi() edit: Oh mann ey, ich werd noch lange an meinem Algorithmus arbeiten, es gibt noch so viel, das mir nicht gefällt.Aber es ist witzig, ich bin mir trotzdem noch sicher dass es möglich ist einen guten Algorithmus selbst zu machen. Btw: Wenn mir jemand helfen will, kann er sich gern bei mir melden! |
|
| |
|
| - Anzeige - | |
|
|
[HaBo] » Security Area » Cryptography & Encryption » Kobalt-Verschlüsselungsalgorithmus
| Themen-Optionen | |
| Ansicht | |
Linear-Darstellung
| |
Ähnliche Themen | ||||
| Thema | Autor | Forum | Antworten | Letzter Beitrag |
| Verschlüsselungsalgorithmus | Affe | Code Kitchen | 10 | 17.01.07 11:08 |
