AEs-Implementierung

Sone

Schon mal vielen Dank für die Rückmeldung, cooky
(P.S.: Ich lache heute über deine Aussage, ich brauche zwei Wochen - das waren vier Tage :p )

Ich wollte doch keine Praxistaugliche AES-Implementierung schreiben!
Nein, das war erstens fürs lernen und zweitens für eine schöne Lösung.

Tatsächlich hast du Recht, die template-isierung ist irgendwie sinnlos. Na gut, die entferne ich komplett.

Die GF8-Klasse ist zwar eine lustige Idee, aber letztlich auch unbrauchbar, weil der allgemeine Algorithmus viel zu langsam ist.

Welcher Algorithmus? Die Multiplikation? Kann sein.
Die Klasse ist tatsächlich ein wenig Gegaukle gewesen , die entferne ich und schreib' mir statt der Operatorfunktion eine normale Funktion.

Man braucht ja nur *2 und *3 oder so, wenn ich mich richtig erinnere.

Du erinnerst dich falsch. Sobald du mit der inversen Matrix arbeitest, sind da 0xE , 0xB , usw.

Sone

Einige Templates sind ja nun mal für die Größe des Keys. Die kann ich nicht weg machen, weil so die ganze Sache designed ist - std::array braucht eine Kompilezeit-Konstante.

Ich hab es jetzt verbessert - wie ist es?

cooky451

Sone schrieb:

Du erinnerst dich falsch. Sobald du mit der inversen Matrix arbeitest, sind da 0xE , 0xB , usw.

Ja, klar, aber es sind eben trotzdem nur ein paar spezifische Werte.

Die Keys als Arrays zu übergeben hat auch nicht wirklich nen Vorteil. Du könntest genau so gut einfach einen void* nehmen. Und was du auch ändern solltest: Mach eine Key-Klasse, die die key-expansion im Konstruktor erledigt. Dann musst du das nicht immer wieder machen, wenn du mehrere Crypter mit dem gleichen Key nutzen willst.

knivil

extern std::array<byte, 256> const Rcon;
extern std::array<byte, 256> const SBox;
extern std::array<byte, 256> const InverseSBox;

Wenn es niemand benutzt, dann brauchst du es auch nicht exportieren.

Sone

cooky451 schrieb:

Und was du auch ändern solltest: Mach eine Key-Klasse, die die key-expansion im Konstruktor erledigt. Dann musst du das nicht immer wieder machen, wenn du mehrere Crypter mit dem gleichen Key nutzen willst.

Natürlich, natürlich. Du hast Recht. Das Wrappe ich dann.

knivil schrieb:

extern std::array<byte, 256> const Rcon;
extern std::array<byte, 256> const SBox;
extern std::array<byte, 256> const InverseSBox;
Wenn es niemand benutzt, dann brauchst du es auch nicht exportieren.

Du hast völlig Recht.

Sone

So, ist on. Wie ist es jetzt?

Ich habe das Gefühl, eigentlich sollten AddRoundKey & Co. nicht einfach einen Zeiger sondern direkt eine Referenz auf ein Key-Objekt nehmen.

Ethon

Verstehe leider nicht genug von AES um deine Implementierung richtig kritisieren zu können - was ich sehe gefällt mir aber.
Du hast dich gewaltig gemacht im Vergleich zum Vorjahr.

knivil

Nun, AES zu implementieren ist nicht schwer. Man muss eigentlich nur vom Paper abschreiben.

Sone

knivil schrieb:

Nun, AES zu implementieren ist nicht schwer. Man muss eigentlich nur vom Paper abschreiben.

Mehr oder weniger. Genau wie cooky. Und alle Anderen.
Nein, aber mal ehrlich - ganz ohne ist das nicht. Ich denke, keiner kann wirklich AES implementieren ohne zu wissen was ein Galoiskörper ist.
(Edit: Hmm, doch.)
Die Multiplikation hat mir schon ein ganz klein wenig zu schaffen gemacht - dass dafür so ein richtiger Algo nötig ist, ahnte ich nicht.
Ich dachte zuerst, man multipliziert und nimmt Modulo des irreduziblen Polynoms (als Zahl 283). Kopf->Tisch

Ethon schrieb:

Du hast dich gewaltig gemacht im Vergleich zum Vorjahr.

Vielen Dank!

cooky451

Na ja, also ich habe die Variante mit den Lookup-Tables implementiert, da muss man zumindest noch mal in's andere Paper gucken.

hustbaer

Sone schrieb:

knivil schrieb:

Nun, AES zu implementieren ist nicht schwer. Man muss eigentlich nur vom Paper abschreiben.

Mehr oder weniger. Genau wie cooky. Und alle Anderen.
Nein, aber mal ehrlich - ganz ohne ist das nicht. Ich denke, keiner kann wirklich AES implementieren ohne zu wissen was ein Galoiskörper ist.
(Edit: Hmm, doch.)

Kommt auch drauf an ob man vom Original-Paper abschreibt oder von einer Referenz-Implementierung. Oder nem Paper/Artikel der das ganze etwas erklärt -- sollte ja einiges zu dem Thema geben.

Wenn man nur eine funktionierende, möglichst performante Implementierung will, dann nimmt man sich wohl am besten eine ... naja, funktionierende, möglichst performante Implementierung, überträgt die auf die gewünschte Zielplattform und tut halt schön linear optimieren wo man was zu optimieren findet.

Sone

http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
+ Wikipedia.

Sone

cooky451 schrieb:

Na ja, also ich habe die Variante mit den Lookup-Tables implementiert, da muss man zumindest noch mal in's andere Paper gucken.

Wieso? Ist die Variante nicht einfach, dass man bspw. alle Multiplikationen im Galoiskörper vorberechnet o.ä.? Das kannst du aber auch ohne Paper, oder nicht?

knivil

Das Orginalpaper ist ganz gut. Ich hatte nur das.

cooky451

Sone schrieb:

Wieso? Ist die Variante nicht einfach, dass man bspw. alle Multiplikationen im Galoiskörper vorberechnet o.ä.?

Kommt drauf an was du mit o.ä. meinst, man berechnet deutlich mehr vor als das.

knivil schrieb:

Das Orginalpaper ist ganz gut. Ich hatte nur das.

Yep, da sollte auch der Trick mit den 4 Tables drin beschrieben sein. Schade, dass man das heute wegen Timing Angriffen nicht mehr benutzen kann.