einzelne Zeichenkette mit DEC 5.1 verschlüsseln

[dschiffler]

Hallo Hagen,

im Forum-Beitrag "Wie DEC 5.1 benutzen" hast du eine umfangreiche und wunderbare Erklärung gegeben, wie man Dateien mit DEC 5.1 verschlüsseln kann. Besonders interessant fand ich die Hinweise zur Behandlung des Passwortes.

Wie stellt sich das Ganze allerdings dar, wenn man lediglich eine einzelne Zeichenkette verschlüsseln möchte?
Da kann ich ja schlecht den verwendeten "SessionKey" mitliefern?

[negaH]

Den Sessionkey lieferst du niemals mit, dann könnte ich ja meinen Tresor gleich offen stehen lassen.

Den Salt der zur Erzeugung des Sessionkeys dient den musst du immer mitliefern. Das bedeutet das dein verschlüsselter String um zb. 16 Bytes länger wird als der unverschlüsselte String. Diese Expansion ist der Salt. Du kannst den Salt speichern wie du möchtest, bewährt hat es sich diesen am Anfang der Daten zu speichern. Diese Expansion wirst du so oder so haben müssen, wenn es sicher sein soll.

Du kannst im einfachsten Falle ausgehend von den TStream basierten Funktionen eine spezielle Funktion für deine Strings bauen. Dazu gehst du den Umweg über einen TMemoryStream. Oder du adaptierst die gleiche Methode und arbeitest direkt auf den Speicherdaten. Dann benutzt man zb. .EncodeBinary() oder .Encode().

Zb.

Delphi-Quellcode:

function Encrypt(const Value: String; const Password: String): String;
var
  Salt,SessionKey: Binary;
begin
  Salt := RandomBinary(16);
  with TCipher_XYZ.Create do
  try
    SessionKey := THash_XYZ.KDF(Password, Salt, Context.MaxKeySize, TFormat_Copy);
    Mode := cmCFS8;  // ein 8Bit Feedback Modus ist für kurze Datenmengen sicherer
    Init(SessionKey);
    Result := TFormat_MIME64.Encode(Salt + EncodeBinary(Value, TFormat_Copy));
  finally
    Free;
    ProtectBinary(Salt);
    ProtectBinary(SessionKey);
  end;
end;

Als Ausgabe dann einen INet-MIME Base64 kodierter Wert. In den ersten 16 Bytes der Salt und nachfolgend die verschlüsselten Daten. Bei der Entschlüsselung also erst aus dem MIME64 Format umwanden nach Binär dann Salt extrahieren, mit KDF Sessionkey berechnen und Daten entschlüsseln.

Delphi-Quellcode:

function Decrypt(const Value: String; const Passwod: String; String;
begin
  with TCipher_XYZ.Create do
  try
    Result := TFormat_MIME64.Decode(Value);
    SessionKey := THash_XYZ.KDF(Password, Copy(Result, 1, 16), Context.MaxKeySize, TFormat_COPY);
    Mode := cmCFS8;
    Init(SessionKey);
    
    Decode(Result[17], Result[1], Length(Result) -16);  // inplaced Entschlüsselung
    SetLength(Result, Length(Result) -16);
  finally
    Free;
    ProtectBinary(SessionKey);
  end;
end;

Die Umwandlung in das MIME64 Format ist vorteilhaft, da man so binäre Daten lesbar speichern kann. Der Nachteil ist halt das der MIME64 String eben wiederum im Verhältnis 3 zu 4 Bytes länger wird als der originale String.

Der Mode cmCFS8 ist prohibitär und von mir entwickelt. Abgeleit vom CBC8 -> Cipher Block Chaining mit 8 Bit Feedback (ist Standard), arbeitet der CFS8 im ersten Schritt identisch, verknüpft aber zusätzlich noch den verschlüsselten Output per XOR Operation mit dem internen Feedback Register. Damit kann man sich den CFS8 so vorstellen wie einen übereinandergelegten doppelten CBC, so ähnlich wie die Schindeln eines Daches. Damit ist der CFS8 Modus eine Alles-oder-Nichts Verschlüsselung. Ändert sich ein Bit in den verschlüsselten Daten so ist die komplette Entschlüsselung danach fehlerhaft. Somit höhere kryptographische Sicherheit, aber dafür keine technologische Selbsynchronisation bei der Übertragung fehlerhafter Daten. Für kurze Strings, meistens Passwörter oder andere sehr wichtige Daten, ist das eine gute Wahl.

Gruß Hagen

EDIT: Link auf angesprochenen Thread http://www.delphipraxis.net/internal...882&highlight=
macht die Sache einfacher für Mitleser.

[dschiffler]

Hallo Hagen,

danke für die schnelle Anzwort.

Zitat:

Den Sessionkey lieferst du niemals mit, dann könnte ich ja meinen Tresor gleich offen stehen lassen.
Den Salt der zur Erzeugung des Sessionkeys dient den musst du immer mitliefern.

Du hast natürlich Recht, ich meinte auch den Salt in Bezug auf deine Erläuterungen, wo der Salt an den Anfang der verschlüsselten Datei geschrieben wurde.

Zitat:

Das bedeutet das dein verschlüsselter String um zb. 16 Bytes länger wird als der unverschlüsselte String. Diese Expansion ist der Salt. Du kannst den Salt speichern wie du möchtest, bewährt hat es sich diesen am Anfang der Daten zu speichern. Diese Expansion wirst du so oder so haben müssen, wenn es sicher sein soll.

Das war der entscheidende Hinweis. So einfach kann es manchmal sein.
Danke für die Info.

Zitat:

Link auf angesprochenen Thread ... macht die Sache einfacher für Mitleser.

Werde ich beim nächsten Mal berücksichtigen, danke für den Hinweis.


Noch eine Frage zum CipherMode:
Im erwähnten Beitrag von dir hast du cmCTS verwendet, hier empfiehlst du cmCFS8. Ich möchte alle Encrypt-Funktionen in einer Unit haben und nur einen CipherMode verwenden, egal, ob ich einzelne Zeichenketten, Dateien oder Streams verschlüssele.
Welchen CipherMode empfiehlst du?
Welchen Cipher-Algorithmus empfiehlst du?

[negaH]

Tja das sind Fragen

Ich empfehle, und das musst du mit Vorsicht geniesen!, cmCTS und cmCFS weil ich diese selber gebaut habe sie verstehe. Ich emfehle beide da es eben unterschiedliche Anforderungen gibt, zb. Performance. cmCTSx ist im Grunde das Gleiche wie cmCFS8, nur mit dem Unterschied das CTS auf Blockgröße des Ciphers arbeitet und CFS8 auf Bytegröße im Feedback Register. Jo ist ne blöde Namensgebung da ich ja beim cmCFBx und cmCFB8 diesen Fehler nicht gemacht habe.

Der beste Kompromiss wird sein sich auf cmCTSx zu einigen. Dieser arbeitet bei ganzen Datenblöcken auch auf Blockgröße und ist demzufolge circa 16 mal schneller beim AES wie cmCFS8. Sobald ein Datenblock nicht BlockSize Bytes groß ist, wechselt der Cipher automatisch in den cmCFS8 Modus und fängt an damit die restlichen Bytes zu verschlüsseln. Danach befindet sich der Cipher im csPadded Status und kann keine weiteren Datenblöcke verschlüsseln.

Als Cipheralgorithmus gibt es viele zur Auswahl, auch wieder abhängig von den Anforderung. Ich persönlich finde RC4, leicht abgewandelt gut wenn ich zb. für den Palm Handheld meine Kommunikation per TCP/IP mit einem Server von mir entwickelt hatte. RC4 nutze ich auch in einigen meiner Bootloader für Mikrokontroller auf AVR oder ARM basis. Einfach weil RC4 leicht zu handhaben ist, da Streamcipher und auf jeder Plattform sehr einfach zu programmieren geht. Gleichs gilt für TEA und XTEA, diese sind super einfach und sehr schnell auf solchen Plattformen zu programmmieren.
Auf PCs bevorzuge ich AES, weil es eben Standard ist und als sicher gilt. Oder IDEA den ich auf Grund der Patente/Lizensen zwar niemals benutze dessen Design ich aber super finde. Als Hash SHA1, manchmal auch SHA256/384 und auch RipeMD aus politischen Gründen da dieser eropäisch ist und nicht amerikanisch. Bendenkt man die lange Zeit herrschende Vorgehensweise der USA bei solchen Verfahren sollte man eigentlich immer misstrauisch sein. Ansonsten noch MD4/5 falls ich bestehende Protokolle die diese Algos. nutzen implementieren muß. Es bleibt dann ja nichts anderes übrig. SCOP finde ich auch noch gut. Und das ist noch mein PMC wenn ich was ganz kompliziert haben möchte. Das ist ein polymorpher Cipher dh. der hat keine feststehende Encryptionfunktion sondern diese wird aus dem Schlüselstrom quasi zur Laufzeit kompiliert. Und das dann aber blockweise, also jeder Datenblock a 16 Bytes wird mit einer eigenen zur Laufzeit auf Grund eines Schlüselstromes komplierten Verschlüsselungsfunktion verschlüsselt. Das hat den Vorteil das zb. bei einer Nachricht mit 256 Bytes insgesamt also 16 verschiedene Verschlüsselungsfunktonen kopiliert werden die jede jeweils bis zu 512 Kb an Code enthält -> macht also 8 MByte an Verschlüsselungfunktionscode und wird einen Cracker auf die Palme bringen. Denn dieser produzierte Maschinencode ist abhängig vom Passwort und den Daten die man verschlüsselt Ansonsten ist dieses Monster schnarch lahm. Dann habe ich noch einen Cipher entwickelt der die Daten als komplettes Packet verschlüsselt. Im Gegensatz zu heutigen Verfahren die immer in Byteströmen oder Blöcken aus x Bytes arbeiten arbeitet dieser Cipher also auf der kompletten Nachricht als Gesammtes. Das bietet ganz andere Möglichkeiten der kryptographischen Sicherheit, zb. komplette Verwürfelung der gesammten Nachricht, arbeiten mit der Mathematik der Zahlentheorie, dh. die komplette Nachricht wird als super große Zahl betrachtet, und die Benutzung perfekter Komprimierungen zu Beseitigung jedweiger Redundanz. Auch dieses Teil ist schnarch langsam aber dürfte enorm sicher sein. Praktisch gesehen von wenig Relevanz ausser man möchte Hochsicherheitssysteme bauen.

Naja, eben für jeden Anwendungsbereich ein eigener Ansatz je nach Aufgabenstellung. Mit AES+SHA1 macht man nichts falsch.

Gruß Hagen

[dschiffler]

Hallo Hagen,

recht vielen Dank für deine ausführlichen Antworten.