Mein Prinzip der AES-256-bit-Cryptography ist die Trennung von Schlüsselmanagement im Core und dem Codieralgorythmus im jeweiligen Prozess. Die Schlüssel können von Core zu Core übertragen werden. Dies stellt dann auch die Datensicherung dar, die ansonsten nicht weiter vorgesehen ist.

Der Core verfügt über eine eigene Databaseseengine. Diese hat ein Wartungsmodul mit zwei Aufgaben: Den „Perfekten Ausgleich“ (PA) des Binary-Search-Trees (BST) und die Startoptimierung (SO) der Datenbankdateien. Letzteres ist vergleichbar mit dem Defragmentieren von Datenträgern. Die SO dient nur der Beschleunigung des Starts der DB-Engine durch eine für den Start optimierte Anordnung der Daten in den DB-Dateien. Es empfiehlt sich, den Vorgang manuell durchzuführen. Bei den heutigen Rechenkapazitäten ist das erst ab 1 Millionen Datensätze sinnvoll. Der PA der BSTs geht sehr schnell, da die BSTs sich im Cache der DB-Engine befinden und dabei nur "Zeiger umgehängt" und keine Daten verschoben werden. Der PA wird auch bei jedem Start des Cores ausgeführt. Diese beiden Aufgaben können auch automatisch zu einer vorgegebenen Zeit ausgeführt werden, wenn beispielsweise der Core im 24/7-Betrieb läuft.

Das Abstract-Data-Types Project ist ein Open-Source-Project. Bei den Funktionen FLOATzuCHAR() und DOUBLEzuCHAR() wird nur in der Darstellung gerundet. Der interne Wert bleibt unverändert. Bei Angabe von 8 Stellen bei FLOATzuCHAR() und bei Angabe von 16 Stellen bei DOUBLEzuCHAR() wird nicht gerundet. Stattdessen wird der echte Wert dargestellt, mit dem der Prozessor intern rechnet. Für eine 100%ige Genauigkeit, wie sie beispielsweise in der Finanzwirtschaft gefordert wird, empfehle ich die Verwendung von COComma4 und COComma4_80. Bei diesen beiden Datentypen wird nach kaufmännischem Runden entsprechend der DIN-Norm 1333 gerundet.

Zusätzlich wird auf der Prozess-Seite noch die Datei FileVers.dll benötigt. Die einzige Aufgabe dieser Datei besteht darin, die jeweilige Dateiversion aller im Programm verwendeten RePag-DLL-Dateien mit der Programmversion abzugleichen. Es ist daher später nicht möglich, beim User eine RePag-DLL-Datei mit gleichem Dateinamen, aber anderer Version, auszutauschen. Ein offizielles Update ist weiterhin möglich.

Aufgrund der umfangreichen Änderungen am Cryptho-Algorithmus ist der Core ab Version 2.0.4.1 im Bereich der Datenbankdateien und des Protokolls nicht abwärtskompatibel. Die Portnummer wurde von 5111 auf 5115 geändert. Zur Verbesserung der Sicherheit wurde noch einmal eine Änderung am Protokoll vorgenommen, die dazu führt, dass der Core ab Version 2.0.4.6 nicht abwärtskompatibel ist. Der Cryptho-Algorithmus und die Datenbankdateien bleiben unverändert.

Hinweis: Jeder Core verfügt über seinen eigenen Datenbankschlüssel, daher ist das Kopieren von Datenbankdateien nicht möglich. Jede Core-zu-Core-Verbindung verfügt über ihren eigenen Schlüssel, der periodisch nach einer bestimmten Zeit oder nach einer festgelegten Anzahl von Benutzungen getauscht wird. Der Core ist ein Viertel des Ganzen einer Client/Server-Architektur, in deren Verbund seine Aufgabe darin besteht, die anfallenden Daten zu verschlüsseln. Jeder Core versucht sich periodisch mit dem Core unter core.repag.net zu verbinden. Sollte ich diesen schalten, würden sich alle Cores, die über das Internet erreichbar sind, miteinander verbinden und Schlüssel tauschen.
...und IP-Listen nach dem Motto "Kennste den schon? "Mehr nicht!