PureBasic Forums - English

The problem is not mine, I only want to replicate the openssl behaviour.

WIth MD5 I get the result like firace, but not the result on my debian 12

infratec wrote: Thu Jun 19, 2025 5:02 pm The problem is not mine, I only want to replicate the openssl behaviour.

WIth MD5 I get the result like firace, but not the result on my debian 12

I would guess that the defaults will highly depend on the OpenSSL version.

NicTheQuick wrote:I would guess that the defaults will highly depend on the OpenSSL version.

I do not think so my friends, even if I have no evidence about my objection.

Let's see the versions of PureBasic and characteristics of a character, depending of this version :
- old versions : "A" has one-byte size
- new versions : "A" has two-byte size

If we hash a simple "A" string through MD5, I do not think we get the same result between a 1-byte character and a 2-bytes character.
0x21h should not have the same MD5 signature as 0x0021h.

If I am also not wrong, "abc123" should be converted from unicode to ascii before being used by the PureBasic MD5 function.
Doc source - see the optional format argument

Then, this line should do the affair :

I am not talking about Purebasic but about OpenSSL. I guess its defaults are different on Debian 12 when used via CLI.

But I just tested it on Debian 12, Ubuntu 24.04 and Rocky 8.10. There's not difference.

Or maybe I just misunderstood this

infratec wrote: Thu Jun 19, 2025 5:02 pmWIth MD5 I get the result like firace, but not the result on my debian 12

Maybe the 2 : the CLI of debian 12 as the pb ide coding type.

Anyway the MD5 signature of a 'A' character could be a good mean to check which coding type is used on a screen.
results :

@Olli

Idf ou read the code, than you will see that always UTF8 is used.
So it is no problem of the internal representation of a character.

the original Base64 result from firace based on a key generation with MD5 from the password.
All other openssl base64 results using an other generation of the key.
That's the problem and nothing else.

@infratec

Could you test this below ?Result (Windows) :

infratec wrote:That's the problem and nothing else.

I think an other problem however occurs when a coder like me, does not go forward step by step, small evidence by small evidence : if the steps are too large : headaches !

At the same time, other coders prefer go forward big step by big step, else they get then a headaches also !

So I think with all these steps written here, the problem will be solved...

Olli wrote: Fri Jun 20, 2025 7:59 pm

Code: Select all

Debug PeekS(@"abc123", -1, #PB_Unicode)

Result (Windows) :

Code: Select all

abc123

Since a long time PB uses unicode only to store internal strings.
So your example will always show abc123 as result.

Many thanks everyone for the nice ideas and especially infratec for your great solution!
Thanks to the community there is always something to learn here.

infratec wrote: Sat Jun 21, 2025 8:49 am

Olli wrote: Fri Jun 20, 2025 7:59 pm

Code: Select all

Debug PeekS(@"abc123", -1, #PB_Unicode)

Result (Windows) :

Code: Select all

abc123

Since a long time PB uses unicode only to store internal strings.
So your example will always show abc123 as result.

You are exactly right my friend : in 2015 (near version 5.40 pureBasic).

But, simultaneously (or maybe not), we were provided by a complete converting string instructions set. What it allowed us to hold perfectly the breakthrough.

In PureBasic, the compiler consider a string is unicode.

So : is (by default)" unicoded ".
You advice to me to observe UTF8 in "the" code.
But... In which code ? The source code openssl ? (actually stored in github)

If yes, this means "abc123" [UTF8] has not the same GUID as "abc123" [unicode]. (here "GUID" is the global numeric code of the string, whatever the string, considered between its first character included, and its last character included.

Note that a unicode character endianness is in the big endian mode. This mean 'A' is stored as 0x8100h. But, with all native PureBasic statements, this is a detail. To convert a string from a pureBasic source code (by default unicode ) to a UTF8 system, we can use the same code just above, with a light difference : And normally, the result is not "abc123", but a shorter overloaded and ununderstandable string.

This should be a good way. But, if I had to understand to the domain, I suggest to be insured the code pages are the right ones.

Because :

1) ASCII had its own code pages
2) UTF8 had its own code pages
3) Unicode has its own code pages

Fred chose a standard unicode code page. And I suppose the author of openssl has also choosen a specific code page, linked to the hardward and software of the environment coding.

My suggest : never use a string in cryptography, even not for a password.
a)Because what it is a force in UNICODE and ASCII, is a fail in UTF8.
b)What it is a force in ASCII and UTF8, is a fail in UNICODE.
c)What it is a force in UTF8 and UNICODE is a not a fail in ASCII : it is all simply unabled in ASCII...

Prefer a variable sized GUID and a good set of symbols (a code page) to be clicked or tapped, else you will be in the mercy of a fail, early or late...

I started to code in ASCII. It is not open to the world. But I do not better way. I can absolutely be wrong, but if it existed a better way as a ASCII non zero terminal string (which uses 100% of the numeric domain, not 0.01% as UNICODE) as a readable key, the COBOL would be six feet under the ground...


So PokeS() converts from standard Unicode "abc123" string to a "utf8" buffer.
Then FingerPrint() should provide a md5 signature.
It stays a standard I have not read in github : which character is used to store the useless terminal characters (0 or 32 ?).

UTF8 is downwards compatible to ASCII. Also UTF-8 does not have code pages. UTF-8 can represent all the characters in existence and it is the defacto standard. So if you want to be compatible to most modern libraries, just use UTF-8. Unfortunately Purebasics Unicode characters can only represent a subset of UTF-8.

Just guessing: maybe it has something to do with this (PB UTF16le)

PS: why "try to replicate with nosalt" instead of "compare decoding"?

PB use UCS-2 with some support for surrogates (not everywhere).

Fred wrote: Thu Jun 26, 2025 9:35 am PB use UCS-2 with some support for surrogates (not everywhere).

That's vague and cryptic