XML file Encryption/Protection

[faiszalkhan]

The project file of the developed application has a custom extension to it. Internally I have used XML to structure data inside.
The Project file is used to open the project in the Application. Also, when the user hits save, the file is updated.
Since the project file is of utmost importance, changing it outside the application could result in undefined behavior and many use cases to take care of.
I want to protect this file from an average user who should not mess the file. What is the best way to achieve this?

Thanks.

[beecksche]

@faiszalkhan

One big advantage of XML is that it's human readable. So to encrypt it would be contradictory.

So why don't you save your project data as binary data?

[VRonin]

@faiszalkhan said in XML file Encryption/Protection:

I want to protect this file from an average user who should not mess the file.

To obfuscate you can just compress the file on save. Of course this does not give any kind of protection from intentional changes to the file contents outside your application. If you want to go one step further you can use openssl or crypto++ to encrypt your file but since the decryption key will be stored in your application anyway, a motivated attacker will always be able to crack it. And in any case, you can't protect the file from becoming unreadable by the user simply changing/chopping the content of the file using a text editor

[faiszalkhan]

I have not given a thought to binary data. Also, please think of the file as a project file which is created by the user via the application. This file would be stored on the disk(Any location). Think of .docx file, if we open it in notepad++, we cannot make anything out of it but works perfectly with Word.

Thanks.

[mrjj]

@faiszalkhan
Hi
But how much protected?
How good are your avg. users?

For some use cases, simply encode it with base 64 is enough to
make it unreadable for them whereas for others user not even
a binary file will stop them.

You could also add a checksum to the file so you can detect if indeed changed. ( and stop loading it)

[VRonin]

@faiszalkhan said in XML file Encryption/Protection:

Think of .docx file, if we open it in notepad++, we cannot make anything out of it but works perfectly with Word.

Try opening it with 7zip (or any other zip reader). office (both MS and Open/Libre) use the first method I mentioned i.e. compress the file on save

[faiszalkhan]

@beecksche @VRonin @mrjj

So as per the thread, I can use the following methods to protect the project file from getting changed by an average user. The Average user is a Software developer who might get the motivation to play with it.

1. Project Data as Binary Data (Not sure about this)

2. Compress the file on save(Need to know what are the best ways to achieve this)

3. openssl or crypto++ to encrypt

4. Encoding with base64

Since I am not an expert on this and have not worked on a task of this nature before, I am not sure which option is the best to go with.

I have two basic requirements,

• When the user double clicks the project file, it opens in the Application, Everything is good. This is Achieved.

• When the user tries to edit the file from outside(Say notepad++), he/she should see obfuscated data just like when Word document is opened in Notepad++. This is pending.

Thanks.

[jsulm]

Is there a reason for such a requirement? Why should an user want to edit the project file manually? And if an user would do this - what is the problem? At the end he/she can edit it in your app anyway, right? As an user I would not like if the app I'm using would try to hide the data from me...
Word files are not really obfuscated: they are zip archives containing text, images,...

[faiszalkhan]

@jsulm There is a problem with the user editing it. The user doesn't know the exact structure of the project file, changing it might make the file not readable by the application. This could result in loss of work for the user.

[jsulm]

@faiszalkhan That's clear, but why would a user want to edit this file outside of your app?

[VRonin]

@faiszalkhan
1 basically means ditching all the code you already wrote to save/load in xml and start from scratch using binary data (pro: fastest serialisation/deserialisation; cons: require re-engineering the serialization process, strings serialised to binary are still pretty readable if opened in a text editor)
2 is a 2 stage process (pro: obfuscates the contents, doesn't require change of existing code to serialise, smaller file size. cons: slower save/load process)

// instead of saving directly to file, save the xml to a temporary buffer in memory
QByteArray plainxml;
QBuffer planxmldevice(&plainxml);
// save as usual
// void saveProjectFile(QIODevice* out);
saveProjectFile(&planxmldevice);
// save the compressed buffer to the final file
QSaveFile projectFile("projectFile.myextension");
Q_ASSUME(projectFile.open(QFile::WriteOnly));
projectFile.write(qCompress(plainxml));
projectFile.commit();

// Load the compressed file and read it to a temporary buffer in memory
QFile projectFile("projectFile.myextension");
Q_ASSUME(projectFile.open(QFile::ReadOnly));
QByteArray compressedxml = projectFile.readAll();
// decompress the buffer
QByteArray plainxml = qUncompress(compressedxml);
compressedxml.clear();
QBuffer planxmldevice(&plainxml);
// void loadProjectFile(QIODevice* in);
loadProjectFile(&planxmldevice);

3 is basically the same as 2 but instead of qCompress/qUncompress you'll have a function to encrypt and one to decrypt the data. The actual body of the function depends on the library and encryption method you chose (pro: encrypt the contents, doesn't require change of existing code to serialise, cons: slowerest save/load process, encryption is not hack proof)
4 can be used as 2 just by replacing projectFile.write(qCompress(plainxml)); with projectFile.write(plainxml.toBase64()); and QByteArray plainxml = qUncompress(compressedxml); with QByteArray plainxml = QByteArray::fromBase64(compressedxml); (pro: obfuscates the contents, doesn't require change of existing code to serialise. cons: the result will be a string of ascii chars that can still be readable and easily de-obfuscated by the user, base64 is very recognisable when opening the file with a text editor)

changing it might make the file not readable by the application

There's nothing that can prevent this to happen. The user can always mess with the content of the file with an hex editor and you just can't prevent it. All you can do is put redundancy in place (like MS office does with autorecover but as you might be aware if you ever used that feature is not 100% reliable)

[faiszalkhan]

@jsulm I don't know. We've had experiences before :D
Thanks.

@VRonin Thanks. Will look into this.

[Pablo J. Rogina]

As @jsulm said:

Why should an user want to edit the project file manually? And if an user would do this - what is the problem? At the end he/she can edit it in your app anyway

I'm thinking of translation files (.ts) or GUI files (.ui) in Qt itself. They're just plain XML files, and I create/edit them with proper applications (Linguist and Designer respectively). BUT I can also edit them with my favorite text editor, why not?
And if I mess them up, my favorite version control system (git, SVN, you name it) will come to the rescue to back them up to the point before the issue.

It looks like you're doing a lot of work/effort for something that could be avoided...