I need to communicate from a Delphi application to a C# application. The C# application enforces encryption using the Rfc2898derivebytes among other things. I have got Password, Salt and the resulting bytes of the Rfc2898DeriveBytes. My implementation using CryptoLib4Pascal is shown below.
The Hasdh256 part is proven to be right towards the C# source. Any suggestions on what is wrong with the ClpGenerator part?
Hash256 := THashFactory.TCrypto.CreateSHA2_256;
Hash256Result := Hash256.ComputeString(Key, TEncoding.UTF8);
KeyBytes := Hash256Result.GetBytes;
SaltBytes := TConverters.ConvertStringToBytes(Salt, TEncoding.UTF8);
ClpGenerator := TPkcs5S2ParametersGenerator.Create(TDigestUtilities.GetDigest('SHA-1'));
ClpGenerator.Init(KeyBytes, SaltBytes, 1000);
PBKDF2_KeyBytes := (ClpGenerator.GenerateDerivedMacParameters(48 * 8) as IKeyParameter).GetKey();
SetLength(CryptKey, 32);
Move(PBKDF2_KeyBytes[0], CryptKey[0], 32);
SetLength(CryptIV, 16);
Move(PBKDF2_KeyBytes[32], CryptIV[0], 16);
I have tried to change the salt encoding from UTF8 to UNICODE based on this article: https://medium.com/rabbit-mobile-business-blog/writing-c-s-rfc2898derivebytes-in-php-88fa8c096dcb
Related
I have a client providing an API that dictates the data to send to them must be encrypted with AES, 128-bit key, ECB mode, and PKCS5Padding. I'm trying to use LockBox 3 in Delphi 10.3 Rio and am not getting the same encrypted string as an online test tool they pointed to for verification. It is close, but not quite there.
With lots of reading here about Unicode, PKCS5Padding, and related questions, I've come to the end of what to try. I must admit I don't do very much with encryption and have been reading as much as I can to get my head around this before I ask questions.
There are a couple things I'd like confirmation on:
The difference between a password and a key. I've read that LB3 uses a password to generate a key, but I have specific instructions from the client on how the key is to be generated so I've made my own Base64-encoded key and am calling InitFromStream to initialize it. I believe this takes the place of setting a password, is that right? Or maybe passwords are only used by Asymetric cipers (not Symetric ones, like AES)?
PKCS5Padding: I was worried by something I read on the LB3 Help site that said padding is done intelligently depending on the choice of cipher, chaining mode, etc. So does that mean there's no way to force it to use a specific padding method? I've converted the data to a byte array and implemented by own PKCS5Padding but I think LB3 may still be padding beyond that. (I've tried looking through the code and have not found any evidence this is what it's doing.)
Should I use a different encryption library in Delphi to accomplish this? I've checked out DelphiEncryptionCompendium and DcPCryptV2 but I found LB3 seems to have the most support and I felt it was the easiest to work with, especially in my Unicode version of Delphi. Plus I have used LockBox 2 quite a bit in years past, so I figured it would be more familiar (this turned out not to be the case).
To illustrate what I've tried, I extracted my code from the project to a console application. Perhaps my assumptions above are correct and there's a glaring error in my code or a LB3 parameter I don't understand that someone will point out:
program LB3ConsoleTest;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils, System.Classes, System.NetEncoding,
uTPLb_Codec, uTPLb_CryptographicLibrary,
uTPLb_StreamUtils, uTPLb_Constants;
var
Codec: TCodec;
CryptographicLibrary: TCryptographicLibrary;
function PKCS5PadStringToBytes(RawData: string; const PadSize: Integer): TBytes;
{ implement our own block padding }
var
DataLen: Integer;
PKCS5PaddingCount: ShortInt;
begin
Result := TEncoding.UTF8.GetBytes(RawData);
DataLen := Length(RawData);
PKCS5PaddingCount := PadSize - DataLen mod PadSize;
if PKCS5PaddingCount = 0 then
PKCS5PaddingCount := PadSize;
Inc(DataLen, PKCS5PaddingCount);
SetLength(Result, DataLen);
FillChar(Result[DataLen - PKCS5PaddingCount], PKCS5PaddingCount, PKCS5PaddingCount);
end;
procedure InitializeAESKey(const AESKey: string);
{ convert the string to a byte array,
use that to initialize a ByteStream,
and call LB3's InitFromStream }
var
AESKeyBytes: TBytes;
AESKeyStream: TBytesStream;
begin
AESKeyBytes := TEncoding.UTF8.GetBytes(AESKey);
AESKeyStream := TBytesStream.Create(AESKeyBytes);
Codec.InitFromStream(AESKeyStream);
end;
const
RawData = '{"invoice_id":"456456000018047","clerk_id":"0023000130234234","trans_amount":1150034534,"cust_code":"19455605000987890641","trans_type":"TYPE1"}';
AESKeyStr = 'CEAA31AD1EE4BDC8';
var
DataBytes: TBytes;
DataStream: TBytesStream;
ResultStream: TBytesStream;
ResultBytes: TBytes;
Base64Encoder: TBase64Encoding;
begin
// create the LockBox3 objects
Codec := TCodec.Create(nil);
CryptographicLibrary := TCryptographicLibrary.Create(nil);
try
// setup LB3 for AES, 128-bit key, ECB
Codec.CryptoLibrary := CryptographicLibrary;
Codec.StreamCipherId := uTPLb_Constants.BlockCipher_ProgId;
Codec.BlockCipherId := Format(uTPLb_Constants.AES_ProgId, [128]);
Codec.ChainModeId := uTPLb_Constants.ECB_ProgId;
// prep the data, the key, and the resulting stream
DataBytes := PKCS5PadStringToBytes(RawData, 8);
DataStream := TBytesStream.Create(DataBytes);
InitializeAESKey(AESKeyStr);
ResultStream := TBytesStream.Create;
// ENCRYPT!
Codec.EncryptStream(DataStream, ResultStream);
// take the result stream, convert it to a byte array
ResultStream.Seek(0, soFromBeginning);
ResultBytes := Stream_to_Bytes(ResultStream);
// convert the byte array to a Base64-encoded string and display
Base64Encoder := TBase64Encoding.Create(0);
Writeln(Base64Encoder.EncodeBytesToString(ResultBytes));
Readln;
finally
Codec.Free;
CryptographicLibrary.Free;
end;
end.
This program generates an encrypted string 216 characters long with only the last 25 different than what the online tool produces.
Why?
AES uses 16-bytes blocks, not 8-bytes.
So you need PKCS7 with 16 bytes padding, not PKCS5 which is fixed to 8 bytes.
Please try
DataBytes := PKCS5PadStringToBytes(RawData, 16);
Also consider changing the chaining mode away from ECB, which is pretty weak, so is to be avoided for any serious work.
I'd like to migrate my old crypto functions from lockbox2 to lockbox3 on delphi XE6.
Before to do that I've made a code (CipherComp.dpr) to compare the output, since the setup have changed.
I'm using AES-ECB (to avoid IV) 256 bits, key: '1234567890', text: 'a secret word'
Using TPLB2 I initialize like
FAES : TLbRijndael;
FAES := TLbRijndael.Create(nil);
FAES.CipherMode := cmECB; // cmECB (default), cmCBC
FAES.KeySize := ks256; // ks128, ks192
FAES.SetKey('1234567890'); // set the password here
and encrypt using:
Result := FAES.EncryptString(pString);
on the other hand on TPLB3 changes like this
FCodec: TCodec;
FCryptoLib: TCryptographicLibrary;
FCodec := TCodec.Create(nil);
FCryptoLib := TCryptographicLibrary.Create(nil);
FCodec.CryptoLibrary := FCryptoLib;
FCodec.StreamCipherId := uTPLb_Constants.BlockCipher_ProgId;
FCodec.BlockCipherId := 'native.AES-256';
FCodec.ChainModeId := uTPLb_Constants.ECB_ProgId;
FCodec.Password := '1234567890';
and encrypt
FCodec.EncryptAnsiString(pString, Result);
but the output mismatch when cipher the same text.
a secret word qD9+fF1EqdQH8C3TrEaLQg==
a secret word 1bUXLgXwob1cL6O27HMViw==
I'm doing something wrong but I can figure out what.
Any hint?
Thanks in advance.
I am sending and receiving messages from an electronic board through UDP using Delphi 6 and Indy 8. But since updating to Delphi XE4, the TIdUDPClient component sends wrong data packets. I think the problem is with the Send() function only sends in Unicode. Is it possible to send AnsiString through TIdUDPClient.Send()?
Here is the code I am using:
idudpclient1.Send(#$7e#$b8#$c7#$81#$10#$8d#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$9d#$02#$0d);
You are sending binary data as a String. In XE4, Strings are Unicode, and Indy's default encoding is ASCII. Your String data contains characters that are outside of the ASCII range.
Don't use String for binary data. That is not what it is meant for. You can get away with that in Delphi 2007 an earlier, but not in Delphi 2009 and later.
You can either:
continue using Send(), but tell it to use Indy's 8bit encoding instead of Indy's default encoding:
IdUDPClient1.Send(#$7e#$b8#$c7#$81#$10#$8d#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$00#$9d#$02#$0d, Indy8BitEncoding);
switch to SendBuffer() instead (which you should do, even in your Indy 8 code):
var
Buf: TIdBytes;
begin
SetLength(Buf, 34);
FillBytes(Buf, 34, $00);
Buf[0] := $7e;
Buf[1] := $b8;
Buf[2] := $c7;
Buf[3] := $81;
Buf[4] := $10;
Buf[5] := $8d;
Buf[31] := $9d;
Buf[32] := $02;
Buf[33] := $0d;
IdUDPClient1.Send(Buf);
end;
I'm trying to write some Romanian text into a RichEdit component (Delphi 7) , and even i set the Font Property - Charset to "EASTEUROPE_CHARSET" it doesn't work.
What i want to accomplish is to paste some text (in romanian) in a RichEdit, load into a StringList, set the property order to true and assign it to another RichEdit component (sort the list in a alphabetical order).
I know this shouldn't be a problem in Delphi2009 and up, but at this point I can work only with Delphi 7.
word examples : opoziţie, computerizată.
Any ideas?
Best regards,
Try this code, it reads the text from RichEdit1 as UNICODE text, manually converts S and T + Comma to S and T + Cedilla and then uses WideCharToMultiByte to convert the text to code page 1250. The code point conversions need to be done because code page 1250 only encodes the cedilla-based versions of Ş and Ţ, while the new Romanian keyboards under Vista and Windows 7 generate the (correct) comma-based versions of Ş and Ţ!
procedure TForm1.Button1Click(Sender: TObject);
var GetTextStruct:GETTEXTEX;
GetLenStruct:GETTEXTLENGTHEX;
RequiredBytes:Integer;
NumberOfWideChars:Integer;
WideBuff:PWideChar;
AnsiBuff:PChar;
i:Integer;
begin
;
// Get length of text
GetLenStruct.flags := GTL_NUMBYTES or GTL_USECRLF or GTL_PRECISE;
GetLenStruct.codepage := 1200; // request unicode
RequiredBytes := SendMessage(RichEdit1.Handle, EM_GETTEXTLENGTHEX, Integer(#GetLenStruct), 0);
// Prepare structure to get all text
FillMemory(#GetTextStruct, SizeOf(GetTextStruct), 0);
GetTextStruct.cb := SizeOf(GetTextStruct);
GetTextStruct.flags := GT_USECRLF;
GetTextStruct.codepage := 1200; // request unicode
WideBuff := GetMemory(RequiredBytes);
try
// Do the actual request
SendMessage(RichEdit1.Handle, EM_GETTEXTEX, Integer(#GetTextStruct), Integer(WideBuff));
// Replace the "new" diactrics with the old (make Romanian text compatible with code page 1250)
NumberOfWideChars := RequiredBytes div 2;
for i:=0 to NumberOfWideChars-1 do
case Ord(WideBuff[i]) of
$0218: WideBuff[i] := WideChar($015E);
$0219: WideBuff[i] := WideChar($015F);
$021A: WideBuff[i] := WideChar($0162);
$021B: WideBuff[i] := WideChar($0163);
end;
// Convert to code-page 1250
RequiredBytes := WideCharToMultiByte(1250, 0, WideBuff, -1, nil, 0, nil, nil);
AnsiBuff := GetMemory(RequiredBytes);
try
WideCharToMultiByte(1250, 0, WideBuff, -1, AnsiBuff, RequiredBytes, nil, nil);
Memo1.Lines.Text := AnsiBuff; // AnsiBuff now contains the CRLF-terminated version of the
// text in RichEdi1, corectly translated to code page 1250
finally FreeMemory(AnsiBuff);
end;
finally FreeMemory(WideBuff);
end;
end;
Then use something similar to turn AnsiString into UNICODE and push into the RichEdit.
Of course, the only real solution is to switch to Delphi 2009 or Delphi 2010 and use Unicode all over.
i've resolved it with JvWideEditor from Jedi. Code is bellow
procedure TForm2.SortUnicode;
var asrt:TWStringList;
i:Integer;
begin
JvWideEditor1.Lines.Clear;
JvWideEditor2.Lines.Clear;
asrt:=TWStringList.Create;
if OpenDialog1.Execute then
begin
wPath:=OpenDialog1.FileName;
JvWideEditor1.Lines.LoadFromFile(wPath,[foUnicodeLB]);
try
asrt.AddStrings(JvWideEditor1.Lines);
for i:=asrt.Count-1 downto 0 do
begin
if Trim(asrt.Strings[i])='' then
asrt.Delete(i);
end;
asrt.Duplicates:=dupAccept;
asrt.CaseSensitive:=true;
asrt.Sorted:=True;
JvWideEditor2.Lines.AddStrings(asrt);
JvWideEditor2.Lines.SaveToFile(GetCurrentDir+'\res.txt',[foUnicodeLB]);
finally
FreeAndNil(asrt);
end;
end;
end;
Check the language settings in Windows. If you are running English windows, try setting the "treat non-unicode programs as..." to Romanian. Or, run on native Romanian Windows. To run in a mixed environment (needing to show different charsets simultaneously), you'll likely need Unicode.
I had some code before I moved to Unicode and Delphi 2009 that appended some text to a log file a line at a time:
procedure AppendToLogFile(S: string);
// this function adds our log line to our shared log file
// Doing it this way allows Wordpad to open it at the same time.
var F, C1 : dword;
begin
if LogFileName <> '' then begin
F := CreateFileA(Pchar(LogFileName), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_ALWAYS, 0, 0);
if F <> 0 then begin
SetFilePointer(F, 0, nil, FILE_END);
S := S + #13#10;
WriteFile(F, Pchar(S)^, Length(S), C1, nil);
CloseHandle(F);
end;
end;
end;
But CreateFileA and WriteFile are binary file handlers and are not appropriate for Unicode.
I need to get something to do the equivalent under Delphi 2009 and be able to handle Unicode.
The reason why I'm opening and writing and then closing the file for each line is simply so that other programs (such as WordPad) can open the file and read it while the log is being written.
I have been experimenting with TFileStream and TextWriter but there is very little documentation on them and few examples.
Specifically, I'm not sure if they're appropriate for this constant opening and closing of the file. Also I'm not sure if they can make the file available for reading while they have it opened for writing.
Does anyone know of a how I can do this in Delphi 2009 or later?
Conclusion:
Ryan's answer was the simplest and the one that led me to my solution. With his solution, you also have to write the BOM and convert the string to UTF8 (as in my comment to his answer) and then that worked just fine.
But then I went one step further and investigated TStreamWriter. That is the equivalent of the .NET function of the same name. It understands Unicode and provides very clean code.
My final code is:
procedure AppendToLogFile(S: string);
// this function adds our log line to our shared log file
// Doing it this way allows Wordpad to open it at the same time.
var F: TStreamWriter;
begin
if LogFileName <> '' then begin
F := TStreamWriter.Create(LogFileName, true, TEncoding.UTF8);
try
F.WriteLine(S);
finally
F.Free;
end;
end;
Finally, the other aspect I discovered is if you are appending a lot of lines (e.g. 1000 or more), then the appending to the file takes longer and longer and it becomes quite inefficient.
So I ended up not recreating and freeing the LogFile each time. Instead I keep it open and then it is very fast. The only thing I can't seem to do is allow viewing of the file with notepad while it is being created.
For logging purposes why use Streams at all?
Why not use TextFiles? Here is a very simple example of one of my logging routines.
procedure LogToFile(Data:string);
var
wLogFile: TextFile;
begin
AssignFile(wLogFile, 'C:\MyTextFile.Log');
{$I-}
if FileExists('C:\MyTextFile.Log') then
Append(wLogFile)
else
ReWrite(wLogFile);
WriteLn(wLogfile, S);
CloseFile(wLogFile);
{$I+}
IOResult; //Used to clear any possible remaining I/O errors
end;
I actually have a fairly extensive logging unit that uses critical sections for thread safety, can optionally be used for internal logging via the OutputDebugString command as well as logging specified sections of code through the use of sectional identifiers.
If anyone is interested I'll gladly share the code unit here.
Char and string are Wide since D2009. Thus you should use CreateFile instead of CreateFileA!
If you werite the string you shoudl use Length( s ) * sizeof( Char ) as the byte length and not only Length( s ). because of the widechar issue. If you want to write ansi chars, you should define s as AnsiString or UTF8String and use sizeof( AnsiChar ) as a multiplier.
Why are you using the Windows API function instead of TFileStream defined in classes.pas?
Try this little function I whipped up just for you.
procedure AppendToLog(filename,line:String);
var
fs:TFileStream;
ansiline:AnsiString;
amode:Integer;
begin
if not FileExists(filename) then
amode := fmCreate
else
amode := fmOpenReadWrite;
fs := TFileStream.Create(filename,{mode}amode);
try
if (amode<>fmCreate) then
fs.Seek(fs.Size,0); {go to the end, append}
ansiline := AnsiString(line)+AnsiChar(#13)+AnsiChar(#10);
fs.WriteBuffer(PAnsiChar(ansiline)^,Length(ansiline));
finally
fs.Free;
end;
Also, try this UTF8 version:
procedure AppendToLogUTF8(filename, line: UnicodeString);
var
fs: TFileStream;
preamble:TBytes;
outpututf8: RawByteString;
amode: Integer;
begin
if not FileExists(filename) then
amode := fmCreate
else
amode := fmOpenReadWrite;
fs := TFileStream.Create(filename, { mode } amode, fmShareDenyWrite);
{ sharing mode allows read during our writes }
try
{internal Char (UTF16) codepoint, to UTF8 encoding conversion:}
outpututf8 := Utf8Encode(line); // this converts UnicodeString to WideString, sadly.
if (amode = fmCreate) then
begin
preamble := TEncoding.UTF8.GetPreamble;
fs.WriteBuffer( PAnsiChar(preamble)^, Length(preamble));
end
else
begin
fs.Seek(fs.Size, 0); { go to the end, append }
end;
outpututf8 := outpututf8 + AnsiChar(#13) + AnsiChar(#10);
fs.WriteBuffer(PAnsiChar(outpututf8)^, Length(outpututf8));
finally
fs.Free;
end;
end;
If you try to use text file or Object Pascal typed/untyped files in a multithreaded application you gonna have a bad time.
No kidding - the (Object) Pascal standard file I/O uses global variables to set file mode and sharing. If your application runs in more than one thread (or fiber if anyone still use them) using standard file operations could result in access violations and unpredictable behavior.
Since one of the main purposes of logging is debugging a multithreaded application, consider using other means of file I/O: Streams and Windows API.
(And yes, I know it is not really an answer to the original question, but I do not wish to log in - therefor I do not have the reputation score to comment on Ryan J. Mills's practically wrong answer.)