Shop-Zugangsdaten verschlüsseln

[freimatz]

So, jetzt kam ich mal dazu das auszuprobieren. Danke erstmal für den Hinweis und den Code.
Diese API kannte ich noch gar nicht. Die hätte ich vor 20 Jahren schon brauchen können.
Der Code hier läuft bei mir hier ohne Probleme durch. (Berlin)

Ein Frage hätte ich noch. Ich beziehe mich auf den Beispielscode:
encrypted := TProtectedData.Protect( inbuffer ); // verschlüsseln

Das encrypted kann da doch Nullen enthalten. Das ist meine Erkenntnis beim Debuggen. Wenn ich das nun in einer INI-Datei o.ä. speichern will, muss ich das nochmals codieren z.B. mit base64.
Sehe ich das so richtig?
(Nein ich brauche kein Beispiel wie base64 geht)

[Uwe Raabe]

Zitat von freimatz:

encrypted := TProtectedData.Protect( inbuffer ); // verschlüsseln

Das encrypted kann da doch Nullen enthalten. Das ist meine Erkenntnis beim Debuggen. Wenn ich das nun in einer INI-Datei o.ä. speichern will, muss ich das nochmals codieren z.B. mit base64.
Sehe ich das so richtig?

Korrekt.

Wie ich das sehe, ist encrypted als TBytes deklariert. Das kann so direkt gar nicht in eine INI-Datei geschrieben werden, sondern muss erst in einen String umgewandelt werden. Da kein TEncoding das für jede beliebige Byte-Sequenz hinbekommt (siehe z.B. Nullen), bietet sich hier sowas wie Base64 geradezu an.

[freimatz]

Danke.

[Schokohase]

Nichts was ein Class Helper nicht lösen könnte

Delphi-Quellcode:

uses
  System.Classes, System.IniFiles, System.SysUtils;

type
  TCustomIniFileHelper = class helper for TCustomIniFile
  public
    function ReadBytes( const Section, Name: string ): TBytes;
    procedure WriteBytes( const Section, Name: string; const Value: TBytes );
  end;

implementation

{ TCustomIniFileHelper }

function TCustomIniFileHelper.ReadBytes( const Section, Name: string ): TBytes;
var
  stream: TBytesStream;
begin
  stream := TBytesStream.Create( );
  try
    Self.ReadBinaryStream( Section, Name, stream );
    Result := stream.Bytes;
  finally
    stream.Free( );
  end;
end;

procedure TCustomIniFileHelper.WriteBytes( const Section, Name: string; const Value: TBytes );
var
  stream: TBytesStream;
begin
  stream := TBytesStream.Create( Value );
  try
    Self.WriteBinaryStream( Section, Name, stream );
  finally
    stream.Free( );
  end;
end;

[KodeZwerg]

*entfernt, ich verstehe TE gerade nicht*

[freimatz]

Tja, Sorry Kathinka, das war für die Katz

Zitat von freimatz:

... in einer INI-Datei o.ä. ...

Wenn man eine "INI-Datei" verwendet geht das schon, nicht aber bei "o.ä."

Zitat von freimatz:

(Nein ich brauche kein Beispiel wie base64 geht)

[freimatz]

Vielleicht doch? ...
Den Code habe ich für meine Bedürfnisse erweitert. Ich bin Jetzt auf XE2. Dank Kodezwerg konnte ich das auch da zum Laufen bringen.
Bei der ersten Erweiterung geht um Base 64. Als Grundlage nahme ich das Beispiel oben mit "procedure SmallTest( );"

Delphi-Quellcode:

uses
  ...
  Soap.EncdDecd,
...
function EncryptStringToBase64(const S: String): String;
var
  inBuffer, outBuffer, encrypted: TBytes;
begin
  inBuffer := TEncoding.UTF8.GetBytes( S );
  encrypted := TProtectedData.Protect( inbuffer ); // verschlüsseln
  Result := EncodeBase64(encrypted,Length(encrypted));
  Result := StringReplace(Result, #13#10, '', [rfReplaceAll]);
end;

function DecryptBase64ToString(const S: String): String;
var outBuffer, encrypted: TBytes;
begin
  encrypted := DecodeBase64(S);
  outBuffer := TProtectedData.Unprotect( encrypted ); // entschlüsseln
  Result := TEncoding.UTF8.GetString( outBuffer );
end;

Dazu habe ich einen unit-test gemacht:

Delphi-Quellcode:

procedure TTest_LoginCrypt.Test_Basic1();
var
  orginal: String;
  crypt: String;
  decrypt: String;
begin
  orginal := 'DesÜsch a Passwörd!';
  crypt := EncryptStringToBase64(orginal);
  decrypt := DecryptBase64ToString(crypt);
  CheckEquals(orginal, decrypt, 'decrypt');
end;

Der läuft gut. Anders sieht es mit dem nächsten aus.

Delphi-Quellcode:

procedure TTest_LoginCrypt.Test_Basic2();
const expected =
  'AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAR6WMUwdNMUWKnnyFGb2XNAAAAAACAAAAAAAQZgAAAAEAACAAAAB54/kNaa'+
  'FIZe84QZZTmPvuZ9asbR6NoCsGdTGhpYDS4AAAAAAOgAAAAAIAACAAAAD44yDX7VmMRv6NO3Sf1fBdJXAd6YmB1HRb'+
  '75aqGm1XCyAAAAAx+BMspmyEA9ymHt02gmt60xXA0JRYzzEtQirpBUSGvUAAAADD6HkiNivbUlSN1LW8293Bq7ktHA'+
  'ca7+3zscNrTPbfqo7zg/cQZLFhIPHVaW8Gqp+fsa9Nx3p4u/XRI0EdsT1n';
var
  orginal: String;
  crypt: String;
  decrypt: String;
begin
  orginal := 'DesÜsch a Passwörd!';
  crypt := EncryptStringToBase64(orginal);
  CheckEquals(expected, crypt, 'crypt');
  decrypt := DecryptBase64ToString(crypt);
  CheckEquals(orginal, decrypt, 'decrypt');
end;

Beim ersten Mal geht er schief, klar denke ich die Daten passen nicht. Ich kopiere mir die richtigen Daten aus dem Debugger oder unit-test Ergebnis raus. Aber bei jedem Durchlauf werden andere Daten erwartet.
Wo ist mein Denkfehler?

[Schokohase]

Weil bei jedem Protect mit einem zusätzlichen (zufälligem) Salt verschlüsselt wird (macht die API von selber). Dadurch ist die Verschlüsselte Code-Folge immer unterschiedlich auch wenn die zu verschlüsselnden Daten gleich sind.

[KodeZwerg]

Zitat von Schokohase:

Weil bei jedem Protect mit einem zusätzlichen (zufälligem) Salt verschlüsselt wird (macht die API von selber). Dadurch ist die Verschlüsselte Code-Folge immer unterschiedlich auch wenn die zu verschlüsselnden Daten gleich sind.

Wenn ich das richtig gesehen habe, hast Du bereits ein Overload eingebaut damit man selbst den Salt bestimmen kann, was ja einem Passwort recht nahe kommt, zumindest für den Lokal Angemeldeten User. Oder ich verstehe da etwas falsch (AOptionalEntropy).

[Schokohase]

Zitat von KodeZwerg:

Zitat von Schokohase:

Weil bei jedem Protect mit einem zusätzlichen (zufälligem) Salt verschlüsselt wird (macht die API von selber). Dadurch ist die Verschlüsselte Code-Folge immer unterschiedlich auch wenn die zu verschlüsselnden Daten gleich sind.

Wenn ich das richtig gesehen habe, hast Du bereits ein Overload eingebaut damit man selbst den Salt bestimmen kann, was ja einem Passwort recht nahe kommt, zumindest für den Lokal Angemeldeten User. Oder ich verstehe da etwas falsch (AOptionalEntropy).

Ja, man kann damit Komplexität der Verschlüsselung zu vergrößern. Und ja, zum Entschlüsseln wird diese Bytefolge benötigt. Man könnte das durchaus im weitesten Sinne als Passwort verstehen.

Trotz allem bekommt man bei gleichen Eingangswerten beim Protect immer unterschiedliche Byte-Folgen zurück