Encrypt 1MB text file

I have a 1MB text file which the program uses, when opening, to provide data for the program’s use. It is read into a text variable on opening. This operation is very fast. No notable delay on opening the program.

Now I would just as soon that users of this program did not have “easy” access to the text file independent of my program so I would like to at least obscure it. It is not an issue that requires military grade security. Just trying to discourage an amateur hacker. The 1MB file is UTF8 text with many Japanese characters so it is not just simple ASCII text.

This is a static piece of text that does not change with the use of the program. I would like to encrypt it with my program “knowing” the password so that when it was imported on opening the program it would decrypted within a couple secs. Is this realistic? And how would you do this?

When I look at the crypto functions of Xojo, they are confusing to me and I am not sure that they are intended to encrypt a large (1MB) piece of text. Maybe I am wrong.

One thought that I had was to create an SQL database with basically one record and one field that was this 1MB text file. I would encrypt that database and decrypt it within the program to get access to the 1MB file? Is that a crazy “indirect” approach to a problem that would be simply solved by some easy way of encrypting and decrypting a 1MB text file?

Maybe Einhugurs e-CryptIt Engine is for you. I can highly recommend his Plugins.

Interesting timing. I’ve just written an article describing an “obfuscation” method for the next issue of xDev, which comes out on Monday (May 2nd).

The problem with actual encryption is that your program needs the key to decrypt it, so then you’re having to obfuscate the key somewhere in your program… might as well just obfuscate the text file if you don’t need it to be super-secure.

MBS Plugins have an example to use SQLite for storing preferences.

We also have encryption functions, e.g. to use Blowfish encryption easily:

and we have obfuscation, e.g. by putting in a picture: Picture.AddSteganographyMBS

Look at RC4v6 function… as Mark says: the problem is the key, the “obfuscation” of the key, may be with Obfuscate or random strings.

IMO, just but the MBS Plugin, and you’ll have a solution and you’ll have the tools in hand to solve dozens of other problems in the future.

It depends on the level of amateur you’re trying to thwart, but if it’s just basic, you could save the file as Base64-encoded.

There are other mechanisms to encrypt the data
https://sites.google.com/site/skydancerstudios/rb-blowfish is one
which ever you use I’d write a small app to encrypt the data using something from Crypto

Take that encrypted data & put it in a constant inside your application
That way it’s compiled in instead of being in a separate file
Then you decrypt it at app start up to load the data
This will stop most simple “hacking”

I had not thought of simply putting the static 1MB file into the program itself as a text file. That is actually “enough” security for my purposes even if it sits in there unencrypted. And it makes it easier for the user because there is one less file to deal with. It probably violates some principle that you should not have “data” in your code, but in this circumstance it might work for me.

When I just try it this morning it does not quite work for some mysterious reason, but I will work on this in a few days when I come home from a trip. I am intrigued, but I have to leave for this small trip

I am surprised by this because I was originally just importing the data into a variable in the program. To test the Constant approach, I just pasted the 1MB file into a Constant in the IDE and then altered the code to copy it into the same variable to see if it would work. For some reason it does not. Self.xInfo is the variable (property). It has plenty of return characters,

[quote] Dim axOneLine() As Text
axOneLine = Self.xInfo.Split(CR)[/quote]

That line does not work when Self.xInfo has simply had its contents transferred from the Constant.
The variable is large enough that I cannot effectively see it in the debugger. The wheel starts spinning endlessly.

Anyway, with a little time, I should be able to study this and get a notion of what is happening.

But I am going to look into the other suggestions made because then I will learn something about encryption. Both the Tekinay and MSB.

Look forward to the obfuscation article in xDev. Thanks all.

Issue is now hot off the “press” (so to speak). Article is paid, but the source code is free:


Try this:

dim axOneLine() as Text =xInfo.Split( &u0A )

The line separator is a linefeed (&u0A) not a carriage return. I think that’s true on Windows too, but if you want to be sure:

dim raw as Text = xInfo
raw = raw.ReplaceAll( &u0D + &u0A, &u0A )
raw = raw.ReplaceAll( &u0D, &u0A )

dim axOneLine() as Text = raw.Split( &u0A )

See http://documentation.xojo.com/index.php/ReplaceLineEndings

kem - that is a horrible way to do it x-platform

Dim axOneLine() As Text
axOneLine = ReplaceLineEndings(Self.xInfo, EndOfLine).Split(EndOfLine)

Agreed that’s better if it’s available. Not sure if he is trying to stick to new framework though, hence the “long” version. (Why is it “horrible”?)

And wouldn’t it be…

axOneLine = ReplaceLineEndings(Self.xInfo, EndOfLine).ToText.Split(EndOfLine)

It’s horrible because &u0A is the line ending on only one of the three main platforms. Hence the existence of LineEndings and ReplaceLineEndings.

  1. I dont see where robert says new framework only
  2. replaceall the way you’ve done it requires more temporary copies & therefore more memory
  3. your replaceall version makes 2 passes through the data
  4. &u0A is not obvious that it is “EndOfLine” on any platform

I’m sure I’ve missed something but those 4 are a good start

This is just another instance of “why would you ever write it that way?” like I asked the other day when you posted similar code

  1. Right, I was being proactive. But I should have mentioned ReplaceLineEndings if available.
  2. If ReplaceLineEndings is not available, that’s the only way to do it. Even EndOfLine is not available. Again, I should have mentioned that.
  3. Same as above.
  4. The codepoint used is not important, just as it wasn’t in the other thread. It doesn’t matter if it’s native to the particular platform or not since it’s being used for Split exclusively. (cc @Tim Hare)

Still don’t think “horrible” was the right word. :slight_smile:

Its not obvious nor easy to read
&u0D &u0A are not obviously “end of line” alone or together
A constant would be nicer

And direct support for “something” in the framework even better
Not sure if that would land in System or something like Platform
Either way - we experience these same issue so we do have lists of things we’re considering adding but they need consideration & discussion rather than just toss everything in

The new framework seems somewhat, incomplete. Haven’t used it. Probably won’t for some time.

The new framework has a few interesting features not found in classic framework, such as Xojo.io.SpecialFolder.GetResource, Timer CallLater, Text support for composite glyphs, HTTP 1.1 with Xojo.Net.HTTPSocket.

Unless you are developing for iOS where the classic framework is absent, I see very little reasons to switch entirely to the new framework. I tend to use the new framework as needed, when classic would not do. Besides, sometimes it is not implemented, such as in Web where Xojo.io.GetResource is not here, as I found out last week.