I need to encrypt an 10-byte string in Delphi using 3DES.
It must get the same result than this PHP code:
function encrypt_3DES($message, $key){
$bytes = array(0,0,0,0,0,0,0,0);
$iv = implode(array_map("chr", $bytes));
$ciphertext = mcrypt_encrypt(MCRYPT_3DES, $key, $message, MCRYPT_MODE_CBC, $iv);
return $ciphertext;
I have been trying to code it using DCPCrypt and LockBox 3. I have finally discarded DCPCrypt because it hasn't been update lately and I'm not sure if it works correctly with Delphi 10.1 Berlin, so I have focused in LockBox 3, but I haven't been able to get the encryption right.
The encryption key is a 24bytes key (which I have its base64 representation). I can't find how to create such key using the TSymetricKey class of LockBox to pass it to an Codec.Init method. So I put it on an AnsiString and set it on the Password property (although the documentations says that there is a utf8Password but I can't find it).
Then there is a method called EncryptAnsiString, but again it expects strings (utf16 on Delphi 10.1 Berlin) instead of AnsiStrings (although the documentation says the contrary), so I'm not surprised that the result doesn't match what I'm looking for (the same value encrypted on that PHP snippet).
This is my Delphi Code :
function Encrypt(Data: AnsiString; LocalKey: AnsiString): AnsiString;
var
BinaryLocalKey: TBytes;
strLocalKey, strTripleDes: AnsiString;
begin
BinaryLocalKey := DecodeBase64(LocalKey);
setString(strLocalKey, PAnsiChar(#BinaryLocalKey[0]), Length(BinaryLocalKey));
Codec1.Rest;
Codec1.Password := strLocalKey;
Codec1.EncryptAnsiString(Data, strTripleDES);
Codec1.Reset;
Result := strTripleDes;
end;
But this Code not only doesn't get the same result as the PHP code, but at every call it returns a different result for the same input.
NOTE: Codec1 is a component linked to a TCryptographicLibrary component, and with the propertis ChainMode set to CBC* and Cipher set to 3DES (Keying option 1)
Does somebody know how to properly get this 3DES encryption ?.
Thank you.
A random IV is generated for each message. The low 8 bytes of the IV are a nonce and the high bytes are zero. These low 8 bytes are prepended to the output.
If you want to send the IV via a side channel, then strip the first 8 bytes out of the nominal ciphertext.
If you want to control the IV, then use version 3.7.0 (https://github.com/SeanBDurkin/tplockbox). You will need to set the advanced options and implement the OnGetIV method.
The asterisk (*) rendered in the property editors for cipher selection and chain mode selection, mean that this selection is a recommended one.
Related
I'm using Crypto API's CryptAcquireContext function (https://learn.microsoft.com/en-us/windows/desktop/api/Wincrypt/nf-wincrypt-cryptacquirecontexta) to get access to my Certificate Store contained on my USB Token, and this is working like a charm!
However, the CryptAcquireContext function is deprecated and the Crypto API documentation recommends the use of CNG to achieve the same results. All my problem now is how to use CNG to get a certificate context from my USB Token, and to achieve this I'm using the following code:
var
Provider: NCRYPT_PROV_HANDLE;
Reader: PByte;
ReaderSize: DWORD;
MemorySize: DWORD;
begin
// Get a handle to the smartcard reader specific provider
Status := NCryptOpenStorageProvider(#Provider
,'SafeSign Standard RSA and AES Cryptographic Service Provider'
,0); // returns ERROR_SUCCESS
// Convert the name of the reader to a PByte
UnicodeStringToBinary('Giesecke & Devrient GmbH StarSign CUT 0',Reader,ReaderSize);
// Inform the name of the reader to the CNG
Status := NCryptSetProperty(Provider
,NCRYPT_READER_PROPERTY
,Reader
,ReaderSize
,0); // returns ERROR_SUCCESS
MemorySize := SizeOf(HCERTSTORE);
// Try to get the size needed to a variable of type HCERTSTORE.
// This is the first step before get the certificate store
Status := NCryptGetProperty(Provider
,NCRYPT_USER_CERTSTORE_PROPERTY
,nil
,0
,#MemorySize
,0); //Returns 0x80090029 (NTE_NOT_SUPPORTED)
end;
As you can see the NCryptGetProperty function fails with error code 0x80090029 which means NTE_NOT_SUPPORTED. What I'm doing wrong? I've found an example (C++) doing the same as me, so, I guess everything is OK with my implementation, but...
My goal is to list all certificates on my smart card (actually an USB Token). I can do this using Crypto API, but the CryptAcquireContext function is deprecated, so, I need to use another one. Using CAPI I get the Certificate Store and I can list It using the default certificate dialog, so, I need, using CNG, get the Certificate Store to do the same thing, but the way I'm doing now seems wrong.
Well, some observations:
I'm not checking the returns here (Status variable) to simplify this code sample
The UnicodeStringToBinary function is strictly correct. The returned buffer (PByte) has twice the size of the original string and the bytes are all "nn 00 nn 00 nn 00", so, the Reader variable contains an Unicode String, just like the NCRYPT_READER_PROPERTY property requires. I can post the code on request.
My NCryptOpenStorageProvider signature is more close of the Windows API version, so, its first argument is a pointer to NCRYPT_PROV_HANDLE
I'm not working with delphi... but the reader name must be null-terminated.
I got this working in .NET with Microsoft Smart Card Key Storage Provider and the call:
NCrypt.NCryptSetProperty(
provider,
NCrypt.KeyStoragePropertyIdentifiers.NCRYPT_READER_PROPERTY,
Encoding.Unicode.GetBytes(smartCardReader + '\0')
);
I'm using IdWhois to work with the RFC954 protocol.
When the result contains Unicode characters like "é, ó, ç...", I just get a question mark "�" instead of the char. I usually have difficulties when need to make string conversion into Delphi. Tried examples found on Google, but no success. So right now I'm thinking maybe the protocol works only with ASCII chars? No idea.
Original code, without any try of conversion (none of them worked anyway), running on Delphi 10 Seattle:
var
Whois: TIdWhois;
RequestResult: String;
begin
Whois:= TIdWhois.Create(Nil);
Whois.ReadTimeout:= 10000;
Whois.ConnectTimeout:= 10000;
try
Whois.Host:= WhoisServer;
try
RequestResult:= Whois.WhoIs(URL);
...
If I add RequestResult to a Memo, or while debugging, I just get the question mark instead of the Unicode characters.
I`m using Delphi XE6 and Indy 10
I want to send an Unicode String as Command to a TIdCMDTCPServer from a TIdCMDTCPClient
I`m sending command with SendCMD method of IdCMDTCPClient component but received command shown as ' ? ' Character !
In fact I have a Command (for example : "USER_REG") and some parameters with that and Parameters are an Unicode String ( Persian characters )
I have set encoding of command to IndyTextEncoding_UTF8 or Encode command with UTF8Encode function but there is no chance !
Example of Command :
CMD := 'USER_REG#register_user(' + QuotedStr('محمود مهری') + ')';
TCPClient.SendCmd(CMD, -1, IndyTextEncoding_UTF8);
or
TCPClient.SendCmd(UTF8Encode(CMD), -1, IndyTextEncoding_UTF8);
How can I send Unicode Strings as Command ?
thanks ...
TIdCmdTCPServer and TIdCmdTCPClient are not designed to be used together. If you are using TIdCmdTCPServer, you should be using TIdTCPClient instead. If you want to use TIdCmdTCPClient, then at the very least DO NOT use its SendCmd() or GetResponse() methods. TIdCmdTCPClient uses an internal reading thread to receive messages from the server. That thread will interfere with GetResponse()'s reading (SendCmd() calls GetResponse() internally). Use the client's IOHandler.WriteLn() method instead, and then let the TIdCmdTCPClient.CommandHandlers read the server's response.
That being said, specifying IndyTextEncoding_UTF8 on the actual send is the correct thing to do. You can alternatively set the client's IOHandler.DefStringEncoding property instead. Either way, using UTF8Encode() in this situation is useless in Delphi 2009+, because SendCmd() (and WriteLn()) takes a UnicodeString as input, so the UTF-8 encoded RawByteString that UTF8Encode() returns will get converted by the RTL back to a UTF-16 UnicodeString, which IndyTextEncoding_UTF8 will then re-encode back to UTF-8 again during transmission. That is useless overhead.
On the server side, you need to use IndyTextEncoding_UTF8 on the reads so the incoming UTF-8 encoded commands will be decoded correctly. Since TIdCmdTCPServer is doing the actual reading for you, you will have to assign IndyTextEncoding_UTF8 to the AContext.Connection.IOHandler.DefStringEncoding property in the OnConnect event. Otherwise, Indy's default encoding will be used instead, and that encoding is US-ASCII by default (configurable via the IdGlobal.GIdDefaultTextEncoding variable). That is why you are seeing the client's non-ASCII characters being converted to ? characters. US-ASCII does not supports characters above #127.
I've downloaded Lockbox3 about a week ago and i can't use it, and i couldn't understand the demo because it's complex i couldn't get the codes i want from it, I'd like to use lockbox 3 AES-256 encryption to encrypt strings in Delphi.
The method and property names pretty much say it all. Here is a method which encrypts a string and then decrypts it back again, assuming you've setup the codec properties at design time, which are also self-describing.
procedure TForm1.actEncryptStringExecute( Sender: TObject );
var
Plaintext, sReconstructedPlaintext: string;
base64Ciphertext: ansistring;
begin
sPlainText := 'I love LockBox 3!';
if not InputQuery( 'Plaintext', 'Enter plaintext that you want to encrypt (UTF-16LE encoding):', sPlainText) then exit;
codec.EncryptString( sPlaintext, base64Ciphertext);
ShowMessageFmt('The base64 encoding of the encoded ciphertext is'#13#10+'%s',[base64Ciphertext]);
codec.DecryptString( sReconstructedPlaintext, base64Ciphertext);
ShowMessageFmt('After decryption, this decrypts back to %s',[sReconstructedPlaintext])
end;
Have another look at the demo program. The handler for Encrypt button, encrypts a file instead of a string. That aside, if you strip away the decorative fluff, like posting information to a memo, and handling exceptions if the user specified a non-existant file, its increddibly simple - it basically boils down to one line...
codecMainDemo.EncryptFile( edtPlaintextFile.Text, edtCiphertextFile.Text );
To encrypt a string, you call EncryptString(). To encrypt a file you call EncryptFile().
The demo shows the setup, to wit:
Put an TCryptographicLibrary component on your form;
Put a TCodec component on your form;
Select your prefered cipher
Select your prefered chaining mode; and
Set the password
and Bob's your uncle!
Let me know if you have any problems.
Sean
Your example has at least one error if not more:
var
Plaintext, sReconstructedPlaintext: string;
base64Ciphertext: ansistring;
Plaintext should be sPLaintext.
Plus Delphi Sydney compiler flags an error 'Not enough actual parameters' on codec.EncryptString( sPlaintext, base64Ciphertext);
I think that uncle bob was having an off day.
This is a great library but unfortunately it is let down by poor documentation. I have ploughed my way through the relevant units in order to make some progress but it is a shame that I have to do this in order to assess whether I want to use it - I am writing a textbook for the school's market.
I have the following declaration for DNSServiceRegister:
function DNSServiceRegister
(
var sdRef: TDNSServiceRef;
const flags: TDNSServiceFlags;
const interfaceIndex: uint32_t;
const name: PUTF8String; //* may be NULL */
const regType: PUTF8String;
const domain: PUTF8String; //* may be NULL */
const host: PUTF8String; //* may be NULL */
const port: uint16_t;
const txtLen: uint16_t;
const txtRecord: Pointer; //* may be NULL */
const callBack: TDNSServiceRegisterReply; //* may be NULL */
const context: Pointer //* may be NULL */
): TDNSServiceErrorType; stdcall; external DNSSD_DLL;
In my Bonjour framework I have the following response to an announced service being made active (i.e. to actually start announcing itself, via Bonjour):
procedure TAnnouncedService.Activate;
var
flags: Cardinal;
name: UTF8String;
svc: UTF8String;
pn: PUTF8String;
ps: PUTF8String;
begin
fPreAnnouncedServiceName := ServiceName;
inherited;
if AutoRename then
flags := 0
else
flags := kDNSServiceFlagsNoAutoRename; { - do not auto-rename }
if (ServiceName <> '') then
begin
name := ServiceName;
pn := PUTF8String(name);
end
else
pn := NIL;
svc := ServiceType;
ps := PUTF8String(svc);
CheckAPIResult(DNSServiceRegister(fHandle,
flags,
0 { interfaceID - register on all interfaces },
pn,
ps,
NIL { domain - register in all available },
NIL { hostname - use default },
ReverseBytes(Port),
0 { txtLen },
NIL { txtRecord },
DNSServiceRegisterReply,
self));
TBonjourEventHandler.Create(fHandle);
end;
This is more verbose than I think it strictly needs to be, certainly it was working perfectly well in Delphi 7 in a much less verbose form. I have expanded a lot of operations into explicit steps to facilitate debugging, e.g. to be able to identify any implicit transforms of string payloads that may be occuring "under the hood" in Delphi 2009.
Even in this untidy expanded form this code compiles and works perfectly well in Delphi 7, but if I compile and run with Delphi 2009 I get no announcement of my service.
For example, if I run this code as part of a Delphi 7 application to register a _daap._tcp service (an iTunes shared library) I see it pop-up in a running instance of iTunes. If I recompile the exact same application without modification in Delphi 2009 and run it, I do not see my service appearing in iTunes.
I get the same behaviour when monitoring with the dns-sd command line utility. That is, service code compiled with Delphi 7 behaves as I expect, compiled in Delphi 2009 - nothing.
I am not getting any errors from the Bonjour API - the DNSServiceRegisterReply callback is being called with an ErrorCode of 0 (zero), i.e. success, and if I supply a NIL name parameter with AutoRename specified in the flags then my service is allocated the correct default name. But still the service does not show up in iTunes.
I am at a loss as to what is going on.
As you might be able to tell from the expansion of the code, I have been chasing potential errors being introduced by the Unicode implementation in Delphi 2009, but this seems to be leading me nowhere.
The code was originally developed against version 1.0.3 of the Bonjour API/SDK. I've since updated to 1.0.6 in case that was somehow involved, without any success. afaict 1.0.6 merely added a new function for obtaining "properties", which currently supports only a "DaemonVersion" property for obtaining the Bonjour version - this is working perfectly.
NOTE: I'm aware that the code as it stands is not technically UTF8-safe in Delphi 7 - I have eliminated explicit conversions as far as possible so as to keep things as simple as possible for the automatic conversions that Delphi 2009 applies. My aim now is to get this working in Delphi 2009 then work backward from that solution to hopefully find a compatible approach for earlier versions of Delphi.
NOTE ALSO: I originally also had problems with browsing for advertised services, i.e. identifying an actual iTunes shared library on the network. Those issues were caused by the Unicode handling in Delphi 2009 and have been resolved. My Delphi 2009 code is just as capable of identifying an actual iTunes shared library and querying it's TXT records. It's only this service registration that isn't working.
I must be missing something stupid and obvious.
Does anyone have any ideas?!
UPDATE
Having returned to this problem I have now discovered the following:
If I have a pre-D2009 and a D2009+ IDE open (e.g D2006 and D2010) with the same project loaded into both IDE's concurrently:
Build and run under 2006: It works - my service announcement is picked up by iTunes
Switch to D2010 and run (without building): It does a minimal compile, runs and works.
Do a full build in D2010: It stops working
Switch back to D2006 and run (without building): It doesn't work
Do a full build in D2006: It works again
Does this give anyone any other ideas?
The answer to this is mind boggling. On the one hand I made a completely stupid, very simple mistake, but on the other hand it should never - as far as I can see - have worked in ANY version of Delphi!
The problem was nothing what-so-ever to do with the Unicode/non-unicodeness of any strings, but was actually due to a type mismatch in the PORT parameter.
I was passing in the result of ReverseBytes(Port) - that parameter expected a uint16_t, i.e. a Word value. My Port property was however declared (lazily) as an Integer!!
Once I fixed this and had Port declared as a Word, it now works on both D2007- and D2009+ versions of Delphi.
Very weird.
I can only think that some other edge-case behaviour of the compiler that might have somehow affected this was changed when Unicode support was introduced.
Based on the information that we have available here, the situation is this:
When calling the DLL with your code in Delphi 2007, it gives one result.
When calling the same DLL with your code in Delphi 2009, it gives another result.
The suspicion is, that it is related to the Delphi 2009 compiler.
Logically, the difference must therefore be, that Delphi 2009 sends different values as parameters. In order to make the debugging truly Delphi-independent, you therefore need to create a dummy DLL, which reports the values it gets. Other Delphi-dependent methods may be applied, like looking at the disassembly of the function-call into the DLL, and debugging it so that we know exactly what values are passed, and how, to the DLL, in both compilers.
I can't find the declaration instruction for the vars "ServiceName" and "ServiceType" in your code sample.
Assuming a String type (thus a unicode string), I guess (yes... no D2009 available to test this) lazy typecasting could be an issue:
name := ServiceName;
Why not use the following?
name := PAnsiChar(AnsiString(ServiceName))
Anyhow... just my 2 cts.
BTW:
I always use the pre defined "EmptyStr", "EmptyWideStr" ... so the test would look like:
if (ServiceName <> EmptyStr) then
which should be safe and avoid the confusion of types.
On the other side, Delphi may interpret the '' as an ANSIChar like the following declaration do:
const
MyParagraphChar = '§';
Not sure... I'm confused - should go home now ;)
If the DLL is not written using Delphi 2009, you may want to use something else than PUTF8String. The Delphi 2009 Utf8String type is different from Delphi 2007's UTF8String type.
If the DLL was written using C/C++, I strongly suggest to use PAnsiChar() instead of PUtf8String.