Recent

Author Topic: DCPCrypt Transportability  (Read 3484 times)

FOV_2001

  • New Member
  • *
  • Posts: 21
DCPCrypt Transportability
« on: February 10, 2020, 06:29:32 pm »
Dear All,

After a lot of test, I have a problem with DCPCrypt Library from one machine encrypting in Delphi, to be decrypted in other machine using Lazarus

Same Library (DCPCrypt) same Hash and Same Cypher.

Here the Encrypt and Decrypt functions SAME at both programs (Delphi & Lazarus)

Code: Pascal  [Select][+][-]
  1. function TMod_Encripcion.Encrypt_String(KeyStr, Texto : String): string;
  2.  var
  3.    i: integer;
  4.    Cipher: TDCP_3des;
  5.  begin
  6.    if KeyStr <> '' then  // get the passphrase
  7.    begin
  8.      Cipher:= TDCP_3des.Create(Self);
  9.      Cipher.InitStr(KeyStr,TDCP_sha256);         // initialize the cipher with a hash of the passphrase
  10.      Result := Cipher.EncryptString(Texto);
  11.      Cipher.Burn;
  12.      Cipher.Free;
  13.    end;
  14.  end;
  15.  
  16. function TMod_Encripcion.Decrypt_String(KeyStr, Texto : String): string;
  17.  var
  18.    i: integer;
  19.    Cipher: TDCP_3des;
  20.  begin
  21.    if KeyStr <> '' then  // get the passphrase
  22.      begin
  23.        Cipher:= TDCP_3des.Create(Self);
  24.        Cipher.InitStr(KeyStr,TDCP_sha256);         // initialize the cipher with a hash of the passphrase
  25.        Result := Cipher.DecryptString(Texto);
  26.        Cipher.Burn;
  27.        Cipher.Free;
  28.      end;
  29.  end;
  30.  
  31.  

The result on the same machine Works perfectly, BUT if I take the Encrypted result on one machine, and try to decrypt on the other, the result is literally garbage.

Any thougths,  & or help to makle this transportable, Will be appreciated.

Xor-el

  • Sr. Member
  • ****
  • Posts: 404
Re: DCPCrypt Transportability
« Reply #1 on: February 10, 2020, 06:42:58 pm »
Direct encryption on strings is always bound to end in tears because of encoding and OS format settings differences.
Also do note that Modern Delphi strings are UTF16 while Lazarus/FPC is ANSI, UTF8 or UTF16 depending on the mode.

All these been said, I suggest you operate on bytes directly to avoid issues like this.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: DCPCrypt Transportability
« Reply #2 on: February 10, 2020, 07:05:29 pm »
Indeed, especially for Ansi vs UTF8 .
IBut when both sides use the Unicodestring versions (That is UTF16) it should work on every machine.

That said, better to use the EncryptDecrypt versions on the data as bytes, or the streams.
Make sure that the string types are properly and specifically declared. If you use unicodestring as string type it is likely to work,
Specialize a type, not a var.

FOV_2001

  • New Member
  • *
  • Posts: 21
Re: DCPCrypt Transportability
« Reply #3 on: February 11, 2020, 02:21:06 pm »
Indeed, especially for Ansi vs UTF8 .
IBut when both sides use the Unicodestring versions (That is UTF16) it should work on every machine.

That said, better to use the EncryptDecrypt versions on the data as bytes, or the streams.
Make sure that the string types are properly and specifically declared. If you use unicodestring as string type it is likely to work,

Yes, I'm trying to find the differences and where they are, in order to get a solution.

Thanks a lot to both of you for the comments.

till now, UTF-8 vs UTF-16 seems to bee relevant, the length of the keys and paddings, may be other ones.

Keep you posted.

ezlage

  • Guest
Re: DCPCrypt Transportability
« Reply #4 on: February 11, 2020, 02:57:52 pm »
Maybe the problem is at storing an encrypted output at a string variable type. I always transport the ciphertext in base64, base85 or hexadecimal. This way we avoid unexpected treatment from different scenarios.

I mean, I get the output bytes - not the string - and encode them to a hex/base64/base85 string.
« Last Edit: February 11, 2020, 03:04:37 pm by ezlage »

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: DCPCrypt Transportability
« Reply #5 on: February 11, 2020, 03:20:45 pm »
Maybe the problem is at storing an encrypted output at a string variable type. I always transport the ciphertext in base64, base85 or hexadecimal. This way we avoid unexpected treatment from different scenarios.

I mean, I get the output bytes - not the string - and encode them to a hex/base64/base85 string.
No. Enryption should be at the byte level as Xor-El and I explained. An easy way is to use UnicodeStrings but that is actually just in this case.
You should encrypt on bytes, not on strings.
That is a misconception.
Specialize a type, not a var.

ezlage

  • Guest
Re: DCPCrypt Transportability
« Reply #6 on: February 11, 2020, 06:37:53 pm »
Maybe the problem is at storing an encrypted output at a string variable type. I always transport the ciphertext in base64, base85 or hexadecimal. This way we avoid unexpected treatment from different scenarios.

I mean, I get the output bytes - not the string - and encode them to a hex/base64/base85 string.
No. Enryption should be at the byte level as Xor-El and I explained. An easy way is to use UnicodeStrings but that is actually just in this case.
You should encrypt on bytes, not on strings.
That is a misconception.

Ok, but we don't know how the ciphered data are being transported. If you copy and past, send through the network, save to a database and etc, there are many steps, code, parts and conversions involved. I would try, at least.

 

TinyPortal © 2005-2018