Diskussion:Rijndael MixColumns

Vorschläge

Vorschläge zur Verrbesserung bitte hier hinterlassen --MyChaOS 16:48, 15. Nov. 2008 (CET)

Guter Artikel. In dem verlinkten Tutorial (http://www.codeplanet.eu/tutorials/cpp/51-advanced-encryption-standard.html), welches als eine Quelle für diesen Artikel fungierte, sind ein paar interessante Informationen über die im AES verwendete MDS-Matrix zu finden. Vielleicht könnte jemand den WP-Artikel damit etwas ausführen. Momentan sind keine Informationen über diese spezielle Matrix hier zu finden. --Stefan Schultz 18:14, 1. Nov. 2009 (CET)

Zitat: "Der MixColumns-Schritt stellt gemeinsam mit dem ShiftRows-Schritt den primären Verschleierungsakt im Rijndael-Algorithmus (AES) dar." Ist dem wirklich so? Beide sind doch im Endeffekt auch nur eine lineare Abbildung. Die Nichtlinearitaet, die AES sicher macht, kommt doch dank der S-Boxen (entspricht Inversion auf Galois Koerper und anschliessender affiner Transformation) zustande? --79.208.76.61 17:59, 8. Nov. 2012 (CET)

das ist sicherlich etwas hochgegriffen, natuerlich ist jeder schritt fuer dich sicherheit wichtig. ich denke man kann diesen satz ruhig umformulieren. --Mario d 18:11, 8. Nov. 2012 (CET)

Pass schon, er IST sehr wichtig, denn es ist der einzige Schritt, wo verschiedene Bytes sich gegenseitig beinflussen. Die S-box ist ein 8bit Blockschiffre, das man bei Text durch Buchstabenhäufigkeit trivial lösen könnte. Die anderen Schritte nehmen nur XOR mit dem Schlüssel, und tauschen die Bytes (auf immer die gleiche Weise) aus, also wäre AES ohne Mixcollum tatsächlich trivial. (nicht signierter Beitrag von 79.225.106.45 (Diskussion) 22:16, 21. Aug. 2015 (CEST))

Fehler

Die Berechnung der Galois Multiplikation mit Hilfe der Potenz und Logarithmustabellen hat meiner Meinung nach einen Fehler. Das Ergebnis ist nicht exp_table[ln_table[a] ^ ln_table[b]] sondern exp_table[(ln_table[a] + ln_table[b]) % 255] Bin mit jetzt aber nicht sicher genug ob das wirklich stimmt, um den Artikel entsprechend zu editieren. -- 92.117.231.210 04:04, 23. Nov. 2010 (CET)

Fehler Beispiel am Galois Körper

Bei der Berechnung von 3 * 32: 11b * 110010b ergibt nach WolframAlpha nicht 01010110b bzw x^6+x^4+x^2+x, sondern x^7+x^4+x^2+x = 10010110b = 150 = 0x96 http://www.wolframalpha.com/input/?i=11+base+2+*+110010+base+2 http://www.wolframalpha.com/input/?i=3+base+16+*+32+base+16 (nicht signierter Beitrag von 93.228.69.59 (Diskussion) 23:06, 5. Mai 2013 (CEST))

das stimmt nur beim multiplizieren von ganzen zahlen. bei der multiplikation in GF(2^8) gibt es keinen uebertrag, sondern x^5+x^5 = 2x^5 = 0. --Mario d 12:43, 7. Mai 2013 (CEST)

Verwirrende Notation

Ich hatte gestern zwei kleine Änderungen vorgeschlagen ([1] und [2]) und bin zunächst von einem Fehler ausgegangen. (Herzlichen Dank an Megatherium fürs Sichten!)

Die Begründung zur Ablehnung der Änderung 221637484 bei Advanced_Encryption_Standard#MixColumns kann ich verstehen, da die Operation $2a$ für ein byte $a$ nicht klar definiert ist: Bleibt die Operation im Raum der "bytes" oder erweitert sich das Ergebnis um ein weiteres bit. Sprich, wenn $2a$ wieder ein byte ist, dann verschwindet ein etwaiges bit an Position 8 (Zählung bei 0 beginnend) automatisch.

Im C-Code bei Rijndael_MixColumns#Möglichkeiten_zur_Implementierung ist es aber äußerst verwirrend:

• Der implizite Cast auf unsigned char bei unsigned char c = a << 1; entfernt bereits ein etwaig auftretendes bit an Stelle 8.
• Bei der Operation c ^= 0x11b; passieren gleich 2 implizite Casts: Zunächst wird c ^ 0x11b ausgeführt. 0x11b hat den Standardtyp int und damit bekommt das Ergebnis den "größeren" Typen int. Hier haben wir sogar kurzzeitig ein falsches Ergebnis, da ein Bit an Position 8 hinzugefügt wird. Es bleibt glücklicherweise ohne Folgen, da das Ergebnis zurück in c geschrieben wird. Als unsigned char "kennt" dieser aber nur die Bits 0-7. Damit führt die Operation insgesamt nicht zu einem funktionalen Fehler.

Zusammengefasst: Es ist nicht falsch, aber meiner Meinung nach verwirrend. Zudem fällt die Inkonsistenz sowohl mit der englischsprachigen Version als auch mit "echten" Implementierungen ins Auge, z.B. [3] oder [4].

--2A02:810D:300:74AC:FE9E:A0C8:FC7A:34DB 14:52, 31. Mär. 2022 (CEST)

Das stimmt, wenn der Datentyp unsigned char ist (habe ich übersehen), sollte man die 1-Byte-Konstante 0x1b verwenden.

In Advanced Encryption Standard hingegen wird die mathematische Multiplikation mit 2 verwendet, das steht ausdrücklich darunter. Das Ergebnis ist also 9 Bit lang, und die Verknüpfung mit 0x11b löscht das neunte Bit, damit man es nicht explizit per modulo-Division durch 256 entfernen muss. --Megatherium (Diskussion) 18:29, 31. Mär. 2022 (CEST)