DCPCrypt Transportability
lazarus / 5-Lazarus Extra Components

----------------------------------------------------------------------
FOV_2001 · 2020-02-10 17:29

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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i function
TMod_Encripcion.Encrypt_String(KeyStr, Texto : String): string; var 
 i: integer;   Cipher: TDCP_3des; begin   if KeyStr <> '' then  // get
the passphrase   begin     Cipher:= TDCP_3des.Create(Self);   
 Cipher.InitStr(KeyStr,TDCP_sha256);         // initialize the cipher
with a hash of the passphrase     Result :=
Cipher.EncryptString(Texto);     Cipher.Burn;     Cipher.Free; 
 end; end; function TMod_Encripcion.Decrypt_String(KeyStr, Texto :
String): string; var   i: integer;   Cipher: TDCP_3des; begin   if
KeyStr <> '' then  // get the passphrase     begin       Cipher:=
TDCP_3des.Create(Self);       Cipher.InitStr(KeyStr,TDCP_sha256);    
   // initialize the cipher with a hash of the passphrase       Result
:= Cipher.DecryptString(Texto);       Cipher.Burn;       Cipher.Free; 
   end; end;  
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 · 2020-02-10 17:42

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 · 2020-02-10 18:05

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,

----------------------------------------------------------------------
FOV_2001 · 2020-02-11 13:21

Quote from: Thaddy on February 10, 2020, 07:05:29 pmIndeed, 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 · 2020-02-11 13:57

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.

----------------------------------------------------------------------
Thaddy · 2020-02-11 14:20

Quote from: ezlage on February 11, 2020, 02:57:52 pmMaybe 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.

----------------------------------------------------------------------
ezlage · 2020-02-11 17:37

Quote from: Thaddy on February 11, 2020, 03:20:45 pmQuote from: ezlage
on February 11, 2020, 02:57:52 pmMaybe 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.