encrypt/decrypt seems spotty

[Da_Elf]

Was trying a demo stack i found online which lets you encrypt or decrypt information via two simple functions. I replicated those functions and setup an example using blowfish as the encryption method. All i wanted was some data thats encrypted to be stored to a file and new data added to it. So i get some data... a name... then i encrypt it and save to a file. Then i read from the file, decrypt the info, add a new name on a new line then re-encrypt the info and stick it back into the file. Most of that works ok. but i got it to answer out some of the stuff like the decrypted info and the new info to be encrypted and unfortunately it seems like its not decrypting stuff properly. Sometimes the info is messed up. sometimes its just blank. its weird

[sefrojones]

On which platform/ Version of LC are you experiencing this?

[Da_Elf]

LC 6.6.2 on windows 7

These are the functions

Code: Select all

function fCipher vText PassCode
   encrypt vText using "blowfish" with PassCode at 128 bit
   return it
end fCipher

function fDecipher vText PassCode
   decrypt vText using "blowfish" with PassCode at 128 bit
   return it
end fDecipher

Ive got a simple text input field called "Text" and a simple button with this code on the button

Code: Select all

on mouseUp
   put URL "file:code.code" into rText
   put text of field "Text" into addText
   if rText <> empty then
      put fDecipher(rText,"Pass") into decodedText
      put decodedText & return & addText into newText
   else
      put addText into newText
   end if
   answer "To be encoded"&return&"----------------------"&return&newText
   put fCipher(newText,"Pass") into encodedText
   put encodedText into URL "file:code.code"
end mouseUp

by the 7th or 8th entry it starts to mess up

[sefrojones]

I can confirm this behavior in LC 7.0 RC1 back to 6.5.2 GM running in Ubuntu 14.04 64 bit, beyond that IDK. possible bug?

[Da_Elf]

the behavior is confirmed but is it due to an error on my part or is my code ok?

[Da_Elf]

actually. on a random thought i figured that maybe the decoder or encoder couldnt do its magic fast enough to keep up with the rest of livecodes functions and it gets confused. so i added a wait command of 2 seconds after decoding and after encoding and ive just entered 14 lines so far with no mistakes... spoke too soon. at 15 i decided to use some long strings and around 17 it started giving problems again.

its like it needs time to encode and decode and the more info there is to encode and decode the longer it takes

[Simon]

it's "binfile:"

Simon

[FourthWorld]

Use the binary specifier ("binfile" when using URL syntax) when reading/writing files containing binary data, e.g.:

put tSomeData into url ("binfile: "& tSomePath)

[sefrojones]

And that solves that. Thanks Simon and Richard.

[Da_Elf]

thanks. i didnt think of binfile since i always imagined binary data to be ones and zeros. not the weird stuff i see in the blowfish encrypted file

[FourthWorld]

thanks. i didnt think of binfile since i always imagined binary data to be ones and zeros. not the weird stuff i see in the blowfish encrypted file

It's probably better to think of binary data as any wierd stuff that isn't easily readable.

The 1s and 0s of binary bits are treated by the computer in groups of 8 making a byte, and when displayed it'll use the character that corresponds with that byte value. In some cases this may seem somewhat readable, but interspersed with readable characters you'll also see things that look like junk.

As a general rule, anytime you see parts of text that look like junk, you're probably dealing with binary data. Specifying the binary options for reading and writing files will retain that data without alteration.

At this point you might be wondering, "If the binary option retains the data unaltered, what does the text option do and why is it the default?"

The reason for this is that much of what we do with computing involves human-readable text, and since LiveCode is a multi-platform tool it needs to account for the differences among the various OSes it supports, mostly with line-endings.

Windows uses two characters for line endings (ASCII 13 followed by ASCII 10), while Mac uses true ASCII return (ASCII 13), and Unix/Linux use ASCII 10.

It would be enormously cumbersome to work with text in LiveCode if all of our code had to check the current OS and parse text in different ways for different OSes.

So instead, within LiveCode a return always uses the Unix convention of ASCII 10 (much as it uses the Unix convention for path delimiters, regardless of platform).

And to make this happen, when it reads text files from disk it translates line endings to use ASCII 10, which is what we want when working with plain text, but as you can imagine this can wreak havoc with binary files where it's important to retain every value as-is.

So the default mode is text to make it easy to work with simple text files across platforms, and when you need to work with binary data you can specify that that's what you're doing and it'll bypass the line-ending translation.

[Da_Elf]

thanks richard. thats most helpful