Diskussion:Advanced Encryption Standard/Archiv/1

message: Im Artikel heißt es:
"Die Konstante wird folgendermaßen bestimmt:
Zeile 1: 2
Zeile 2: 3
Zeile 3: 1
Zeile 4: 1"
Das ist so nicht korrekt. Die Konstante ist für jedes Feld der Matrix unterschiedlich. Die hier angegebenen Werte sind die der ersten Zeile.
Richtig ist die Matrix
2	3	1	1
1	2	3	1
1	1	2	3
3	1	1	2
Diese wird dann von links mit der Matrix die durch ShiftRow ermittelt wurde multipliziert. Und zwar in \mathbb F_{2^8}
Quelle z.B. http://www.realtec.de/privat/files/AES_Krypto_Seminar.pdf (nicht signierter Beitrag von 134.2.187.27 (Diskussion) 2007-09-18, 17:22:23)
- Ich habe einen potentiellen Fehler gefunden ! (?)
In der Definition der Multiplikation für den Fall a >= 2^7 wird a*2 XOR 0x11b beschrieben. Im tiefergehenden verlinkten Artikel zu den Rijndael MixColumns (oder auch hier: http://www.codeplanet.eu/tutorials/cpp/3-cpp/51-advanced-encryption-standard.html#aes_description_description) wird jedoch die Konstante 0x1b Hex verwendet. Hier hat sich wohl ein Tippfehler eingeschlichen? (nicht signierter Beitrag von 80.128.55.37 (Diskussion) 11:27, 4. Mai 2013 (CEST)
replies: text: Nein. Das ist kein Tippfehler. Im mathematischen Sinne korrekt ist 0x11b, um in GF256 zu bleiben. Wenn mit 0x1b gearbeitet wird, wird ausgenutzt das das oberste Bit aus dem Byte sowieso raus fällt und nicht durch das XOR auf null gesetzt werden muss. --F. Saerdna (Diskussion) 11:29, 5. Mai 2013 (CEST)
thread_title:   MixColumn  

message: In der rechten Box: "Beste bekannte Kryptoanalyse":
"Eine gewählte Klartextattacke kann 8 Runden von 192 und 256 Bit Schlüssellänge und 7 Runden von 128 Bit Schlüssellänge. (Ferguson et al, 2000)"
:Ja ist mir auch grad aufgefallen. Aber auch der "Satz" darüber ist merkwürdig: "Bezogene Schlüsselattacke auf 9 Runden mit 256 Bit Schlüssellänge.". Ich finde nirgendwo etwas über eine "bezogene Schlüsselattacke", was soll das denn sein?--Sixot 16:46, 3. Okt. 2008 (CEST)
replies: text: Wahrscheinlich eine "gewaltsame" Übersetzung von "related key attack", wobei "related" hier eher mit "verwandt", als mit "bezogen" zu übersetzen wäre. 87.149.72.190 10:50, 9. Okt. 2014 (CEST)
thread_title:  Unvollstaendiger Satz 

message: Ist es bei AES als reiner Blockchiffre nicht so, dass es zu Wiederholungen im Chiffrat kommen muss, wenn ein bekannter Klartext chiffriert wird? Als ich mir neulich eine Implementation ansah und diese mit einem langen String aus Leerzeichen fütterte, hatte ich Repetitionen alle 512 Byte (bei Blockgröße 256 Bit und Schlüsselgröße 256 Bit). 
Mich würde freuen, zu wissen, ob dieses Verhalten der Chiffre so gewollt war. Ich hätte gedacht, dass Rijdael/AES so eine Art Cipher Block Chaining (CBC) oder einen auf andere Weise variablen Initialisierungsvektor ebenfalls schon im Design implementiert hat.
Donalbein 01:49, 12. Mär. 2008 (CET)
replies: text: AES selbst ist kein Kryptosystem, sondern lediglich ein kryptographisches Primitiv, nämlich eine "pseudozufällige Permutation" (nicht "Permutation von Bytes", aber die Abbildung aller möglicher Eingabeblöcke auf alle mögliche Ausgabeblöcke ist eine bijektion und somit eine Permutation, da die Chiffre sonst nicht umkehrbar wäre). Du kannst AES an Stellen, an denen eine pseudozufällige Permutation benötigt wird, in einem Kryptosystem verbauen. Wenn dieses Kryptosystem trivial ist (Etwa: "Initialisiere die pseudozufällige Permutation mit dem Schlüssel. Zerlege die Eingabe in Blöcke, schiebe jeden Block durch die pseudozufällige Permutation, um die Ausgabe zu erhalten."), ist es auch bei Verwendung von AES nicht notwendigerweise "sicher". AES ist ein Primitiv, das Du benutzen kannst, um ein sicheres Kryptosystem darauf aufzubauen. Diese "modulare Denkweise" ist hilfreich, weil es in der Kryptographie häufig um beweisbare Sicherheitseigenschaften geht und einzelne Teilprobleme (wie etwa eine "pseudozufällige Funktion") einfacher zu evaluieren sind, als vollständige Kryptosysteme. Ich finde es auch irreführend, dass Algorithmen wie AES allgemein als "Blockchiffre" bezeichnet werden. AES ist eine pseudozufällige Funktion und diese kann man verwenden, um daraus ein Kryptosystem zu konstruieren. AES selbst ist noch kein Kryptosystem, erst recht kein "brauchbares". Dazu braucht es schon noch etwas mehr. 84.159.210.50 (00:23, 5. Okt. 2014 (CEST)
thread_title:  Blockchiffre Repetitionen bei bekanntem Klartext 

message: "Die S-Box in AES basiert auf einem mathematischen Zusammenhang und ist somit fest im Algorithmus implementiert. [..] da die S-Box lediglich zur Vermischung der Bytes [..] genutzt wird"
Was für ein mathematischer Zusammenhang? Die S-Box sie stellt eine nichtlineare Substition dar und ist somit die Essenz des Algorithmus'. Die Bytes werden hier nicht vermischt, sondern ersetzt - wie der Name Substitution schon sagt.
: Die S-Box lässt sich aus einem mathematischen Zusammenhang berechnen (der meine Mathematik-Kenntnisse leider übersteigt, weshalb ich ihn hier nicht erläutern kann). Das ist wichtig, da bei einer scheinbar "zufällig gewählten" bzw. "vorgegebenen" S-Box ("Hier ist die S-Box! Grund, weshalb die ausgerechnet so aussieht? Gibt keinen! Das ist eben die S-Box! Sieht doch toll aus!") die Möglichkeit bestünde, dass eine Hintertür eingebaut wurde. Deshalb haben die Entwickler des Rijndael nicht einfach 256 Bytes vorgegeben und gesagt "Hier, das ist die S-Box!", sondern eine Berechnungsvorschrift angegeben, wie die S-Box "generiert" werden kann. Außerdem wurde die S-Box (bzw. die Berechnungsvorschrift) so "gewählt", dass die S-Box sehr widerstandsfähig gegen lineare und differentielle Kryptoanalyse ist, ein Designkriterium, das auch bereits der S-Box des DES "innewohnte", deren Entstehungsgeschichte aber soweit ich weiß nie offengelegt wurde. 84.159.210.50 00:04, 5. Okt. 2014 (CEST)
replies: text:  Nachtrag: Auf der englischsprachigen Wikipedia lässt sich nachlesen, wie die S-Box von Rijndael aussieht, wie sie berechnet wird und nach welchen Kriterien sie entworfen wurde. 84.159.210.50 00:08, 5. Okt. 2014 (CEST)
thread_title:  Arbeitsweise --> S-Box 

message: Ist schon was bezüglich AES-512, AES-1024 usw. geplant bzw. wird daran bereits gearbeitet?
-- 134.93.51.36 14:03, 31. Mai 2009 (CEST)
replies: text: Nein. Bevor aufgrund der explodierenden Rechenressourcen noch längere Schlüssel erforderlich werden sollten, wird der Algorithmus längst durch andere Angriffsmöglichkeiten angreifbar sein und ersetzt werden müssen. Es gibt spezielle "Betriebsmodi" (modes of operation) des AES, die längere Schlüssel erlauben und diese auch benötigen, um hinreichend sicher zu sein. Beispielsweise setze ich auf meinen Servern AES-XTS mit einer Schlüssellänge von 512-bit zur Festplattenverschlüsselung (full disk encryption) ein und erreiche damit "geringfügig" höhere Sicherheit, als ein "klassischer" Betriebsmodus (etwa AES-CBC oder AES-CTR, wobei CBC ja in "Verruf" kommt) mit 256-bit es benötigen würde und bin damit (hoffentlich) auch sicherer, als die genannten Algorithmen mit 256-bit Schlüsseln es wären. Würde ich AES-XTS mit einem 256-bit Schlüssel verwenden, läge das Sicherheitsniveau nur "marginal" über dem von AES-CBC oder AES-CTR mit 128 bit. (Wobei das mit dem "geringfügig" und "marginal" natürlich relativ zu sehen ist. Es bezieht sich hier auf "im Vergleich zur exorbitanten Vergrößerung des Schlüsselraums, die normalerweise aus einer Verdoppelung der Schlüssellänge zu erwarten wäre".) Die 256-bit Variante hat man auch hauptsächlich entwickelt, um auch ausreichend "Sicherheitsmarge" zu haben, wenn man, ausgehend von der Publikation des Algorithmus, "in ~30 Jahren", also um das Jahre ~2030 herum, Rechnerarchitekturen hat, die in der Lage sind, den Schlüsselraum mittels des probabilistischen Grover-Algorithmus in sqrt(2^256) = 2^128 Operationen zu durchsuchen. (Die Laufzeit des Grover-Algorithmus wächst nicht linear, sondern lediglich mit der Quadratwurzel der Größe des Schlüsselraums.) Gemäß der Potenzgesetze muss man die Schlüssellängen symmetrischer Verfahren daher verdoppeln, um gegen einen Angreifer, der den Grover-Algorithmus durchführen kann, vergleichbar sicher zu sein. Die 256-bit Variante bietet also gegen den Grover-Algorithmus vergleichbare Sicherheit ("vergleichbar" in "O-Notation"), wie die 128-bit Variante gegen "klassische" Algorithmen. Bislang gibt es keine praktikable Rechnerarchitektur, auf der man den Grover-Algorithmus tatsächlich implementieren könnte, aber das Problem ist "nur noch" ein technisches. Die Mathematik für den Algorithmus ist bereits da. 84.159.210.50 23:30, 4. Okt. 2014 (CEST)
thread_title:  Zukünftige Entwicklung von AES 

message: Hallo, Ich habe mir mal erlaubt den Abschnitt Implementierungen mit mir bekannten links zu erweitern Omikronn 00:51, 13. Nov. 2009 (CET)
thread_title:  Implementierungen 

message: Warum genau ist die 128 Bit AES Verschlüsselung sicherer als die 256 Bit Verschlüsselung? Wird bei der 256 Bit Verschlüsselung das Passwort einfach nur verdoppelt, sodass jedes Zeichen doppelt so oft vorkommt wie in der 128 Bit Verschlüsselung? Bitte eine einfache Erklärung. (nicht signierter Beitrag von 134.76.61.232 (Diskussion) 10:13, 23. Nov. 2010 (CET)
replies: text: AES arbeitet nicht mit Passwörtern, sondern mit Schlüsseln. Wenn mit Passwörtern gearbeitet werden soll, muss man einen Weg definieren, um aus dem Passwort einen Schlüssel abzuleiten. In der Regel bedient man sich hierzu "gesalzener" (salted) kryptographischer Hashfunktionen, es gibt aber auch spezielle "Schlüsselableitungsfunktionen" wie PBKDF2 (the Second Password Based Key Derivation Function), die sich widerum kryptographischer Primitive wie Hashfunktionen bedienen, um aus einem Passwort, möglichst unter Zuhilfename eines Salzes, einen Schlüssel abzuleiten. Natürlich wird bei AES-256 nicht einfach der Schlüssel "verdoppelt", sondern der Schlüsselraum ist tatsächlich erheblich größer. AES-256 "wählt" gewissermaßen eine pseudozufällige Permutation aus 2^256 mögliche Permutationen, anstatt aus "lediglich" 2^128 wie bei AES-128. Aber gegen AES-256 (der intern ein wenig anders arbeitet, unter anderem eine größere Zustandsmatrix besitzt) ist eine Kryptoanalyse bekannt, die effizienter ist, als die effizienteste gegen AES-128. Darum ist AES-256 derzeit "formal schwächer", als AES-128. Das kann sich aber jederzeit ändern (und wird sich wahrscheinlich auch), wenn man den AES-128 genauer analysiert. Man kann nur eben nicht jeden Angriff gegen AES-256 notweidigerweise trivial auf AES-128 übertragen. Deshalb kann es durchaus sein, dass die Variante mit dem längeren Schlüssel zeitweise "formal schwächer" (da bessere Angriffsmöglichkeit bekannt) ist, als die mit dem kürzeren Schlüssel. 84.159.210.50 23:43, 4. Okt. 2014 (CEST)
thread_title:  256 Bit AES vs. 128 Bit AES 

message: Verschwörungstheoretiker unterstellen AES immer und immer wieder geplante Hintertüren bzw. merken an, die NSA habe doch viel, viel bessere Techniken, weil die doch nie ihr bestes Verschlüsselungssystem offenlegen würden. Das alles erscheint mir völlig unglaubwürdig, ihre eigenen Methoden zu sabotieren? Gibt es denn in auch nur ansatzweise Informationen dazu?--Antemister (Diskussion) 23:25, 24. Mär. 2012 (CET)
replies: text: was fuer informationen meinst du? das sind ja nur wilde spekulationen, es gibt keinen grund dafuer, sich in dem artikel damit auseinanderzusetzen. seit fast 15 jahren beschaeftigen sich die besten kryptoanalytiker der welt damit und haben noch keine ernsthafte schwaeche gefunden. --Mario d 11:12, 25. Mär. 2012 (CEST)
replies: text: Das irgendjemand, der nicht Verschwörungstheoretiker ist, die Möglichkeit dass es Hintertüren  geben könnte, irgandwann einmal in betracht gezogen. Ich glaube das ja nicht, aber viele solche Verschwörungstheorien basieren ja auf einer sehr kreativen Interpretation seriöser Publikationen.--Antemister (Diskussion) 11:25, 25. Mär. 2012 (CEST)
replies: text: ich kann mir nicht vorstellen, dass das in irgendeiner serioesen publikation mal angeklungen ist. die NSA war bei der entwicklung des AES ueberhaupt nicht beteiligt, das waren zwei belgier. vielleicht meinst du den DES? nicht, dass die spekulationen da mehr substanz haetten. --Mario d 15:42, 25. Mär. 2012 (CEST)
replies: text: Rijndael wurde, wie bereits erwähnt, von zwei belgischen Kryptologen (Rijmen und Daemen) entwickelt und vom amerikanischen NIST (nicht NSA) zum AES "ausgewählt". Nunja, das stimmt nicht ganz. AES ist gewissermaßen eine "Untermenge" von Rijndael. Rijndael kann alles, was AES kann, aber Rijndael kann mehr. AES ist Rijndael, das auf die geringste Blocklänge von 128 bit "beschnitten" wurde (Rijndael unterstützt Blocklängen bis 256 bit) und zudem nur noch 3 unterschiedliche Parametrisierungen erlaubt (von Rijndael selbst gibt es 25 verschiedene Varianten). Abgesehen von diesen Einschränkungen sind die Algorithmen identisch. Die USA hatten übrigens Bedenken, dass ein Algorithmus, der aus dem Ausland kam, zum AES "gewählt" wurde. In der restlichen Welt dürfte dies Gefallen gefunden haben, schließlich ist eine Hintertür weniger Wahrscheinlich, wenn "Kurator" (NIST, USA) und "Entwickler" (Rijmen und Daemen, Belgien) aus unterschiedlichen Nationen stammen. Die NSA hat den AES allerdings, nach seiner "Wahl", untersucht und für Regierungsdokumente höchster Geheimhaltung "freigegeben", d. h. die US-Regierung verschlüsselt inzwischen selbst mit AES. 84.159.210.50 23:58, 4. Okt. 2014 (CEST)
thread_title:  Hintertüren? 

message: Im zweiten Absatz wird ausgesagt, dass erst nach 10 Jahren ein Angriff gefunden wurde, aber weder wird der Angriff benannt noch eine Quelle zitiert. Ein Verweis auf den entsprechenden Angriff in der Sektion Schwaechen und Angriffe sowie ein Beleg mit Quellenangabe waeren hier sicher sinnvoll --Cornim (Diskussion) 09:59, 29. Nov. 2012 (CET)
replies: text: das bezieht sich auf den Advanced Encryption Standard#Biclique-Angriff, der koennte aber sicher noch prominenter erwaehnt werden. --Mario d 13:03, 29. Nov. 2012 (CET)
thread_title: Beleg fuer Angriff im 2. Absatz

message: Im letzten Satz der Einleitung steht: "AES ist in den USA für staatliche Dokumente mit höchster Geheimhaltungsstufe zugelassen." Gibt es dazu einen zitierbaren Nachweis? Woher ist bekannt, dass die USA für die Einstufung Top Secret dieses Verfahren zugelassen haben? --80.156.43.136 09:01, 10. Apr. 2013 (CEST)
replies: text: Puh, so weit ich das verstehe wurde er ja genau dafür entwickelt.--Antemister (Diskussion) 10:36, 10. Apr. 2013 (CEST)
replies: text: ich habe den nachweis eingefuegt. --Mario d 11:40, 10. Apr. 2013 (CEST)
thread_title:  Quellenangabe 

message: Rechts in der Box steht, dass die beste bekannte Kryptoanalyse noch über 2^100 Schritte braucht jeweils.
Aber weiter unten steht doch: 
"Ende 2009 wurde mit einer Verbesserung des Angriffs eine Komplexität von nur noch 2^99,5 erreicht."
Das müsste man doch oben eintragen oder? Und dann steht danach noch der Satz:
"Für die Praxis hat dieser Angriff jedoch wenig Relevanz, denn AES bleibt weiterhin praktisch berechnungssicher."
Aber ohne jegliche Quelle. Da wäre es gut, wenn man eine Einschätzung von Experten oder etwas aus der Literatur dazu hat, weil dem Wiki-Satz einfach blind zu vertrauen ist an der Stelle irgendwie ungünstig. 46.237.211.42 21:35, 27. Mär. 2014 (CET)
replies: text: die einschaetzung findet sich im selben paper wie der angriff. in die box kommen nur angriffe in realistischen modellen, sie soll ja einen ueberblick ueber die staerke des verfahrens gehen. --Mario d 09:56, 28. Mär. 2014 (CET)
thread_title:  Beste bekannte Kryptoanalyse 

message: Was nützt eigentlich die Verschlüsselung eines Passwort einer DB, wenn die Client-Software das Passwort per default (!) in einer Konfigurationsdatei auf dem PC speichert? Und wenn diese Einstellungen dann zusätzlich auch noch für die Verwendung an einem anderen rechner des Nutzers manuell ex- und importiert werden können? Auch wenn das Passwort gehasht ist (wie bei Oracle SQL Developer): wenn ich diese Einstellungen einfach an einem Drittrechner übernehme, stört das doch den Client nicht - und die abgefragte DB schon mal gar nicht!? Wo ist der Fehler?--Mideal (Diskussion) 17:12, 9. Jun. 2015 (CEST)
replies: text: Der Fehler ist dass in Passwort-Datenbanken in der Regel keine "verschlüsselten Passwörter" gespeichert sind, sondern "gesalzene Passwort-Hashes". Somit ist deine Frage hier off-topic, da sie nicht der Verbesserung des Artikels dient. --RokerHRO (Diskussion) 21:00, 9. Jun. 2015 (CEST)
thread_title:  AES-verschlüsselte Kennworte in Datenbanken 

message: Dieser Artikel (zumindest die ursprüngliche Form) war ein Referat von mir und befindet sich auch auf meiner Homepage: http://www.korelstar.de/aes.php -- Korelstar 13:09, 4. Jan. 2004 (CET)
thread_title: Artikelherkunft

message: Wie könnte man wohl, -ohne, dass es zu sehr stört-, die  Magenta-Pleite mit einbauen.., immerhin ein deutsches Qualitätsprodukt... usw. --Psycho Chicken 20:36, 19. Okt. 2005 (CEST)
replies: text: Aus meiner Sicht hat das hier nichts zu suchen. Magenta ist schlecht und abgehakt. --Qbi 21:22, 19. Okt. 2005 (CEST)
replies: text: Einverstanden. Die Idee ist nach meinen jüngsten T-Erfahrungen geboren. Und vergessen.--Psycho Chicken 07:45, 20. Okt. 2005 (CEST)
thread_title: Magenta einbauen

message: Zwar kann man mittels einer dreifachen Anwendung von DES, genannt 3DES, die effektive Schlüssellänge [von 56 bit] auf 112 Bit steigern, jedoch geht dies sehr zu Lasten der Geschwindigkeit.
wieso steigert die 3fache anwendung des algorithmus die effektive schluessellaenge nur um den faktor 2? fehler? oder hab ich da was nicht verstanden? 
Siehe Seite zu DES, anscheinend unterscheidet sich die effektive Schlüssellänge von verwendeten Schlüssellänge. Wusste ich auch nicht.--Rolandmamie 13:27, 3. Aug. 2008 (CEST)
thread_title: Entstehung

message: sehr schön Benutzer:OttTheTormentor hat die korrekten Blocklängen von Rijndael in das Dokument aufgenommen. 
:hat er ? Sry, aber mich hat das verwirrt: 
:Der Rijndael-Algorithmus besitzt eine variable Blockgröße von 128, 192 oder 256 Bit und eine variable Schlüssellänge von 128, 192 oder 256 Bit. Rijndael bietet ein sehr hohes Maß an Sicherheit. Das Verfahren wurde eingehenden kryptoanalytischen Prüfungen unterzogen. AES schränkt die Blocklänge auf 128 Bit ein, während die Wahl der Schlüssellänge von 128, 192 oder 256 Bits unverändert übernommen worden ist. Anhand der Schlüssellänge wird zwischen den drei AES-Varianten AES-128, AES-192 und AES-256 unterschieden.
:AES ist doch Rinjndael ??? 
::"AES ist doch Rinjndael ???"
::Nein, AES ist ein Standard und Rijndael ein Algorithmus, der diesem Standard entspricht bzw. zum Standard erklärt worden ist. Rijndael als AES-Standard ist jedoch gegenüber den Möglichkeiten des Rijndael-Algorithmus eingeschränkt. Die Bedingungen der Blocklänge von 128 Bit waren vom NIST vorgegeben. Rijndael selbst unterstützt zwar variable Blockgrößen von 128, 192 oder 256 Bit, aber die Blocklänge wurde auf 128 Bit eingeschränkt um diesen Bedingungen zu entsprechen.
::Jetzt klarer? 
:::Rijndael unterstützt sowohl 5 verschiedene Schlüssellängen, als auch 5 verschiedene Blocklängen, und somit insgesamt 25 verschiedene "Konfigurationen". AES ist eine "Untermenge" von Rijndael und unterstützt 3 verschiedene Schlüssellängen und nur eine einzige Blocklänge. Wenn Rijndael auf die Parameter von AES konfiguriert wird, sind die beiden Algorithmen identisch. Rijndael ist jedoch "mehr", als AES. Rijndael "kann" Dinge, die der AES nicht "kann". 84.159.210.50 00:16, 5. Okt. 2014 (CEST)
thread_title: Schlüssel und Blocklänge

message: Zu AES scheint es in vielen Implementierungen Timing-Attacken zu geben: http://cr.yp.to/papers.html#cachetiming 
: allgemein wäre es meiner Meinung nach angebracht, einen Abschnitt "Schwächen" aufzuführen (bei den allermeisten Krypto-Algo-Artikeln scheint das gegeben und es ist finde ich wichtig). Dabei wären praktische, aber auch theoretische Schwächen interessant (sollten keine relevanten Schwächen bekannt sein - dann kann man das ja auch aufführen ^^) --Axel Wagner 04:39, 10. Jun. 2007 (CEST)
thread_title:  Timing Attacken 

message: So lang und unübersichtlich scheint mir diese Diskussionsseite noch nicht zu sein, als dass man hier ein Archiv benötigt. Ich habe deshalb die automatische Archivierung wieder rausgenommen. --CruZer (Disk. / Bew.) 15:59, 22. Jul. 2008 (CEST)
thread_title:  Archivierung dieser Diskussionsseite 

message: Welche Exportbeschränkungen meint SUN, dass sie die maximale Schlüssellänge in Java auf 128bit begrenzen? --87.123.86.97 03:54, 16. Sep. 2009 (CEST)
thread_title:  Exportbeschränkungen? 

message: Die Einleitung genügt nicht WP:OMA. --217.50.204.222 18:23, 4. Dez. 2010 (CET)
thread_title:  Unverständliche Einleitung 

message: "Schließlich werden die Spalten vermischt." Liest sich für mich als handele es sich um eine Spaltentransposition was ja nicht der Fall ist. Spalten bleiben ja gleich nur ihr Inhalt ändert sich. Vieleicht fällt jemandem ja ne schönere Formulierung ein, mir leider nicht. 2.204.215.63 (23:51, 18. Jan. 2011 (CET)
thread_title:   MixColumn verwirrend