xsharp.eu

In https://www.xsharp.eu/forum/private-pro ... -continued I wrote that I had strange issues with our mailreader once we removed the Vulcan DLL's and replaced them with X# DLL's.

It seems that the pop3 access fails because of the Crypt function giving a different result. We use:

cValue := Crypt(cValue, "OurCryptPassword")
This decrypts fine with Bandol RC 2 but not anymore after we replaced the Vulcan DLL's with the X# DLL's .

Could it be that Crypt is in one of the X# DLL's working differently than the Crypt in the Vulcan DLL?

If you need additional info please let me know.

Dick

PS: I could have posted this as a ticket on GitHub but this requires an account. I don't want to open an account on Microsoft's GitHub.

You may need:

SetAnsi(FALSE)

Jamal

Hi Dick,

Yeas, the implementation of Crypt() in vulcan was very problematic, when the (unicode) string to be crypted had non English characters in it, then issuing a Crypt() and another Crypt() on the first result, was not returning the original string! This does work properly in X# now.

But still, it is not possible to have it completely compatible with VO, which uses 8 bit strings only, and depending on how you use the function, you may need to adjust your code. So how are you using Crypt() and how/where are you storing its results?

Btw, don't worry about github tickets, making your reports here is fine as well.

Hello Chris,

Basically we have many installation with a txt files with settings in it - some of them encrypted with the Crypt function, running it with a password like in the line I posted below (something like cValue := Crypt(cValue, "OurCryptPassword") - in 'realaity' it is also a normal password with regular ASCII code, not even accented characters).

If we would start replacing our code with X# based code and the Crypt does not properly decrypt all these stored passwords and other crypted information it would mean that we can't replace our Vulcan based X# for program with the X# based program.

Reason: we can't tell which passwords have been assigned by users. If a new version stops reading passwords correctly they simply can't login. We would need to start a massive password reset operation to assign and later read passwords. It would also mean that we can't do a test with an older version of our program which we sometimes do, as this will most likely read the new "X#" password incorrectly.

Could it be a solution to use the VO/Vulcan compatible Crypt function as a source? I don't see a problem in replacing Crypt with e.g. CryptVO as long as it keeps working the same.

Dick

An alternate solution would be to convert your Vulcan crypt function stored values to .NET AES or DES encryption functions then use the same functions in X#.

Jamal

Hello Jamal,

An alternate solution would be to convert your Vulcan crypt function stored values to .NET AES or DES encryption functions then use the same functions in X#.

That is not an alternative. We do not want to change stored values. If we can't keep on reading the passwords like we do now with the Vulcan DLL's it would mean that we can not update to (the full) future X# versions and keep working with the Vulcan DLL's.

I checked the 01 System Library SDK but there is no source version of Crypt in that AEF. I think/hope that is the easiest solution.

Dick

Hi Dick,

Yes, I can give you a version of Crypt() that works exactly as the vulcan version, it is very easy, will just need to remove the extra functionality of the X# version which makes it work correctly . Will send it in a moment, you can use it as a replacement of the standard X# version.

Edit: Hmm, no, actually there's also a bug in the X# version, it does return different results than VO. Looking into it...

Chris wrote:Hi Dick,

Edit: Hmm, no, actually there's also a bug in the X# version, it does return different results than VO. Looking into it...

Hello Chris,

Thanks for the update. Leave it to me to find bugs

Just let me know if I can probaly still get it working after you solved the bug, or if I better replace the default Crypt function. Either way will do for me but the first option I guess is preferable.

Dick

ic2 wrote:

Chris wrote:Hi Dick,

Edit: Hmm, no, actually there's also a bug in the X# version, it does return different results than VO. Looking into it...

Hello Chris,

Thanks for the update. Leave it to me to find bugs

I'm also that kind of person, too

ic2 wrote: Just let me know if I can probaly still get it working after you solved the bug, or if I better replace the default Crypt function. Either way will do for me but the first option I guess is preferable.

The thing is there is no way in .Net to make Crypt() work completely correctly, because Crypt() assumes 8 bit strings, while strings in .Net are unicode (unless you use PSZs, which would work fine). Because of that, it is not possible to make it truly compatible to VO and at the same make it work correctly for international characters in crypted strings.

We can only do one of the two, so there will always be a "bug" in Crypt(). Currently the X# version handles international characters well, but is not binary compatible with VO. Vulcan is binary compatible with VO, but "destroys" strings with international characters, this is why you get a different behavior now.

So I take it back, it's not actually a bug in X#, just a different behavior. Since there is no correct behavior possible, I will send you a version that works in the same way as the vulcan version for your specific needs. maybe we should include both versions in the X# runtime actually...

Hi Chris, hi Dick,

why don't add two different functions: Crypt() that is compatible with VO and destroys foregn characters, and CryptEx() with the new, correct and incompatible behaviour.
So after a migration from VO (where Unicode does not exists) unchanged code works in compatibility mode, and for use with CryptEx() code needs to be checked. And add a big red warning to the documentation.
Wolfgang