Zitat:
Aber zudem möchte ich noch weitere Änderungen vornehmen: Ich möchte nicht mehr SHA-1 verwenden und stattdessen einen Hash mit 256Bit. Welchen kannst du mir von denen, die im alten
DEC enthalten sind, da am ehesten empfehlen? Es gibt nicht um Geschwindigkeit, sondern lediglich um Sicherheit.
Du meinst zur Erzeugung des Sessionkeys aus dem Passwort ?
Im neuen
DEC würde ich SHA256 empfehlen, aber....
In deinem Falle ist SHA1 mit echten 160Bits gut, du könntest aber auch RipeMD256 nehmen, allerdings meinen die Experten das dieser nicht sicherer als 128 Ripe MD wäre, da eben nur ein Derivat davon.
Im alten
DEC gibt es bis auf Sapphire in fakt keinen Hash mit mehr als effektiven 160 Bits. Man muß stark differenzieren ob einen Hash funktion mit 256,384,512 Bits diese Digest real produzieren oder aber nur durch Anwendung eines kleineren Bruders. Bei Ripe MD ist dies der Fall. Der 256 Bit RipeMD ist ein Trick der auf 128 Bit RipeMD basiert. Trotzdem würde ich Sappihre nicht empfehlen, da er eigentlich ein umgebauter Cipher ist. Besser wäre dann schon Haval, denn der produziert echte 256 Bit.
Zitat:
Außerdem habe ich vor, auch bei der Verschlüsselung von Dateien einen Random-String hinter dem Hash-Wert mit anzuhängen. Aber wie groß ist die Blockgröße bei Rijndael? Der Hash mit 256 Bit hat ja nun 32 Byte. Angenommen ein Block hätte 1024 Byte, dann müsste ich ihn aus Sicherheitsgründen mit 992 Byte auffüllen. Wäre also nett, wenn du mir die Blockgröße sagen könntest.
Die Blockgröße von Rijndael ist = .BufferSize. Im neuen
DEC habe ich auch daran gearbeitet da die .BlockSize <> .BufferSize sein kann. Dies trifft aber nur auf Stream Cipher zu.
Schau dir TCipher_Rijndael.GetContext() an.
Im
DEC gibts keine Cipher mit so enorm großen Blockgrößen. Meistens sind sie 8,16,24,32,64 Bytes groß.
Wenn du den Hashwert + Randomsalt als erste Daten verschlüsselst dann sollte der Randomsalt >= 16 Bytes sein und (Length(HashWert) + Length(RandomSalt)) mod Cipher.BufferSize == 0. D.h. die Gesamtlänge des Hashes + Salts sollte ein mehrfaches der Blockgröße sein. Damit umgehst du das Problem das z.B. im CBC/CTS Modus ein Padding notwendig wäre. Denn in diesen Modis müssen alle sequentiellen Daten immer in Stücken zu BufferSize Bytes dem Cipher übergeben werden. Im neuen
DEC habe ich deswegen auch neue Ciphermodis implementiert. Ideal wären in diesem Falle die neuen CFBx,OFBx,CFSx Modis. Bei denen muß man nicht mehr auf dieses Blockgrößen Problem achten.
Ich arbeite daran universelle Funktionen zur ver/Entschl. von Streams in's neue
DEC einzubauen. Diese wird einen Header benutzen um den verwendeten Hash/Cipher Algo. zu speichern. Desweiteren wird ein PasswortSalt eingeführt der zusammen mit dem Passwort per KDF gehasht wird. Der entstehende Wert ist der Sessionkey der immer die maximale Schlüsselgröße des Ciphers berücksichtigt. Zusätzlich dazu wird eine sichere Checksumme verschlüsselt gespeichert die es ermöglicht die Korrektheit des Passwortes zu prüfen, usw. usw. Eventuell integriere ich noch meine LHSZ Komprimierung.
Gruß Hagen