LiveCode Forums.

I have a unique issue that is plaguing me, I created an encrypted text file that should work across platforms, in the past it has done so with no problems, however with the newest version, 4.0 this no longer is the case, so obviously some change occurred that has created some change in the way text is rendered, across platforms.

For example, if I use the SSL library, and encrypt some text on MAC OSX

I can take that same encrypted text to windows and it can then be decrypted using a key or salt value.

However, if I then take and produce the same text and encrypt it on windows, and attempt to decrypt it on MAC osx, failure is the result, in fact the application I created to make this happen, fails to even load, on MAC OSX, when attempting to load encrypted text from a windows machine.

This suggests that there is something happening when the text is rendered from a field created on a windows machine,)

hmmmm, I am completely lost on this one, sorry that there are not more details, but I know that it works fine in the IDE,

But when an attempt as mentioned above is tried, there is obviously some problem with the way that text is rendered from windows to the MAC osx environment, any thoughts or ideas or suggestions,

I know it may be difficult to fully grasp this without the code, but I just have no idea where to even start, the engine used to transcribe text automatically, is this not the case any longer?

or is it something else that I am missing.

encrypted text should not be transcribed from operating system to operating system, but I think it may be what is happening, just thought I would put that out there in case anyone had a thought to share on that,

Yup, I think you need to post your current (failing) script, reelstuff.

Best,

Mark

snip

reelstuff,

Try replacing
with
Best,

Mark

Also, you could try to utf-8-encode the plaintext before encryption.
Decryption would have to be followed by utf-8-decode.
That should give you platform-independency.

(You might even try URL-encode and URL-decode instead of utf8-)

regards

Mark wrote:reelstuff,

Try replacing

Code: Select all

   put aData into URL ("file:" & it & myVar)

with

Code: Select all

   put aData into URL ("binfile:" & it & myVar)

Best,

Mark

Of course, Bangs head...

Yes, that would do it, allright, LOL

ukimiku wrote:Also, you could try to utf-8-encode the plaintext before encryption.
Decryption would have to be followed by utf-8-decode.
That should give you platform-independency.

(You might even try URL-encode and URL-decode instead of utf8-)

regards

Thanks for the reply, yes, I can see that would make a difference I will try both of those out, thanks again.

reelstuff wrote:

ukimiku wrote:Also, you could try to utf-8-encode the plaintext before encryption.
Decryption would have to be followed by utf-8-decode.
That should give you platform-independency.

(You might even try URL-encode and URL-decode instead of utf8-)

regards

Thanks for the reply, yes, I can see that would make a difference I will try both of those out, thanks again.

I took a look at the stack code and it is impressive, I started with the binary issue first, as this was the most likely culprit,

it turned out that this did not allow cross platform use, interesting, because in the past I know that I was able to make this work from one platform to another.

I will have to take a closer look at your suggestions, but it may be above my pay grade, LOL

Hi Reelstuff,

not a paygrade issue

You will find a special utf-encode and decode function in the Blowfish stack that you downloaded. You can use it even more easily than the Blowfish routines, since you don't need to provide any key for encoding and decoding.

I think you would benefit from utf-8 encoding since non-basic ASCII characters like ÄÖÜäöüß, ÉÈÊéèêâô and the like will be encoded properly and preserved across platforms.

I suppose English is not your native language? May I ask where you are located?

Regards

Thanks again, for your post,

I am located in the USA,

Yes, I think you are right about the utf-8 encoding

I think you would benefit from utf-8 encoding since non-basic ASCII characters like ÄÖÜäöüß, ÉÈÊéèêâô and the like will be encoded properly and preserved across platforms.