Ab und an kommt es vor, dass exportierte, sensible Daten einer Applikation nur bestimmten Personen zugänglich gemacht, oder für den besseren Transport komprimiert werden sollen. Auch CONZEPT 16 bietet diese Möglichkeit.
Mit der Funktion FsiFileProcess() können externe Dateien ver- und entschlüsselt, komprimiert und dekomprimiert werden und der Datei-Hash angehängt werden.
Der Funktion wird im ersten Parameter die Quelldatei und im zweiten der Zieldatei, beide inklusive Pfad, übergeben. Der dritte Parameter bestimmt die durchzuführende Operation. Bei der Ver- und Entschlüsselung kann im vierten Parameter ein Schlüssel mit maximal 64 Zeichen angegeben werden.
Folgende Optionen sind möglich:
_FsiEncrypt– Verschlüsseln_FsiCompress…– Komprimieren_FsiDecode– Entschlüsseln und dekomprimieren_FsiFileMD5– MD5-Hash anhängen_FsiFileRMD160– RIPEMD-16-Hash anhängen
Dabei kann _FsiEncrypt mit einer _FsiCompress...-Konstanten und einer _FsiFile...-Konstanten kombiniert werden. Werden diese Möglichkeiten kombiniert, wird die Datei erst komprimiert, dann verschlüsselt und anschließend der Hash angehängt.
_FsiEncrypt
Die Datei wird mit dem angegebenen Schlüssel verschlüsselt. Ist kein Schlüssel definiert, wird ein interner Schlüssel verwendet. Aus dem angegebenen Schlüssel wird ein 128-Bit-Schlüssel generiert, mit dem die Datei symmetrisch verschlüsselt wird.
_FsiCompress…
Für die Komprimierung können die folgenden Konstanten angegeben werden:
_FsiCompressFast– Schnelle Verarbeitung bei niedriger Komprimierung_FsiCompressMed– Mittlere Komprimierung_FsiCompressStd– Standardkomprimierung_FsiCompressSlow– Langsame Verarbeitung bei hoher Komprimierung
Bei Dateien die bereits stark komprimiert sind, kann eine weitere Komprimierung die Datenmenge vergrößern. Dazu gehören zum Beispiel JPEG, AVI und andere Multimedia-Dateien. Beste Kompressionsergebnisse erhält man bei textbasierten Dateien.
_FsiDecode
Die angegebene Datei wird, je nach vorher durchgeführter Aktion, entschlüsselt und / oder dekomprimiert. Bei der Entschlüsselung muss im vierten Parameter der gleiche Schlüssel verwendet werden, wie bei der Verschlüsselung.
_FsiFileMD5
An die Datei wird deren Hash-Wert nach dem „Message-Digest Algorhithm 5“ angehängt. Wird gleichzeitig eine Verschlüsselung oder Komprimierung vorgenommen, wird der Hash-Wert auf den resultierenden Daten gebildet.
_FsiFileRMD160
An die Datei wird äquivalent zu _FsiFileMD5 ein Hash-Wert nach dem „RIPEMD-160-Standard“ angehängt.
7 Antworten
@Andrej
Ja, stimmt, da der tatsächlich verwendete Schlüssel ja erst erzeugt wird, kann der vom Programmierer eingegebene Wert nicht für die Entschlüsselung verwendet werden. D.h. man müsste den tatsächlich verwendeten Schlüssel irgendwie verfügbar haben, um mit externer Software kommunizieren zu können. Die Verschlüsselungsfunktion(en) sollte(n) also irgendeine Art von Zugriff auf den tatsächlich verwendeten Schlüssel bieten.
Dies würde allerdings nicht in Bezug auf die Entschlüsselung extern verschlüsselter Daten helfen. So dass man also ohnehin veränderte Entschlüsselungsfunktionen bräuchte, die mit einem ausserhalb von C16 erzeugten Schlüssel umgehen könnten. Also könnte man eine derartige Verfahrensweise auch gleich sowohl für die Ver- als auch die Entschlüsselung vorsehen.
Es wäre wohl besser gewesen, man hätte die Schlüsselgenerierung und die Ver- bzw. Entschlüsselung sauber getrennt, dann könnte man eine Ver- und Entschlüsselung je nach Bedarf mit externen oder in C16 erzeugten Schlüsseln vornehmen.
Nach welchem Verfahren wird denn aus dem übergebenen Schlüsselwert der tatsächlich verwendete Schlüssel berechnet?
@Kilian
Das "modifiziert" bezieht sich auf den kryptografischen Schlüssel. Aus dem übergebenen alphanumerischen Schlüsselwert wird der binäre Key erzeugt, somit ist der verwendete Key zum einen nicht direkt sichtbar, zum anderen können alphanumerische Werte einfach gespeichert und übertragen werden.
Die Implementierung weiterer Verfahren hängt natürlich von konkreten Anwendungsfällen ab. Allerdings wird dabei von unserer Seite eine Verschlüsselung/Kompression auf der Ebene des Memory-Objekts bevorzugt.
@Andrej
Aber wieso überhaupt "modifiziert"? Würde das Standardverfahren verwendet, wären wir doch ohne weiteren Aufwand kompatibel mit dem Rest der Welt?
Praktisch wäre auch, das Verfahren per Flag auswählen zu können (_CryptIDEA, _CryptAES, _CryptBlowfish, usw…). Natürlich das jeweilige Standardverfahren.
Über diesen Weg, liesse sich die Standardkonformität auch rückwärtskompatibel einbauen: ohne Flag = modifiziertes IDEA, mit Flag = jeweiliges Standardverfahren.
@Kilian
Für die Verschlüsselung wird ein modifiziertes IDEA-Verfahren verwendet. Sowohl für Verschlüsselung als auch für die Kompression sind prinzipiell auch andere Verfahren realisierbar (AES, zip etc.).
Welche der symmetrischen Verschlüsselungsmethoden kommt denn zum Einsatz?
Ich bin überrascht, dass die Entschlüsselung nur wieder mit C16 möglich sein soll, denn falls die üblichen Verschlüsselungsverfahren verwendet werden, sollte man doch kompatibel zu einer ganzen Reihe von externer Software sein.
Im Übrigen bedeutet diese Einschränkung wohl auch, dass umgekehrt Dateien, die ausserhalb von C16 verschlüsselt wurden, nicht mit C16-Bordmitteln entschlüsselt werden können, so dass entsprechende Daten also unverschlüsselt an C16-Software übergeben werden müssen.
Eigentlich funktioniert ja die Entschlüsselung durch externe Software bereits, denn bei einer per SSL-verschlüsselten Kommunikation passiert ja genau das: von C16 verschlüsselte Daten werden beim (nicht-C16)-Adressaten wieder entschlüsselt.
Vorschlag: Wenn beim Verschlüsseln ein Schlüssel angegeben wird, dann sollte die Datei auch unter Angabe dieses Schlüssels von aussen wieder entschlüsselt werden können (wie z.B. bei der Verschlüsselung von ZIP-Archiven gängige Praxis). Evtl. könnte man diese Funktionalität über ein Flag an-/abschaltbar machen (falls jemand wirklich so verschlüsseln möchte, dass es nur von C16 wieder entschlüsselt werden kann).
@Th.Eichele:
Da zum verschlüsseln und komprimieren CONZEPT 16-eigene Funktionen verwendet werden, die nach außen nicht verfügbar sind, wird zum entschlüsseln und dekomprimieren wieder CONZEPT 16 benötigt.
Benötigt der Empfänger zum Entschlüsseln/Entpacken dann auch wieder Conzept16, oder kann er die Datei auch anderweitig öffnen ?