Crypt function gives different results with X# DLL's replacing Vulcan DLL's

[ic2]

Hello Chris, Wolfgang,

I think either 2 versions or a extra parameter (normally not a good idea but does X# support overloads? Then a Crypt(<cSource>, <cKey>,lUseVOCrypt) ---> cCryptedString would do perfectly).

But I am sure I am not the only when who used Crypt and has to rely on unchanged decoding when a (new) X# version is used. Maybe the default behavior should even use the VO Crypt protocol even though that's clearly inferior to the X# protocol?

Dick

[Chris]

Wolfgang, yeah, that's what I meant at the end of my post. Dick, unfortunately there's no "VO protocol" that we can follow, it is simply not possible to make it behave exactly as in VO.

The reason is that in (ansi) VO, the Greek word "αβγ" (alpha, beta, gamma) is represented by the character values 225,226,227, while in (unicode) .Net, the values for the same letters are 945,946,947. Crypt() works in byte level, so obviously it cannot have the exact same behavior and results in both VO and X#.

[ic2]

Hello Chris,

Dick, unfortunately there's no "VO protocol" that we can follow, it is simply not possible to make it behave exactly as in VO.

Just to be sure: you mean: Crypt can't behave like it does in VO and at the same time work with Unicode, correct?

Just to make sure we understand each other correctly: I need a Crypt function (a 2nd one, like CryptVO, one with an extra parameter, whatever), which does decrypt my existing passwords correctly. If that would be impossible, I will remain with the Vulcan DLL's which basically means I can't use any future X# version which I really hope is not what you mean .

I also can imagine that a Crypt function changing it's behavior without a user knowing that (like what happened to me) is a problem on it's own. End users of former VO->new X# created programs will suddenly see that these don't work anymore. If you are able to create 2 versions, it's probably better to make strong typed 3rd parameter so every user will be forced to add a parameter and chose for VO or X# working.

I think nobody coming from VO has chosen for ASCII keys >128 anyhow...

Dick

[Jamal]

Hi Chris,

I don't know if anyone is using the X# Crypt function, but I think it should be thrown away and instead implement more secure Encrypt() and Decrypt() functions using .NET AES Class found the System.Security.Cryptography. For the VO Crypt() there should be a BIG warning that's is compatibility function and should not used in new .NET apps.

Just my 2 cents!
Jamal

[Chris]

Dick, i will send you a version that behaves exactly like the vulcan runtime version did. You previously said that this one worked well for you, so do not worry, the one I will send you will work fine for you as well.

Jamal, I completely agree, problem though (with this and many other functions) is that it's heavily used in a lot of VO applications, so we need to provide a compatible (as much it can be) solution. Bigger problem is that some developers need their X# version to be able to share (at least in the beginning) the same existing data/dbf etc with their existing VO applications, so unfortunately "just" switching to a better crypt system is not always an option.

[Chris]

Oh, after all there did exist a small bug causing Crypt() in X# to be incompatible with VO also with chars < 128 ascii. Fixed that, also added a new function CryptRaw() which treats characters in strings as single bytes (ignoring the high order byte, thus corrupting non-English characters), so it is compatible with vulcan's implementation of Crypt(). The previous implementation of X# Crypt() remains intact. Dick I am sending you a new dll that contains the update, please check your email.

[ic2]

Hello Chris,

Thanks you very much! I'll check it and let you (and other readers) know.

Dick

[ic2]

Hello Chris,

I am again impressed with how fast you solved this problem! Crypt seems to work fine (will test some more) but the initial problems aren't solved unfortunately, see
https://www.xsharp.eu/forum/private-pro ... inued#9592

Dick