Where is Delphi crypto suite? Open letter to Embarcadero
Delphi really needs cross platform crypto library as crypto is now everywhere. Seems Embarcadero has decided to fill the void by partly adopting ancient TurboPower LockBox suite. But they are not adopting it completely but just keeping someone else to maintain it so they don't need to waste their own resources on it. On paper there is now crypto library for Delphi but in reality there is no stability like when the library could be officially maintained and updated by Embarcadero.
I'm listing some of the issues with LockBox 3.5 here. It is interesting to note that I'm not an expert programmer myself and if someone like me finds this kind of issues then how this software has been existed and used for so long, likely used in thousands of applications that require real security?
1) The first thing is that there is basically no documentation about LockBox. Is it really only used by some oldtimers who bought LockBox 1.0 some 25 years ago from TurboPower and got some documentation?
2) The real issue is that if you look at the code in most current version LockBox 3.5, you'll start scratching head and asking ****!?. *There are plain text leaks all over the place and seems the practice to burn any sensitive data after use was completely unknown to developers*.
Few examples:
{code}
procedure TLbRijndael.GenerateKey(const Passphrase: string);
begin
TLMD.GenerateLMDKey(FKey, FKeySizeBytes, GetBytes(Passphrase));
end;
{code}
Above we see typical example how easy is to leak your plain text password to memory and that eventually ends up in memory dump or swap file. Note temporary plain text password bytes returned by GetBytes function are never burned. Same happens when you call any LockBox hash function on string and in numerous other places.
But if you want to be completely sure that someone must find your plain text then you can call EncryptString:
{code}
function TLbRijndael.EncryptString(const InString: string): string;
begin
case CipherMode of
cmECB : Result := GetString(TRDLBytes.RDLEncryptBytesEx(GetBytes(InString), FKey, FKeySizeBytes, True));
cmCBC : Result := GetString(TRDLBytes.RDLEncryptBytesCBCEx(GetBytes(InString), FKey, FKeySizeBytes, True));
end;
end;
{code}
Again notice GetBytes which leak plain text. But RDLEncryptBytesEx that is internally used by above function creates several temp streams that are never burned.
{code}
class function TRDLBytes.RDLEncryptBytesEx(const InBytes: TBytes; const Key; KeySize: Integer; Encrypt: Boolean): TBytes;
var
InStream : TMemoryStream;
OutStream : TMemoryStream;
WorkStream : TMemoryStream;
begin
InStream := TMemoryStream.Create;
OutStream := TMemoryStream.Create;
WorkStream := TMemoryStream.Create;
InStream.Write(InBytes[0], Length(InBytes));
InStream.Position := 0;
if Encrypt then begin
RDLEncryptStream(InStream, WorkStream, Key, KeySize, True);
WorkStream.Position := 0;
TLbBase64.LbEncodeBase64(WorkStream, OutStream);
end else begin
TLbBase64.LbDecodeBase64(InStream, WorkStream);
WorkStream.Position := 0;
RDLEncryptStream(WorkStream, OutStream, Key, KeySize, False);
end;
OutStream.Position := 0;
SetLength(Result, OutStream.Size);
OutStream.Read(Result[0], OutStream.Size);
InStream.Free;
OutStream.Free;
WorkStream.Free;
end;
{code}
That code is painful to look at. What about efficiency? Error handling? Security? It seems we get bonus BASE64 encoding as well (functions that operate with TBytes type actually are only meant for string encrytoption, it seems).
3) *Error handling in LockBox is non-existent, sensitive information is not burned on exception and usually also not burned after use.*
4) *Design of the suite is overly complex.*
5) On some reason copy of crypto cipher keys are kept in memory as property of class (and also not automatically burned on destroy), while best practice is burn key after initializing cipher with key and IV.
It is painful exterience to look at this widely used crypto library with these issues. Yes, it is possible to write more secure code with LockBox by avoiding some high-level functions. But how is it possible this situation has been existing for so long time and no one pointing out? That tells us another thing open source code is not always better because it is open, although many like to think that way. People just assume in good faith it is all good, it must be good.
My suggestion for Embarcadero is to include a crypto library with Delphi VCL. Users need stability and crypto is one area which especially requires stability. I don't want to worry from where I get crypto and if I do, does it really work? Does it work with the next Delphi release?
My recommendation is to *adopt DCPcrypt and drop LockBox*. DCPcrypt has very nice, sensible and clean architecture, and is not as complex. http://www.cityinthesky.co.uk/opensource/dcpcrypt/
0 
Ahto
7/24/2015 12:08:11 PM
I agree with you LockBox quality is not enough for any sensible application requiring true security. > My recommendation is to *adopt DCPcrypt and drop LockBox*. DCPcrypt has very nice, sensible and clean architecture, and is not as complex. http://www.cityinthesky.co.uk/opensource/dcpcrypt/ No. My recommendation is wrap Windows CryptoAPI (CNG, not the old one) under Windows, and wrap OpenSSL - or whatever can be a good replacement - on other platforms (don't use OpenSSL under Windows because you need to update it yourself...). If the wrap is well done, it could be cross-platform. This way application will always use the updated crypto libraries the platform offers and maintains, without any need for Embarcadero to have to maintain the libraries itself, or wait for some volunteer to update them. Edited by: Luigi Sandon on Jul 24, 2015 6:35 PM
0
Luigi
7/24/2015 4:35:57 PM
I agree with you LockBox quality is not enough for any sensible application requiring true security. I've pointing out lack of proper security features for a long time, but no one listen to me... > My recommendation is to *adopt DCPcrypt and drop LockBox*. DCPcrypt has very nice, sensible and clean architecture, and is not as complex. http://www.cityinthesky.co.uk/opensource/dcpcrypt/ No. My recommendation is wrap Windows CryptoAPI (CNG, not the old one) under Windows, and wrap OpenSSL - or whatever can be a good replacement - on other platforms (don't use OpenSSL under Windows because you need to update it yourself...). If the wrap is well done, it could be cross-platform. This way application will always use the updated crypto libraries the platform offers and maintains, without any need for Embarcadero to have to maintain the libraries itself, or wait for some volunteer to update them.
0
Luigi
7/24/2015 4:37:32 PM
I agree with you LockBox quality is not enough for any sensible application requiring true security. I've pointing out lack of proper security features for a long time, but no one listens to me...Probably the average Delphi developer doesn't really care about security. > My recommendation is to *adopt DCPcrypt and drop LockBox*. DCPcrypt has very nice, sensible and clean architecture, and is not as complex. http://www.cityinthesky.co.uk/opensource/dcpcrypt/ No. My recommendation is wrap Windows CryptoAPI (CNG, not the old one) under Windows, and wrap OpenSSL - or whatever can be a good replacement - on other platforms (don't use OpenSSL under Windows because you need to update it yourself...). If the wrap is well done, it could be cross-platform. This way application will always use the updated crypto libraries the platform offers and maintains, without any need for Embarcadero to have to maintain the libraries itself, or wait for some volunteers to update them as often as required.
0
Luigi
7/24/2015 4:40:55 PM
Luigi Sandon wrote: > I agree with you LockBox quality is not enough for any sensible > application requiring true security. > > > My recommendation is to *adopt DCPcrypt and drop LockBox*. DCPcrypt > > has very nice, sensible and clean architecture, and is not as > > complex. http://www.cityinthesky.co.uk/opensource/dcpcrypt/ > > No. My recommendation is wrap Windows CryptoAPI (CNG, not the old > one) under Windows, and wrap OpenSSL - or whatever can be a good > replacement - on other platforms (don't use OpenSSL under Windows > because you need to update it yourself...). If the wrap is well done, > it could be cross-platform. > > This way application will always use the updated crypto libraries the > platform offers and maintains, without any need for Embarcadero to > have to maintain the libraries itself, or wait for some volunteer to > update them. > > Edited by: Luigi Sandon on Jul 24, 2015 6:35 PM Whatever goes under the hood, they need a library that will keep up with practices and methods. The ability to sign XML (needing C14N and friends) are common needs. Most/all of that stuff is available in OpenSSL but dandy/standardized wrappers for Delphi would be most useful. That said, I'm holding at XE2 right now and maybe it is magically in later versions already. Dan
0
Dan
7/24/2015 5:05:45 PM
Emb will tell you that is "impossible, really impossible, no one does it, exporting encryption algorithms!" - then they sell you the new encryption capabilities of Interbase.... That's why wrapping CNG - for which MS already took care of the paperwork for exporting - or OpenSSL and whatever OSX uses - which again are already available - makes sense so Embarcadero doesn't need to spend your subscription money to hire someone to fill the forms for exporting commercial cryptography.
0
Luigi
7/24/2015 6:47:06 PM
Reply:
(Thread closed)
(Thread closed)
