C - AES - Multiplikation

[fork(Agent Smith)]

Hallo Community!

Versuche gerade AES zu implementieren. Ich weiß es gibt hier schon genügend Bibliotheken,
möchte das aber gerne selber schaffen.

Ich verwende diese Spezifikation.

Eine Frage habe ich bei der AES Multiplikation (Abschnitt 4.2):

Dabei handelt es sich um eine Polynommultiplikation von den Summanden und abschließend ein Modulo mit einem bestimmten Wert.
So weit habe ich es einmal verstanden, hoffe ich jedenfalls. Ich kann die Polynommultiplikation so lösen, so wie ich sie händisch lösen würde.
Also in der Form mit Iterationen, hab das aber noch nicht gemacht.

Die Frage:
Gibt es hier eine bessere bzw. schnellere Lösung (ohne die Verwendung von Schleifen)?

 

[gringoo]

Hi,

waere hilfreich die Basis deiner Ausgangssituation zu kennen. Geht es dir darum round keys für die decryption states zu generieren? Wie sieht denn generell dein usecase aus, hoffe nur für self education reasons und nicht irgendwas, was du auf die Welt loslassen möchtest.

hier mal als reference, kokkes tiny aes

tiny-AES-c/aes.c at master · kokke/tiny-AES-c

Small portable AES128/192/256 in C. Contribute to kokke/tiny-AES-c development by creating an account on GitHub.

github.com

greetings,
gringo

 

[fork(Agent Smith)]

Hi,

waere hilfreich die Basis deiner Ausgangssituation zu kennen. Geht es dir darum round keys für die decryption states zu generieren?
[...]

Ja, genau.

Wie sieht denn generell dein usecase aus, hoffe nur für self education reasons und nicht irgendwas, was du auf die Welt loslassen möchtest.

Was ist daran schlecht eine eigene Implementation zu machen? Außerdem, wenn meine Implementation auch etwas "richtig" laut Standard verschlüsselt und entschlüsselt, dann sehe ich keine Probleme das Ganze zu veröffentlichen. Schon mal in den Sinn gekommen, dass mir die Lizenz von einer fertigen Implementation nicht zusagt? Deswegen die Frage ob man es anders auch machen kann. Habe auch erfolgreich schon SHA256 und SHA512 (sind zwar kryptographische Hasher) für meine Projekte implementiert und auch in einer Bibliothek veröffentlicht. Und machen auch was sie sollen. Warum nicht AES? Die Ausgangslage sind empfindliche Daten zu verschlüsseln. Mehr sage ich dazu nicht. Kommt aber natürlich auch der Lerneffekt dazu. Ist noch kein Meister vom Himmel gefallen. Jeder oder jede hat mal klein Anfangen müssen.

hier mal als reference, kokkes tiny aes

tiny-AES-c/aes.c at master · kokke/tiny-AES-c

Small portable AES128/192/256 in C. Contribute to kokke/tiny-AES-c development by creating an account on GitHub.

github.com

Kenne ich schon, danke.

 

[kaputtnik]

Krypto ist halt so schon komplex, dass selbst Menschen, die das Hauptberuflich machen, Fehler machen. Und die Erfahrung zeigt hier, dass Menschen, die damit keine Erfahrung haben, erst Recht (auch kritische) Fehler machen.
Deshalb sagt man allgemein, dass man in diesem Fall besser bestehende Implementierungen nutzt sollte und das Rad besser nicht neu erfindet.

 

[fork(Agent Smith)]

Krypto ist halt so schon komplex, dass selbst Menschen, die das Hauptberuflich machen, Fehler machen. Und die Erfahrung zeigt hier, dass Menschen, die damit keine Erfahrung haben, erst Recht (auch kritische) Fehler machen.

Mag sein. Allerdings will ich mich mit diesem Thema mehr auseinander setzen. Und ich schreibe es nochmal: Auch den sogenannten Kryptographieexperten ist das Wissen nicht einfach so in den Schoß gefallen. Die haben sich auch mal mit den Basics beschäftigen müssen.

Deshalb sagt man allgemein, dass man in diesem Fall besser bestehende Implementierungen nutzt sollte und das Rad besser nicht neu erfindet.

Es geht mir ums Verstehen der Implementierungen. Das ist bei fremden Code oft nicht der Fall. Außerdem ist es nach wie vor eines meiner Ziele ein eigenes Verschlüsselungssystem zu entwerfen. Und man kann auch von der Spezifikation das lernen. Wegen dem Rad neu erfinden: Ja, ich bin so ein Typ. Habe derzeit aufgrund zweier Krankheiten (beziehe schon Invaliditätsrente mit einem zarten Alter von 37 Jahren) genügend Zeit um das zu machen. Außerdem gilt bei mir der Satz: It's done, when it's done. Habe mir für alle meine Projekte keine Deadline gesetzt.

Nachtrag:
Wenn mich jedes mal jemand zurückschrecken würde, dann wären auch in meinem damaligen Beruf als Hardware-/Softwareentwickler bestimmte Projekte nicht möglich gewesen. Dachte in einem Board das sich Hackerboard nennt ist das klar.

 

[kaputtnik]

Das war nur eine Erklärung zu gringoos Beitrag gedacht.

Niemand hat etwas gegen das Auseinandersetzen mit einem Thema oder Lernen im Allgemeinen geschrieben. Lernen ist super!

Es ist eben ein Unterschied, ob du etwas machst, um es zu verstehen, oder das Rad neu erfindest und denkst "hey das geht ja auch so und ist viel einfacher" und dann schaut sich das jemand anderes an und stellt fest, dass da schwerwiegende Fehler in der Implementierung drin sind. Das geht bei irgendwelchen statischen Keys los und hört bei komplexem Kram, den du nicht weißt, auf. Denk nur mal an Heartbleed.

Zum Lernen bau was willst. Aber in nem Projekt Verschlüsselung selbst zu basteln, anstatt auf bereits bestehende Lösungen zu setzen, geht eben (fast) immer in die Hose.

 

[fork(Agent Smith)]

[...]

Es ist eben ein Unterschied, ob du etwas machst, um es zu verstehen, oder das Rad neu erfindest und denkst "hey das geht ja auch so und ist viel einfacher" und dann schaut sich das jemand anderes an und stellt fest, dass da schwerwiegende Fehler in der Implementierung drin sind. Das geht bei irgendwelchen statischen Keys los und hört bei komplexem Kram, den du nicht weißt, auf. Denk nur mal an Heartbleed.

[...]

In erster Linie steht bei mir mal das Verstehen. Danach kommen - ich nenne sie mal so - Optimierungen und Anpassungen an die gegebene Situation. Keine statischen Schlüssel sind bei meinen Projekten nicht immer möglich. Weil irgendwo muss der Schlüssel stehen. Mir ist durchaus klar, dass das ein Sicherheitsproblem ist. Allerdings habe ich noch keine anderen Lösungen ohne Benutzereingabe oder Verschleierung gefunden. Habe mich da derzeit auch nicht wirklich beschäftigt. Schwerwiegende Fehler in der Implementierung können meiner Meinung nur entstehen, wenn ich mich nicht an die Spezifikation halte.

Zugegeben ich habe mir bis jetzt nie den Fehler von Heartbleed angeschaut. Aber wenn die Angaben (Keine Längenüberprüfung der Eingabedaten) bei Wikipedia stimmen, dann muss ich ganz frech sagen: Shit happens! Was mich hier allerdings wundert, warum das niemand sofort beanstandet hat. Sind für mich eigentlich Grundregeln, dass man eine Dateneingabe nicht immer trauen kann und verifiziert gehört auch wenn nur die Länge überprüft wird.