turbopack / lockbox Goto Github PK

Running the GetIt package installer for RadStudio the LockBox package was not compiled for C++ Builder (Missing all the hpp files).
Also the paths in the Tools - Options - C++ - Paths and Directories - System Include Path contained $(BDSCatalogRepository)\LockBox-2.4\source\hpp\Win32\Debug but when I opened and recompiled the packages the hpp files were placed in the source folder so the path needed to be changed to $(BDSCatalogRepository)\LockBox-2.4\source\

Using GetIt package manager trying to install LockBox 3.7 on Delphi 10.4. there are errors.
I click install.
I click Agree All.
it downloads.
It extracts.
It begins to compile
It then asks me for profiles for Linux and OSX. I do not use either of those environments currently. I try to cancel out of that portion.

The install fails.

I need to get this installed for a project I am working on. Please get this working without profiles!

Hi, how would you convert this code which doesn't compile anymore with the latest version of TpLockBox (DESEncryptStringEx was in the LbString unit):

function CipherString(const AString: string; APassPhrase: string): string;
var
  Key64: TKey64;
begin
  LbCipher.GenerateLMDKey(Key64, sizeof(Key64), APassPhrase);
  Result := DESEncryptStringEx(AString, Key64, True);
end;

Thanks !

Downloaded and compiled and installed the latest source from here. (Tried GetIt with problems, so came here directly). I am able to install the packages and create a project with TLbDES or TLb3DES components on them. I am able to run on 32 bit Release and Debug modes no problem.
When I switch to 64 bit and try to run - it compiles fine, but immediately throws an "Access violation at address 0..08B77DF in module 'rtl280.bpl'. Read of address 0..200. Same error in Debug or Release mode.
I have run it with RadStudio 11.1 and RadStudio 11.1 with Update 1 - same problem in both.
Any ideas or what I can try now?

Hi,

in old(er) versions there were couple of string methods available, like GenerateKeyW and EncryptStringW.
In newer versions we have option to use the same by setting Encoding property. But, it is broken for UNICODE, because stream that contains Base64 bytes is returning pure ANSI bytes and the TlbDES (example I am using) is doing GetString() on the result which expects the result to be encoded in the way Encoding was set.

Consider this, using old versions (please excuse missing try..finally, it is just an example)

DES := TLbDES.Create(nil);
DES.GenerateKey**W**('TEST');
Result := DES.EncryptString**W**('TEST_STRING');

Result is 8NxSs3eF6IqVqpOtwPGlYrNY1Nu30bt9.

Move on to the new versions we have this:

DES := TLbDES.Create(nil);
DES.Encoding := TEncoding.UNICODE;
DES.GenerateKey('TEST');
Result := DES.EncryptString('TEST_STRING');

And the Result is jibberish - 丸卸㍳䙥䤶噱灱瑏偷汇牙奎丱㍵戰㥴.
This clearly looks like encoding error so looking at the stuff happening in background, result from DESEncryptBytesEx() has correct bytes internally, only not in the UNICODE format the GetString() in TLbDES.EncryptString expects them to be in. So the GetString is returning garbage.

Fix is not too hard to do but I imagine your implementation would differ from mine since you know the whole library better than I do currently :)

Hi,

I found an issue with the EncodeString and DecodeString methods in LbRijndael, but it is an issues in other cypher classes as well.
I think the EncodeString should return an AnsiString and the DecodeString should have an AnsiString as in parameter. More precisely it is an error i think that the EncodeString uses the internal GetString method that relies on the encoding of the given string to encrypt. but the generated encrypted data should always be interpreted ans ANSI and not use the encrypted data encoding. This behaviour is what we had in the previous 2.08 version of LockBox that still made a distinction between unicode and none unicode methods.
I suggest changing this behaviour by adding a protected GetBytesString method that is used to return keys and cyphers as string instead of the now used GetString method.
But this will change the existing behaviour of the LockBox components.

regards,
Steve

Previously I was using SeanBDurkin/tplockbox 3.6.3.0. I installed the Delphi 10 Seattle LockBox 3.5.0 package from IDE GetIt and I cannot get my previous crypted files to be decrypted with TCodec.DecryptStream. Are the two versions compatibles ? Here is my components configuration :

object Codec1: TCodec
AsymetricKeySizeInBits = 1024
AdvancedOptions2 = []
CryptoLibrary = CryptographicLibrary1
Left = 616
Top = 24
StreamCipherId = 'native.StreamToBlock'
BlockCipherId = 'native.3DES.1'
ChainId = 'native.CBC'
end
object CryptographicLibrary1: TCryptographicLibrary
Left = 624
Top = 88
end

Thanks

In TMD5.GenerateMD5Key the Key is never returned.

Changed was to add Key := TKey128(D)
class procedure TMD5.GenerateMD5Key(var Key : TKey128; const ABytes: TBytes);
var
D: TMD5Digest;
begin
HashMD5(D, ABytes[0], Length(ABytes));
Key := TKey128(D);
end;

TurboPack LockBox3 v3.5.0 (Delphi 10 Seattle GetIt package).

The following error is raised by FastMM4 in full debug mode when doing a Base64 decryption:
'FastMM has detected an error during a ReallocMem operation. The block footer has been corrupted...'

The bug appears to be an 'off-by-one' indexing problem in the TBase64Conv.Decrypt method. The local variable 'base64_Fragment' was changed from an ANSIString to a TBytes type at some stage and the in-buffer read pointer index was not adjusted. Line 250 in 'uTPLb_Base64.pas' should be:

FInBuffer.Read( base64_Fragment[0], FromBase64_BufferSize);

FYI, I have attached the full memory manager event log.
MemoryManager_EventLog.txt

HTH.
Steve

Using the RSA encryption / decryption I got a range check error in TLbBase64.LbDecodeBase64.
I added {$I LockBox.inc} to LbBytes.pas to avoid this.

Hi,

I am trying to use the RSA module to do some signature verification, and I found that the byte order of TLbBigInt to be kind of funny.

If I do this to load pubkey.der which was generated using OpenSSL,

pubKey := TLbRSAKey.Create(aks1024);
pubKey.LoadFromFile('pubkey.der');

then the modular exponentiation seems to be wrong. Somehow I had to reverse the byte order of the modulus to make it working.

However, even if the modular exponentiation works, the signature verification cannot succeed, because at line 688 of LbRSA.pas, the byte orders of SHA1Digest1 and SHA1Digest2 are reverse of each other (I checked the Local Variables by using adding a breakpoint there), and thus Result will be False.

Any thoughts on this?

Please, make installation compatible with Delphi 7, need some adjusts, like TBytes doesnt is available on D7.
And will be so cool if support last Delphi Tokyo to linux.

Can not build with iOS 64bit as target!

All lbxxxStream object is not compiling to iOS 64 bit !

on lbxxxStream object the read and write functions are defined with integer, but in TMemoryStream
they are LongInt

function Read(var Buffer; Count : Integer) : Integer; override;
function Write(const Buffer; Count : Integer) : Integer; override;

Longint and Integer is not the same on iOS 64 bit!!

Is there an XE6 version available?

After update components via GetIt package list "Installed components" is empty:

Hi ;
I have installed the Lockbox 2.4 in Delphi 10.3 Rio ! But I found that new version lockbox 2.4 doesn't have LBString file. We use that file for our custom components. We are getting error LBSting and TripleDESEncryptStringEx undeclared identifier errors.

is there any same function in new lockbox 2.4 ? or any way we can add that file in to Lockbox 2.4 ?

Please let me know !

Urvesh