1.) die Vielzahl der Algorithmen ist nur eine Frage der Kompatibilität vom
DEC als Bibliothek. Du wählst dir 1-3 Algorithmen aus den über 70 vorhanden aus. Wichtig für dich ist nur das alle verfügbaren Algorithmen identisch programmierbar sind, du kannst also in Zukunft ohne Probleme von deinen 1-3 ausgewählten Verfahren wechseln auf die anderen Verfahren. Darin besteht der Sinn vom
DEC.
2.) auswählen wirst du dir ein Hashverfahren, ein Verschl. Verfahren und ein oder zwei Text Konvertierungs Verfahren. Als Hash hat sich SHA1 durchgesetzt, als Cipher AES (Rijndael) und als Textformat ist MIME64 zu empfehlen.
3.) die Wahl des Ciphrmode (cmCBCx etc.pp.) ist da schon kritischer. Du kanst wählen ob du konform zu anderen Standards sein möchtest (alle ausser cmCTSx und cmCFSx) oder ob du es sicherer haben möchtest dafür nicht standardkonform (zb. cmCTSx/cmCFSx die ich entwickelt habe). Du kannst wählen ob du nur in Blöcken a x Bytes ver/entschl. musst oder ob du auf Bytegröße genau arbeiten möchtest (cmCBCx oder cmCBC8). Diese Entscheidung ist eine technischologisch und auch sicherheitsrelevante Entscheidung.
Kurz: du möchtest Inhalte von Datenbankfeldern schützen, also sehr kurze Informationsblöcke. In diesem Falle sollte es nicht so sehr auf Geschwindigkeit ankommen sondern auf Sicherheit und die vermeidung des Paddings der Daten. Modis wie cmCFS8, cmOFB8, cmCBC8 wären die Wahl. Willst du einigermaßen Standardkonform bleiben wären cmCBC8 oder cmOFB8 richtig, möchtest du höhere Sicherheit dann cmCFS8.
Zitat:
Hat das Ausgabeformat Auswirkungen auf die Sicherheit?
Nein, darfs es auch garnicht. Als Format in einer Datenbank solltest du eines wählen das
1.) nicht durch Sprachtreiber der
DB zerstört wird
2.) möglichst keine hohe Datenexpansion hat. MIME64 expandiert die binären Daten zb. um ein Ratio von 3 auf 4 Zeichen. HEX expandiert dagegen schon von 2 auf 4 Zeichen.
In jedem Falle werden die Daten expandiert, da du aus Sicherheitsgründen immer mit einem Zufallssalt arbeiten solltest. D.h. ein Addressfeld wird verschlüsselt indem bis zu 16 Bytes Zufall + die Addressdaten in einem Rutsch verschlüsselt werden. Machst du dies nicht so hat ein Angreifer die Chance über viele Addressdatensätze hinweg eine differentielle Kryptroanalyse anszusetzen.
Das größte Problem dürfte aber an ganz anderer Stelle entstehen:
Du möchtest das mehrere Benutzer die gleichen Daten bearbeiten können. Also kannst du nicht die Daten mit den Benutzerpasswörtern verschlüsseln. Stattdessen benötigst du einen zufälligen Masterkey der als Datensatz für jeden Benutzer verschlüsselt gespeichert wird. Du kannst dies auf Datenbankebene machen oder auf Datensatzebene. Machst du es auf Datenbankebene so heist dies es gibt nur einen Masterekey. Das erhöht das Risiko das ein Angreifer als regulärer Benutzer diesen Masterkey ausspioniert und somit alle Daten entschlüsseln kann. Zudem musst du denoch wie oben angedeutet mit einem Salt für die Daten arbeiten.
Arbeitest du auf Datensatzebene so musst du für jeden DS einen eigenen Schlüssel verwalten (zufallserzeugt). Damit sparst du dir die Zufallssalts ein. Andererseits musst du aber nun für diesen Schlüssel und pro Datensatz für alle Benutzer diesen Schlüssel geschützt abspeichern. ZB. bei 6 Benutzern also pro Datensatz 6 mal verschl. in einem Datenfeld hinterlegen.
Das sind alles Vorschläge die mir reiner sym. Verschl. funktionieren.
Du kannst es dir aber auch einfacher machen. Zb. installierst du dir eine Sofwtare wie E4M die ein virtuelles Laufwerk auf eine Datei mappen kann. Dieses Laufwerk ist online verschlüsselt und in dem speicherst du deine
Access DB. Der Admin muss dann für alle Benutzer beim Hochfahren dieses Laufwerk erst mappen.
Gruß Hagen