AES: Test und Meinung
-
Ja, AnsiString hat diese Methode.
-
Na dann?
cheers, Swordfish
-
Versuchen werd ich's definitiv.
Nur ob ich es schaffe.
-
Hi
Auch wenn das Thema seeehr alt ist, habe ich einige Fragen bzw. Anmerkungen:1.) Ab einer bestimmten Schlüssellänge crasht die Klasse bei mir (habe es mit 60 Zeichen und 10 Zeichen getestet, bei 60 crasht es).
2.) Woher weiß ich, wie groß der Buffer sein muss? Wenn ich das recht sehe, brauche ich z.B. für einen 18-stellen Langen String zum verschlüsseln 2 Blocks (also 32 Byte, richtig?). Muss der Buffer jetzt 32 Bytes groß sein, oder reichen 18?!Gruß
-
So sieht jedenfalls keine effiziente AES-Implementierung aus. Ich finde aber leider auch nicht mehr die Veröffentlichung, in der schön erklärt wurde, wie man Ver- und Entschlüsselung schnell mit jeweils vier 32-bittigen Lookuptabellen der Größe 256 erschlagen kann (Te0,Te1,Te2,Te3 und Td0,Td1,Td2,Td3). Die Referenz-Implementierung von 2000 verwendete auch schon diesen Trick.
Ja, es ist lustig, das mal alles selbst zu implementieren. Habe ich auch schon gemacht, damals in Java. Es dann aber für sicherheitskritische Anwendungen nutzen, ist eine ziemlich blöde Idee. Da verwendet man besser die gut getesteten, open source Bibliotheken.
-
@krümelkacker
Der Code ist von 2006, wahrscheinlich findet auch Swordfish ihn mittlerweile schrecklich.krümelkacker schrieb:
Es dann aber für sicherheitskritische Anwendungen nutzen, ist eine ziemlich blöde Idee. Da verwendet man besser die gut getesteten, open source Bibliotheken.
Mal aus Interesse. Angenommen man implementiert das selbst, verschlüsselt dann etwas und "große" Programme können das dann wieder entschlüsseln. (Test natürlich auch umgekehrt machen.)
Bedeutet das dann nicht, dass der Algorithmus richtig angewendet wird und man eigentlich keine Sicherheitslücken haben sollte? (Im Sinne der Verschlüsselung, Schlüssel im Speicher oder so sind ja noch mal ein anderes Thema.)
-
cooky451 schrieb:
@krümelkacker
Der Code ist von 2006, wahrscheinlich findet auch Swordfish ihn mittlerweile schrecklich.Daß ich damit nix 'reiß' hab ich damals schon gewusst
-
Algorithmus richtig angewendet != keine Sicherheitslücken
-
Swordfish schrieb:
Daß ich damit nix 'reiß' hab ich damals schon gewusst
Aber wie bist du auf die Idee mit dem buf** gekommen, auf den du dann auch noch delete[] aufrufst?
knivil schrieb:
Algorithmus richtig angewendet != keine Sicherheitslücken
Sehr informativ..
-
cooky451 schrieb:
knivil schrieb:
Algorithmus richtig angewendet != keine Sicherheitslücken
Sehr informativ..
Du setzt zwei Groessen in Relation, die nichts miteinander zu tun haben. Wenn das Programm beispielsweise den Schluessel bei Twitter postet, dann ist es potentiell unsicher. Das hat nichts mit der Funktionsweise des Algorithmus zu tun.
-
cooky451 schrieb:
Bedeutet das dann nicht, dass der Algorithmus richtig angewendet wird und man eigentlich keine Sicherheitslücken haben sollte? (Im Sinne der Verschlüsselung, Schlüssel im Speicher oder so sind ja noch mal ein anderes Thema.)
Yay, ich habe deine Antwort vorausgesehen und sie von vorneherein ausgeschlossen. Aber offensichtlich wurde das einfach mal galant ignoriert.
-
Du willst wissen, ob AES sicher ist? Ja, es gilt als sicher. Aber was nützt dir diese Antwort? Nur weil ein Frickelprogramm AES benutzt, wird es dadurch nicht sicher. Selbst wenn es auf einem isolierten Rechner läuft, das Ergebnis ausgedruckt wird und dann per Schneckenpost an dem Empfänger geschickt wird. Die Frage macht einfach keinen Sinn, wie knivil schon erklärt hat.
-
SeppJ schrieb:
Die Frage macht einfach keinen Sinn, wie knivil schon erklärt hat.
Natürlich macht sie das. Die Frage war, ob es sein kann*, dass der Algorithmus irgendwie falsch angewendet wird, obwohl andere Programme es wieder entschlüsseln können.
* Die Wahrscheinlichkeit nicht gegen 0 geht.
-
Also, wenn man AES selbst implementiert und erfolgreich die Testvektoren durchrechnen kann, dann ist das schon nicht schlecht. Allerdings kann da natürlich trotzdem noch ein Bug drin sein, der sich bei den Testvektoren nur nicht bemerkbar macht. Man kann aber erwarten, dass die gut getesteten Implementierungen in Open Source Bibliotheken sehr flott sind und vllt sogar auch resistent gegen "side channel attacks" sind (wo man z.B. über Energieverbrauch und/oder Timing versucht, den Schlüssel rauszufinden oder zumindest den Schlüsselraum einschränken will).
