XML file Encryption/Protection

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.

Project Data as Binary Data (Not sure about this)
Compress the file on save(Need to know what are the best ways to achieve this)
openssl or crypto++ to encrypt
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...