Na das nenne ich doch "ideale Rahmenbedingungen".
Du solltest dann folgendes machen:
1.) ein Datenbankfeld "Salt" binär mit 16 Bytes anlegen. Dieses Datenbankfeld wird mit 16 Bytes Zufall gefüttert.
1.1.) ein Datenbankfeld "Check" binär mit 16 Bytes, enthält verschlüsselt einen Hash über den Sessionkey als Überprüfung ob der Benutzer das richtige Passwort benutzt (optional, wenn du's benutzen möchtest frage mich nochmal danach)
2.) dieser Salt dient in einer KDF -> Key Derivation Function -> Schlüsselableitungsfunktion zur Erzeugung eines Sessionkeys für diesen einen Datensatz.
3.) mit THash_SHA1.KDFx(Salt || Userpasswort) erzeugst du diesen Sessionkey.
4.) wenn der Benutzer nur 1 Datenfeld des Datensatzes ändert verschlüsselst du alle anderen Datenfelder immmer neu. Du speicherst als alle zu schützenden Felder immer neu. Denn bevor du speicherst erzeugst du einen neuen Salt. Das bedeutet das bei jder Änderung im Datensatz dieser immer mit einem komplett neuen, zufallsähnlichem ander Benutzerkey abhängigem Sessionkey verschlüsselt wird. Das verhindert effektiv einige der modernsten Angriffe.
5.) als Ciphermode würde ich cmCBC8 oder cmCFS8 benutzen. Die 8 bedeutet das diese Modis auf 8 Bit arbeiten. Beim AES, der ein Blockcipher ist, werden immer 16 Bytes der Nachricht in einem Rutsch verschlüsselt. Der Ciphermode stellt nun sicher ds diese Blöcke untereinander verknüpft werden, und somit bestimte Angriffe (Austasuch voin Datenblöcken) verhindert werden. Normalerweise würde man also mit AES immer in 16 Bytes Schritten eine Nachricht schützen. Das führt aber dazu das diese Nachricht in der Größe ein Mehrfaches von 16 sein muß oder aber auf dieses Merhfache expandiert werden muß, in short wir benötigen ein Padding. Verschiedene Padding-Verfahren wie CipherText Stealing sind aber bei Nachrichten < 16 Bytes unsicher ! Die Cipher Modis die auf 8 Bit = 1 Byte arbeiten benutzen im Falle von AES intern auch einen 16 Bytes Block. Allerdings wenden sie die Verschlüsselungsfunktion auch 16 mal auf diesen Block an also pro Datenbyte einmal. Statt normalerweise 1 mal pro 16 Bytes. Damit wäre der cmCBC8 Modus im Falle von AES im vergleich zum cmCBCx Modus eine 16 fache Verschlüsselung, also auch 16 mal so langsam wie cmCBCx. Dafür entfällt aber die Notwendigkeit eines Paddings. Eine Nachricht mit 17 Bytes benötigt auch nur 17 Bytes an Speicher und jedes der 17 Bytes wäre gleich stark geschützt. Nimmt man dageben cmCBCx so würde der erste 16 Bytes Block vollständig geschützt sein. Das Byte 17 würde entweder durch weitere 15 Bytes zu einem vollständigen Datenblock expandiert und dann verschlüsselt. Das bedeutet aber unser Ciphertext wäre nun 32 Bytes statt 17 Bytes groß, also expandiert. Desweiteren müssen wir diese 15 Bytes mit einer bekannten Signature versehen damit wir bei der ENtschlüsselung wieder die exakten 17 Bytes restaurieren können. Diese bekannte Signature ist aber ein Problem stellt sie ja ein Angriffsziel eines Angreifers dar. Oder man benutzt CipherText Stealiung als Padding-Verfahren. Dann würde man aus 17 bytes auch 17 Bytes Ciphertext erzeugen, also keine Expansion. Man "stiehlt" aber bestimmte Bytes zur virtuellen Expansion aus dem vorherigen Datenblock. Existiert aber kein vorheriger Datenblock, die Nachricht ist als < 16 Bytes lang, dann haben wir ein Problem, denn wir "stehlen" quasi Informationen direkt aus dem Passwort. Der so entstehende CipherText ist also schwach und könnte unter Umständen für Angriffe empfindlich sein.
Deshalb benutzt
DEC eine Methode bei der im cmCBCx Modus bei denn verbleibenden Bytes in den korresponierenhden cmCBC8 Modus gewechselt wird. Das IST NICHT STandardkonform, obwohl ich mit dieser Wahl im
DEC nicht die einzigste Bibliotrhek bin die es genauso macht. Es gibt aber keinen Standard dafür ;(
Davon abgesehen relativiert sich diese "Standard"-gehabe im Falle der Ciphermodis erheblich. Denn defakto existiert noch garkein international annerkannter und wissenschaftlich geprüftere Standard. AES/NIST arbeitet noch immer daran und hat schon einige Modis selektiert aber noch nicht endgültig verabschiedet.
Ergo: Standardkonform heist hier nur ob du kompatibel zu den meisten Librarys sein möchtest, und das wäre mit cmCBC8, cmCBCx, cmCFB8, cmOFB8 auf jeden Falle gegeben.
Wichtig ist nur eines, niemals cmECB benutzen, es sei den deine Daten bestehen aus Zufall !!
Gruß Hagen