Diskussion:Advanced Encryption Standard

Automatische Archivierung

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 1000 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 8 Abschnitte. Das aktuelle Archiv befindet sich unter Archiv/1.

Automatische Archivierung

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 365 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 8 Abschnitte. Die Archivübersicht befindet sich unter Archiv.

Sicherheit

Am Ende des Abschnitts Weitere Angriffe steht "... denn AES bleibt weiterhin praktisch berechnungssicher." Sollte diese Aussage über die Sicherheit nicht bereits in der Einleitung erwähnt werden? Ich denke, dass viele Leser des Artikels sich ausschließlich über die Sicherheit des AES-Schlüssels informieren wollen und nicht über die technischen Hintergründe. Deshalb sollte eine solch zentrale Aussage nicht so weit hinten stehen.--89.204.137.102 15:46, 26. Mai 2012 (CEST)

Ich schließe mich dem Wunsch an: Inzwischen wird in der Einleitung zwar auf die Zulassung in den USA von AES-192 und AES-256 für Dokumente mit höchstem Geheimhaltungsgrad hingewiesen. Hinweise auf die Sicherheitsempfehlungen des BSI würden das aber für deutsche Leser sicher abrunden. Nach meinem Verständnis wird danach wohl auch AES 128 für Zeiträume bis > 2030 als sicher eingeschätzt (https://www.keylength.com/en/8/).

Auch wäre es für mich interessant zu erfahren, was heute (10 bis 20 Jahre später) aus den einzelnen Angriffs-Ansätzen geworden ist. Insbes. aus der Komplexitätsreduzierung auf rund 100 Bit (Courtois und Pieprzyk, 2002).--ULupus (Diskussion) 11:54, 22. Dez. 2020 (CET)

Modi

Haltet ihr es für angebracht eventuell noch einen Abschnitt über die wichtigsten Modi mit einzubauen? (CTR, CBC, ECB (eben weil er unsicher ist))--2001:638:804:1FF:0:0:0:10 22:05, 12. Dez. 2014 (CET)

Habe einen Satz mit einem Verweis auf das entsprechende Lemma eingefügt. Das sollte denke ich ausreichen. (nicht signierter Beitrag von 2A02:8070:63D1:1B00:1145:D3D4:BF77:260A (Diskussion) 17:40, 23. Dez. 2020 (CET))

Der letzte Satz

Der letzte Satz, d.h.

"Im März 2012 wurde bekannt, dass die NSA in ihrem neuen Utah Data Center neben dem Speichern großer Teile der gesamten Internetkommunikation auch mit enormen Rechenressourcen an dem Knacken von AES arbeiten wird.[14] Die Eröffnung des Rechenzentrums läuft schrittweise seit September 2013.[15]"

ist nicht richtig. Dies wurde nicht bekannt. Genauer: In dem ersten Artikel wird AES zwar erwähnt. Diese Erwähnungen sind jedoch nicht in einem der Zitate. Es sind, auch wenn man die Zitate in dem Artikel für bare Münze nimmt, Aussagen des Autors. Es gibt keinen Hinweis darauf, dass der Autor hier eine relevante Information bezüglich AES wiedergibt. Der Autor sagt noch nicht einmal selbst, dass NSA wirklich versucht, AES zu brechen. In diesem Sinne schreibt er auch zweimal "like AES". In dem zweiten Artikel wird AES noch nicht einmal erwähnt. (nicht signierter Beitrag von 2001:638:902:2001:C23F:D5FF:FE6B:33A6 (Diskussion | Beiträge) 10:19, 4. Dez. 2015 (CET))

Nachschlüssel/"Dietrich" für Geheimdienste?

Der Aspekt von bei der Algorithmus-Entwicklung erschaffenen Hintertürchen bzw. möglichen Nachschlüsseln/Dietrich etc. fehlt komplett. Solche Möglichkeiten waren in der öffentlichen Diskussion Ende 90er Anfang 2000er Jahre bzw. zu Beginn der Regierungszeit von G.W.Bush!

Wurden Solche Möglichkeiten umgesetzt? (nicht signierter Beitrag von 188.110.249.239 (Diskussion) 10:10, 18. Aug. 2016 (CEST))

Nein. Der ALgorithmus wurde, bevor er als Standard akzeptiert wurde, von diversen Kryptographieexperten begutachtet. Es gab damals einen Wettbewerb und dieser Algorithmus hat ihn gewonnen.--2A02:8070:63D1:1B00:1145:D3D4:BF77:260A 17:35, 23. Dez. 2020 (CET)

@188.110.249.239 AES hat keine Hintertür und es zeigt sich auch in den Nachrichten, dass die Behörden keine solche für AES nur haben, denn die haben reichlich Probleme mit Chats (siehe XMPP's OTR zb) oder Festplatten (siehe Veracrypt oder das Linux-Modul dm-crypt), die es nutzen. --Kerostera (Diskussion) 12:26, 8. Mär. 2024 (CET)

Schlüssellängen

In der Ursprünglichen Version waren weniger Schlüssellängen vorgesehen. 160 und 224 Bit Schlüssel wurden erst in V 2 eingeführt , siehe Ab. 4 https://csrc.nist.gov/csrc/media/projects/cryptographic-standards-and-guidelines/documents/aes-development/rijndael-ammended.pdf (nicht signierter Beitrag von 93.204.128.135 (Diskussion) 23:12, 11. Dez. 2019 (CET))

AES mit 128-Bit-Schlüssel in der höchsten Geheimhaltungsstufe NICHT zugelassen.

Das entnehme ich jedenfalls dem Artikel. --Franz Scheerer aus Wiesbaden (Diskussion) 10:55, 1. Feb. 2023 (CET)

Das Problem, ein Passwort, das sich ein Mensch gut merken kann mit 128-Bits ist zu kurz und AES ist mit spezieller Hardware, ähnlich wie der DES extrem schnell. --Franz Scheerer aus Wiesbaden (Diskussion) 11:04, 1. Feb. 2023 (CET)

Daher ist eine Stromchiffre ähnlich RC4 besser, weil das Verfahren mit spezieller Hardware nicht wesentlich beschleunigt werden kann. Es können praktisch beliebig lange Passwörter verwendet werden, so dass extrem hohe Sicherheit erreicht werden kann. --Franz Scheerer aus Wiesbaden (Diskussion) 11:09, 1. Feb. 2023 (CET)

Unabhängig von der Schlüssellänge hindert einen nichts daran, ein beliebig langes Passwort zu wählen. Man nutzt in der Regel eine Schlüsselableitungsfunktion zum berechnen des AES-Schlüssels aus dem PW. Ist dieses genügend lang und nicht zu regelmäßig, hat man auch die volle Entropie von 128 bit. Aber für die höchste Geheimhaltungsstufe fordert man offenbar mehr als 128 bit Entropie.--Megatherium (Diskussion) 13:06, 1. Feb. 2023 (CET)

Ach - Schlüsselableitungsfunktion - ich würde MD5 benutzen. --Franz Scheerer aus Wiesbaden (Diskussion) 17:42, 1. Feb. 2023 (CET)

Ich würde lieber Argon2 benutzen. --Megatherium (Diskussion) 18:11, 1. Feb. 2023 (CET)

Warum nicht RC4 als Zufallsgenerator. Die ersten 1000 Bytes Output können verworfen werden (RC4-drop(1000)). --Franz Scheerer aus Wiesbaden (Diskussion) 19:30, 1. Feb. 2023 (CET)

Der Nachfolger Spritz ist noch besser. Er wurde fast zeitgleich zu Argon2 entwickelt. --Franz Scheerer aus Wiesbaden (Diskussion) 19:38, 1. Feb. 2023 (CET)

Siehe da, ein europäisches Verfahren. --Franz Scheerer aus Wiesbaden (Diskussion) 19:35, 1. Feb. 2023 (CET)

Die Wahrheit ist, es vollkommen egal, welche Schlüsselableitung wir exakt verwenden. Wenn das Verfahren nicht bekannt ist (in allen Details), ist die Verschlüsselung unknackbar, auch mit AES-128. --Franz Scheerer aus Wiesbaden (Diskussion) 12:58, 5. Feb. 2023 (CET)

Ganz allgemein könnten die Rundenschlüssel bei jeder Blockverschlüsselung, Feistelchiffre und Anderen mit einen Schlüsselexpansion berechnet werden. Wenn dieser Teil des Verfahrens geheim ist, kann die Chiffre niemals geknackt werden. --Franz Scheerer aus Wiesbaden (Diskussion) 13:05, 5. Feb. 2023 (CET)

Allerdings beim Cipher Block Chaining Mode oder anderen sicheren sicheren Anwendungen der Blockchiffre, Nicht bei Electronic Code Book Mode! --Franz Scheerer aus Wiesbaden (Diskussion) 13:08, 5. Feb. 2023 (CET)

Pragmatisch sicher

Das Verfahren ist pragmatisch sicher, (...)

Ist das ein gängiger Fachbegriff? Es geht vermutlich um das englische computationally secure, was ich eher als rechnerisch sicher übersetzen würde. Diese Quelle nennt als Übersetzungen komplexitätstheoretisch sicher und berechnungssicher. Abseits davon würde ich von praktisch sicher sprechen, aber pragmatisch sicher erscheint mir gefühlt nicht richtig. --Matthäus Wander 17:02, 1. Jan. 2025 (CET)