AES-128-CBC - replicate openssl result

[infratec]

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

[NicTheQuick]

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.

[Olli]

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 :

Code: Select all

MD5$ = StringFingerprint(pwd$, #PB_Cipher_MD5, 0, #PB_Ascii)

[NicTheQuick]

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

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

[Olli]

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.

Code: Select all

UseMD5Fingerprint()
Debug StringFingerprint("A", #PB_Cipher_MD5, 0, #PB_Ascii)
Debug StringFingerprint("A", #PB_Cipher_MD5, 0, #PB_Unicode)

results :

Code: Select all

7fc5627...
8214d1003...

[infratec]

@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.

[Olli]

@infratec

Could you test this below ?

Code: Select all

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

Result (Windows) :

Code: Select all

abc123

[Olli]

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...

[infratec]

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.

[firace]

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.

[Olli]

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 :

Code: Select all

"abc123"

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 :

Code: Select all

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

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 ?).

[NicTheQuick]

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.

[Piero]

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

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

[Fred]

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

[Piero]

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

That's vague and cryptic