Diskussion:Advanced Encryption Standard/Archiv/1

aus Wikipedia, der freien Enzyklopädie

Abschnitt „Weblinks“

Sollte man nicht die Software-Links getrennt von den anderen Links aufführen?

Ich habe alle Links zu Software gelöscht, da ich diese für unsinnig halte. Wenn wir hier Links zu Software präsentieren, dann sollte diese eingehend analysiert sein. --Stefan Birkner 11:21, 23. Apr. 2007 (CEST)

Was willst Du denn im Fall der GPL-/OpenSource-Software eingehend analysieren? Der Quellcode liegt doch offen und zumindest im Fall von TrueCrypt und Gpg4win handelt es sich um seit Jahren in der CryptoSzene be- und aner-kannte Software. Auch die Steganos-Verschlüsselungssoftware kann IMHO ohne Bedenken empfohlen werden. Ich plädiere also dafür, zumindest Software-Links bewährter Software in einer eigenen Sektion namnes "Software" wieder aufzunehmen.

Wenn du eindeutige, nachprüfbare Kriterien nennst, bei deren Erfüllen Software in den Artikel aufgenommen werden soll, dann ist das ok. --Stefan Birkner 16:13, 30. Apr. 2007 (CEST)

Vorschlag für Kriterien, bei deren Erfüllen Software in den Artikel aufgenommen werden soll:

  1. Kostenlos für Privatanwender. (Somit erfolgt keine Werbung für kommerzielle Software.)
  2. Quellecode muss einsehbar sein. (Überprüfbarkeit)
  3. Software muss AES-256 unterstützen. (Sicherheitsmindeststandard)
  4. Evtl. auch noch: Software muss besonders einfach oder besonders sicher sein.
Vorschlag für Kriterien für "besonders einfach":
  • Mindestens eines der folgenden Kriterien muss erfüllt sein:
  • Software ist ohne Installation direkt ausführbar. (So kann sie z.B. vom USB-Stick aus gestartet werden und sollte auch ohne Administrator-Rechte ausführbar sein.)
  • Verschlüsselte(s) Datei (bzw. Dokument) ist ohne Software (- vorausgestzt, man hat das richtige Passwort -) entschlüsselbar.
  • Ver- & Entschlüsselung mehrerer Dateien über das Kontextmenü des Windows-Explorers bei Eingabe eines einzigen Passworts möglich.
  • Ist bereits in hybrider Verschlüsselungssoftware enthalten.
Vorschlag für Kriterien für "besonders sicher":
  • Mindestens eines der folgenden Kriterien muss erfüllt sein:
  1. Verschlüsselte/r/s Datei/Container/Volume kann nicht erkannt werden, da sie/er/es keinen eigenen Kopfdatenbereich hat und nur aus zufälligen Bitfolgen zu bestehen scheint. Sie/er/es ist damit von normalen Dateien bzw. Partitionen voller Zufallszahlen nicht zu unterscheiden.
  2. Versteckte Container (Hidden Volumes) können innerhalb des freien Speicherplatzes eines anderen verschlüsselten Volumes versteckt werden.
  • Ist in hybrider Verschlüsselungssoftware enthalten und kann somit in Kombination mit zufällig gewählten Einwegpasswörtern und mit dem hybriden Verschlüsselungsverfahren eingesetzt werden. (Das Einwegpasswort der AES-Verschlüsselung ist so auf sicherem Weg übermittelbar, die asymmetrisch verschlüsselte Datei besteht nur aus einer pseudo-zufälligen Anhäufung von Zeichen und ist somit besonders schwer zu knacken und der AES-Schlüssel wechselt von Mal zu Mal, was die AES-Verschlüsselung besonders schwer zu knacken macht.)

-- SETI@home 20:27, 1. Mai 2007 (CEST)

Nach deinen Kriterien kann ich problemlos ein Programm einstellen, dass kryptografisch nicht sicher ist. Auch wenn der Quellcode einsehbar ist, heißt das noch nicht, dass er richtig ist. Ich sehe auch nicht den Sinn darin, Software aufzunehmen. Jeder kann selbst im Internet nach entsprechender Software suchen. --Stefan Birkner 11:59, 2. Mai 2007 (CEST)


Vorweg: "Suchen" heißt noch lange nicht "finden".

Du sagst, Du siehst keinen Sinn darin, Software hier aufzunehmen. Ich sehe da aber Sinn darin, Software hier aufzuführen (und offensichtlich bin ich nicht der einzige, der darin Sinn sieht. Schließlich war hier von anderen Mitwirkern dieses Wikipedia-Artikels bereits Software aufgenommen - und das, noch bevor ich überhaupt die Frage nach der Trennung zwischen den Softwarelinks und den anderen Links gestellt hatte und Du, durch diese Frage auf die bereits aufgeführten Softwarelinks aufmerksam gemacht, diese Links wieder entfernt hattest). Dass jeder nach entsprechender Software suchen kann, ist m.E. erstens sachlich nicht ganz korrekt, da manche Anwender mit der Anwendung einer Suchmaschine schlichtweg überfordert sind, anderen Anwendern wiederum - z.B. Kindern & Jugendlichen, die nur Zugriff auf von Erziehern/Sorgeberechtigten freigeschaltete Seiten haben - der Zugriff auf Standardsuchmaschinen verwehrt bleibt, ferner die hohe Trefferzahl bei der Suche nach entsprechender Software dem Anwender, der nach solcher Software sucht, keine Hilfe sein dürfte, desweiteren man m.E. unter den wenigsten Treffern tatsächlich AES-Verschlüsselungssoftware - geschweige denn gute AES-Verschlüsselungssoftware findet, und zweitens ist es m.E. kein Argument, dass sich Elemente einer vorgeschlagenen Liste auch im Internet suchen (bzw. finden) lassen. Mit der Argumentation wäre m.E. ein Großteil der weltweit existierenden Wikipedia-Artikel unberechtigt und überflüssig, da sich die entsprechenden Quellen i.d.R. im Internet suchen und finden lassen. Ich mache ja meine Vorschläge bzgl. eines Kriterienkatalogs für derartige Software, damit sich die Liste der diesen Kriterien entsprechende Software eben von dem unterscheidet, was man sonst im Internet aufgelistet bekommt.

Evtl. wäre es ja ein guter Kompromiss, für eine solche Auflistung eine eigene Wiki-Seite namens "Liste von AES-Verschlüsselungsoftware" oder ähnlichem Namen zu erstellen und diese Seite ggf. hier im Artikel (unter "Weblinks") zu verlinken.

Hier noch ein weiterer Vorschlag für die Kriterien:

  1. Kostenlos für Privatanwender. (Somit erfolgt keine Werbung für kommerzielle Software.)
  2. Quellecode muss einsehbar sein. (Überprüfbarkeit)
  3. Software muss unter GPL-Lizenz stehen oder es muss sich zumindest um freie Software handeln. (Grundlage für Verbesserungen durch eine Entwicklergemeinschaft & rechtliche Garanatie, dass der Quellcode einsehbar ist)
  4. Software muss in einem Projekt, an dem jeder mitmachen darf, ständig weiterentwickelt werden. (Überwachung der Software durch die Gemeinschaft)
  5. Evtl. auch: Projekt muss auf bekannter Projektseite wie sourceforge.net gehostet sein.
  6. Software muss AES-256 unterstützen. (Sicherheitsmindeststandard)
  7. Evtl. auch noch: Software muss besonders einfach oder besonders sicher sein. (Wie man "einfach" und "besonders sicher" näher eingrenzen könnte, habe ich ja oben bereits versucht, anzuführen.)

Im Übrigen würde ich es begrüßen, wenn Du Dich an dem Kriterienkatalog (ganz im Sinne Deiner Aussage vom 30. April 2007) beteiligen würdest, wenn Dir die vorgeschlagenen Kriterien nicht zusagen. Ein kategorisches Ablehnen des Gedankens einer von mir angestrebten Softwareauflistung würde ich sehr bedauern. Auch alle anderen dürfen sich übigens eingeladen fühlen, sich bei der Erstellung dieses Kriterienkatalogs zu beteiligen. SETI@home 12:12, 12. Mai 2007 (CEST)

Ich habe kein Verständnis dafür, dass Du die Softwareliste gelöscht hast, Stefan. Wer in der Wikipedia einen Artikel über einen Softwarestandard liest, erwartet dort auch eine Liste von Implementierungen. Ein Standard ist doch nichts ohne seine Anwendung, und eine unvollständige Enzyklopadie ist auch Käse. Ich bin sogar dafür, eine Softwareliste ohne Kriterien aufzunehmen (oder meinetwegen mit wenigen). Wenn jemand kryptographische Software verwendet, muss er sich sowieso im klaren darüber sein, was er tut, und dazu gehört auch, sich über die Qualität der Implementierung zu informieren, wenn man sie erst einmal gefunden hat. --Hok 17:35, 8. Nov. 2007 (CET)

Die Wikipedia ist kein Softwarekatalog. Solche gibt es zuhauf im Netz und wer bei Google nach AES sucht wird auch entsprechende Programme finden. Vollständigkeit ist bei einer Enzyklopädie nicht möglich. Bei einer Auflistung von wahrscheinlich mehr als hundert Implementierungen würde vor allem die Übersichtlichkeit des Artikels leiden. --Stefan Birkner 22:40, 12. Nov. 2007 (CET)

MixColumn

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

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))

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)

Unvollstaendiger Satz

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)
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)

Blockchiffre Repetitionen bei bekanntem Klartext

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)

soviel ich weis ist das nicht teil der AES-Spezifikation ob der ECB Modus, bei dem das von dir beschriebene Muster auftritt, oder CBC oder ganz andere wie CFB benutzt werden. Diese Verfahren können ja bei jeder Block Chiffre angewendet werden und es ist kein Problem zum Beispiel CBC mit AES zu verwendden. Der AES spezifiziert das nicht weiter, und das ist auch sinnvoll so. Wenn man nur kurze Nachrichten quasizufälligen Inhalts versendet, der sich sehr sicher nicht wiederholt dann ist ECB einfach schneller, CBC verschleiert natürlich mehr. Ausserdem lässt sich CBC schön parallelisieren CBC aber nicht --MyChaOS 19:59, 19. Nov. 2008 (CET)

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), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Arbeitsweise --> S-Box

"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)
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)

Zukünftige Entwicklung von AES

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)

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)

Implementierungen

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

Habe den Abschnitt Implementierungen nochmal um C# /.NET und Delphi erweitert Omikronn 04:06, 16. Nov. 2009 (CET)

256 Bit AES vs. 128 Bit AES

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))

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)

Hintertüren?

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)

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)
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)
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)
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)

Beleg fuer Angriff im 2. Absatz

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)

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)

Quellenangabe

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)

Puh, so weit ich das verstehe wurde er ja genau dafür entwickelt.--Antemister (Diskussion) 10:36, 10. Apr. 2013 (CEST)
ich habe den nachweis eingefuegt. --Mario d 11:40, 10. Apr. 2013 (CEST)

Beste bekannte Kryptoanalyse

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)

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)

AES-verschlüsselte Kennworte in Datenbanken

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)

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)

Artikelherkunft

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)

Magenta einbauen

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)

Aus meiner Sicht hat das hier nichts zu suchen. Magenta ist schlecht und abgehakt. --Qbi 21:22, 19. Okt. 2005 (CEST)
Einverstanden. Die Idee ist nach meinen jüngsten T-Erfahrungen geboren. Und vergessen.--Psycho Chicken 07:45, 20. Okt. 2005 (CEST)

Historie von DES

Mathematisch ist die Permutationsgeschichte um DES sehr interessant. Kein Platz hier, zu speziell. Data-Geyer (nicht signierter Beitrag von 84.133.184.200 (Diskussion) 14:01, 7. Feb. 2006 (CET))

Entstehung

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? (nicht signierter Beitrag von 80.136.197.116 (Diskussion) 21:17, 26. Mär. 2008 (CET))

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)

Schlüssel und Blocklänge

sehr schön Benutzer:OttTheTormentor hat die korrekten Blocklängen von Rijndael in das Dokument aufgenommen. (nicht signierter Beitrag von 141.76.176.56 (Diskussion) 19:14, 19. Feb. 2007 (CET))

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 ??? (nicht signierter Beitrag von 217.224.6.200 (Diskussion) 17:04, 22. Feb. 2007 (CET))
"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? (nicht signierter Beitrag von 84.176.18.82 (Diskussion) 20:09, 22. Apr. 2007 (CEST))
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)

Timing Attacken

Zu AES scheint es in vielen Implementierungen Timing-Attacken zu geben: http://cr.yp.to/papers.html#cachetiming (nicht signierter Beitrag von 58.165.246.226 (Diskussion) 08:29, 24. Apr. 2007 (CEST))

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)

Archivierung dieser Diskussionsseite

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)

Exportbeschränkungen?

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)

Unverständliche Einleitung

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

Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Advanced_Encryption_Standard/Archiv/1&oldid=195382826“