No, I disagree that a version information makes a file unsuspicious. We build the files 1:1 using the OpenSSL make process, any change to that process will actually make the files “suspicious”, even if those changes are just related to version info.

OpenSSL provides version information through it’s API, that’s the way to go, especially when talking about our experimental FIPS versions.

Cheers,
Arvid

I’ll reply to your question in the Embarcadero Forums at https://forums.codegear.com/thread.jspa?threadID=34251 shortly.

Regards,
Arvid

I have a problem with OpenSSL v0.9.8m for Indy (I use 10.5.5). My code works fine with Indy 9.X and OpenSSL v0.9.7, but now I use Delphi 2010 with Indy 10.5.5 and OpenSSL v0.9.8m and there is access violation. Any suggestions?

uses IdSSL, IdSSLOpenSSL, IdSSLOpenSSLHeaders
…
function RSA_new:pRSA; cdecl; external ‘libeay32.dll’;//this function was not described in IdSSLOpenSSLHeaders.pas
function BN_bin2bn(const _from: pointer; len: integer; ret: pBIGNUM): pBIGNUM; cdecl; external ‘libeay32.dll’;//this function was not described in IdSSLOpenSSLHeaders.pas
…

procedure TForm1.Button1Click(Sender: TObject);
var
publicKey, Signature, ResultArray : array[1..256] of AnsiChar;
publicKeyExponent : array [1 .. 3] of ansichar;
resultValue, keyLen, exponentLen : Integer;
CryptLibHandle : Cardinal;
rsaMethods : IdSSLOpenSSLHeaders.RSA_METHOD;
rsaBody : IdSSLOpenSSLHeaders.pRSA;
begin

//…
//publicKey, Signature, publicKeyExponent are assigned, also keyLen and exponentLen gets his value
//…

if not IdSSLOpenSSL.LoadOpenSSLLibrary then begin
MessageDlg(‘Unable to load SSL library’,mtInformation,[mbOK],0);
exit;
end;

rsaBody := RSA_new;

CryptLibHandle := IdSSLOpenSSLHeaders.GetCryptLibHandle;
rsaMethods.rsa_pub_dec := GetProcAddress(CryptLibHandle, PChar(‘RSA_public_decrypt’));//this method was not initilaized in LoadOpenSSLLibrary

if @rsaMethods.rsa_pub_dec = nil then begin
MessageDlg(‘Unable to load function rsa_pub_dec’,mtInformation,[mbOK],0);
exit;
end;

rsaBody.n := BN_bin2bn(@publicKey, keyLen, rsaBody.n);
rsaBody.e := BN_bin2bn(@publicKeyExponent, exponentLen, rsaBody.e);

resultValue := rsaMethods.rsa_pub_dec(keyLen,@Signature,@ResultArray,rsaBody,OPENSSL_RSA_NO_PADDING);//access violation at address 61D9484F in module libeay32.dll
end;

Nice solution, despite I think we will get troubles with our internal test regarding the FIPS versions of OpenSSL when we adjust the build process.

I would suggest you open a ticket at the RT of the OpenSSL team for a feature request about. I will of course support this approach!

Regarding C++ Builder I am still looking forward for David Dean’s tests: http://blogs.embarcadero.com/ddean/2009/11/11/34858

He says he has this on his list.

Cheers,
Arvid

Yes, I checked using Dependency Walker.
Here’s what I did using Microsoft Visual C++ 2008 SP1:

1. perl Configure VC-WIN32 –prefix=c:/temp
2. notepad.exe ms\ntdll.mak // replace “/MD” with “/MT”
3. ms\do_masm
4. nmake -f ms\ntdll.mak
5. nmake -f ms\ntdll.mak test
6. editbin.exe /rebase:base=0×11000000 libeay32.dll
7. editbin.exe /rebase:base=0×12000000 ssleay32.dll

IMHO, building with Embarcadero C++ 2010 and being able to static link into a Delphi or Embarcadero C++ EXE would be super. I hate using DLLs for crypto since calls are so easy to intercept (no programming skills needed.)

yes the lack of C++ Builder support is one of the reasons to use gcc. The DLLs you created are usable with any newer Indy version too, there are no more adjustments needed. We are “just” publishing them in order to provide something like an out-of-the-box experience when using Indy and SSL/TLS (without the need for MS VC Runtime DLLs as you already mentioned and most precompiled OpenSSL libraries available need).

The drawback of using gcc is a slightly larger size of the resulting files.

One thing regarding your experience: Are you sure there are no dependencies? I mean did you check it with Dependency Walker or something like that? If so, I will need to check that again, regarding Win32 we might move to that build environment after doing some tests.

Cheers,
Arvid

My findings were surprising.

I was unable to build OpenSSL 0.98m using Embarcadero C++ 2010.

I tried building OpenSSL 0.98m with Microsoft Visual C++ 2008 using the instructions in INSTALL.W32. But the default settings require deploying MSVC runtime DLL.

I changed “/MD” to “/MT” in ms/ntdll.mak and resulting DLL’s don’t require any more runtime DLL’s than MinGW.

No MSVC++ runtime DLL’s needed and OpenSSL binaries are smaller compared to ones compiled by MinGW! If I had time, I’d do benchmarks.

So far, it is working great with Delphi 2010 apps using Synapse. I haven’t done multithreaded stress tests, yet.

Embarcadero needs to work with the OpenSSL team, because Borland C++ 5.0 is the latest version mentioned by OpenSSL. That is embarrassing as not being able to compile.