Implementierung eines standardisierten AES-Algorithmus
- Hoffentlich passt diese Frage hierher -
Immer wieder gibt es eine Person, die nach der Erstellung eines eigenen Verschlüsselungsstandards / einer eigenen Verschlüsselung gefragt hat, und wir sind uns alle einig, sie frühzeitig zu stoppen, da wir uns alle einig sind, dass dies sehr unklug ist (z. B. das Verhindern unbekannter oder unsichtbarer Schwächen) in ihrem Standard usw.).
Meine merkwürdige Frage lautet: Was ist mit der Programmierung Ihrer eigenen Bibliothek mit beispielsweise AES-Chiffre in der Sprache Ihrer Wahl? Es wird keine neue Verschlüsselung erstellt (die sich immer noch strikt an die AES-Verschlüsselung / den AES-Algorithmus hält), sondern nur das Schreiben dieses Algo in einer Programmiersprache Ihrer Wahl (möglicherweise wird die AES-Verschlüsselung in C / C ++ erneut durchgeführt, damit wir neue Funktionen verwenden können, die in neue integriert sind CPU und machen Sie es schneller -> NUR BEISPIEL) oder jemand hat eine neue Programmiersprache erstellt, die noch keine AES-Bibliothek hat (und Sie möchten eine beitragen). Ist es immer noch ratsam, dies zu tun?
Antworten
Was ist mit der Programmierung Ihrer eigenen Bibliothek von beispielsweise AES-Chiffren in der Sprache Ihrer Wahl?
Die korrekte Implementierung von AES selbst ist nicht allzu schwierig. Die Spezifikation ist gut geschrieben, enthält Abbildungen und Zwischentestvektoren, so dass im Wesentlichen jeder dies tun kann.
Was für AES schwierig ist und der Grund, warum es im Allgemeinen nicht ratsam ist, eine produktionsbereite Implementierung selbst zu schreiben, ist, eine Implementierung zu schreiben, die relativ schnell und (/ oder) resistent gegen gängige Software-CPU-Seitenkanäle ist.
Wenn Ihre Sprache weiterhin eine AES-Implementierung haben soll, besteht der übliche Weg darin, die Fremdfunktionsschnittstelle zum Aufrufen einer C-basierten AES-Bibliothek zu verwenden.
Was die Implementierung von AES selbst angeht: Wenn Ihre Sprache zu Maschinencode kompiliert wird, gibt es normalerweise eine Möglichkeit, auf Intrinsics für AES zuzugreifen, und bei diesen gibt es normalerweise wenig, was man falsch machen könnte - abgesehen davon, dass die CPU die Anweisungen nicht ordnungsgemäß weiterleiten kann.
Wenn Sie keine mit Maschinencode kompilierte Sprache haben und / oder Ihre Ziel-CPU keine Hardware-AES-Anweisungen hat, wird es schwieriger. Sie müssen sicherstellen, dass alles, was Sie in Ihrer Sprache schreiben, während der Interpretation / Just-in-Time-Kompilierung keine seltsamen Dinge tut, um versehentlich zusätzliche Anweisungen einzuführen. Sie müssen sicherstellen, dass die Implementierung unabhängig vom verwendeten Schlüssel und den verwendeten Daten immer dieselbe Zeit in Anspruch nimmt. Sie müssen sicherstellen, dass der vorherige Schritt vom Interpreter / JIT-Compiler / CPU nicht potenziell durcheinander gebracht wird. Sie müssen auch sicherstellen, dass Ihre Speicherzugriffsmuster nicht von geheimen Daten abhängen. Die meisten dieser Punkte können behoben werden, z. B. mithilfe von AES-Implementierungen mit Bit-Sliced, aber dies ist natürlich keine triviale Aufgabe - insbesondere, wenn die Implementierung relativ schnell sein soll.