ICS SSL under Linux x64

[Angus Robertson 558]

In this function. ICS does not use PAnsiChar as a null terminated string, it passes the actual TBytes length to the OpenSSL API, since the hash or digest is binary data.

 

It would seem the old digest is being corrupted before verification. 

 

Angus

 

[ap2021 0]

Irrespective of that, even if all the right data is sent to OpenSSL's EVP_DigestVerify  function, unlike Windows, in Linux it fails - returns 0 and those messages...

 

[Angus Robertson 558]

So you are saying you've saved a TBytes digest created by IcsAsymSignDigestTB and used it with IcsAsymVerifyDigestTB without any string, encoding or base64 conversions, and it fails?

 

Specifically,as in the function doTestSignClick in the JoseTst sample which displays the digest in hex and base64?  

 

I will convert that sample to FMX, as I said earlier, but it is not a priority.

 

Angus

 

[Angus Robertson 558]

One other thing you could check before verify is the length of the digest.  It varies depending on your private key type and signing hash, but is generally the length of the key, so

an RSA 2048 SHA256 digest will be 256 bytes long, binary.  The JoseTst sample reports the hash length for all combinations of keys and hashes.

 

This could be a simple check for the digest not being corrupted at some point.  I might do some investigation to see if I can reliably add such a check to verify. 

 

Angus

 

 

[ap2021 0]

On 10/4/2024 at 11:38 PM, Angus Robertson said:

So you are saying you've saved a TBytes digest created by IcsAsymSignDigestTB and used it with IcsAsymVerifyDigestTB without any string, encoding or base64 conversions, and it fails?

Yes, pretty much. Except that I was not creating this JWT, it's someone else's. It does validate using the same code under Windows. - "used it with IcsAsymVerifyDigestTB without any string, encoding or base64 conversions" And yes, it's 256 bytes long, binary digest I'm passing in.

 

So far I triple-checked the OpenSSL function definition, data types/sizes, etc. Binary stream is the same under Windows, BTW, so I know it comes through exactly the same here.

 

I'm trying to build the latest SSL now, to see if that was just a 3.0 bug...

[ap2021 0]

And typically Linux: OpenSSL 3.3.2 breaks yum and has a new dependency on libcurl (which I cannot install because of yum issue)...