|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Testing "Is a File Encrypted" |
| Débuté par StanleyBarnett, 28 mai 2016 11:02 - 6 réponses |
| |
| | | |
|
| |
Posté le 28 mai 2016 - 11:02 |
Hi,
Using WinDev 21...
Are there any methods that I can call to see if a file has already been encrypted to avoid encrypting it again? I do not want to change the filename to reflect if it has been encrypted.
Does the encrypted file have a signature that could be low level read to determine if it is/was encrypted?
How would I detect and make sure an encrypted file doesn’t get encrypted again un-intentionally?
Is WinDev or WLanguage capable to create a user defined function that reveals whether its encrypted or not. Something like IsEncrypted()... that would add a 20 byte header to the file AFTER it is encrypted and allow us to supply the content value for the header so the encrypt routine knows what to store in the first 20 bytes. This way it can be automatic and not re-encrypt the file if the encrypt routine first read the file's header, (byte 1 thru 20).
I've considered doing this but I'm afraid of performance issues on files greater that 5mb. If this could be done at a low level, then performance might not be an issue. And of course, to decrypt, one would have to first strip the 20 byte header away BEFORE decrypting.
Any thoughts?
Stanley |
| |
| |
| | | |
|
| | |
| |
Posté le 28 mai 2016 - 14:25 |
Hi Stanley,
if you know the type of file, you know what type of content it should have at it's beginning and you can check for that.
Now if you are working with files that can have ANYTHING at the beginning you need to had your "header". That can be done easily with the fxxxx functions, however, you may want to add it at the END of the file, in order to speed things up.
Best regards |
| |
| |
| | | |
|
| | |
| |
Posté le 28 mai 2016 - 23:24 |
Hi Fabrice,
>> if you know the type of file, you know what type of content it should have at it's beginning and you can check for that.
This is not at all reliable as for example the tif file format has many different header types... Several examples showing why it would be very difficult to handle. Take a look at
http://www.garykessler.net/library/file_sigs.html
where the .doc and .xls headers and you will see several totally different header variations. I discovered that last year and opted to not depend on that, plus many files from other operating systems do not respect the windows/dos extension convention.
I need to be absolutely sure that the file is or is not encrypted by our encryption process. This way we can encrypt file that were encrypted by other encryption processes without worrying about losing data.
Good to see the fxxxxx functions can do this whole process.
Is there a file size limit with these fxxx functions?
What functions would I need to use as I have not look at them yet?
Thanks again,
Stanley |
| |
| |
| | | |
|
| | |
| |
Posté le 30 mai 2016 - 17:59 |
Hi Stanley,
In general an encrypted file will get a different extension. Just the same way as a compressed file will get a different extension (e.g. .zip)
Otherwise the operating system cannot determine how to open a file with the same name and extension but a different binary content (encrypted/not encrypted version of myimage.tif).
We use OpenSSL to encrypt files in several of our solutions and the files keep their name, but the extension becomes .p7m.
Not sure what you're trying to do, but it sounds very counter-intuitive and not in accordance with general coding and file naming principles.
So after encrypting, I would change the extension of the file as the extension would indicate which program to use in order to process (decrypt) it...
You could always keep your original extension in the name:
E.g.: myimage.tif becomes myimage.tif.p7m
This way you know what to rename to in case you decrypt the file...
Just my 2 cents,
Peter Holemans |
| |
| |
| | | |
|
| | |
| |
Posté le 31 mai 2016 - 00:59 |
Hi Peter,
Adding an extension ".p7m" to the filename is in fact changing its name and breaking the rules on what the actual file is to be opened with by windows. Most windows OSes knows to open readme.txt with notepad. If you encrypt it to readme.txt.p7m, windows no longer recognizes it as a notepad file. This breaks all the windows default program rules. If if you register the .p7m extension with windows as a OpenSSL app, something would have to supply the decrypt key to make it readable/usable again.
In our case, we check if the file is actually present and changing its name would force us to add logic to deal with the extra if/else tests.
I can do as you suggest and change the file names, and that is easy, but my original questions was about whether the Wlanguage had enough low level file functions to...
1. open the file
2. read and get the last 20 characters of the file and compare it with the hash of the known key (the last 20 characters is not the key, instead its a hash)
3. if the hash (last 20 characters) matches the key's hash, then close the file if our mission was to encrypt, (because it is already encrypted) otherwise we will remove the last 20 characters and save the encrypted file to disk/memory.
4. if decrypting, we decrypt the file we just saved to disk where the last 20 characters has been removed.
5. now save the decrypted file to disk,
Question... After the file is read, how much can be done in memory without saving to a file first? Optimally, I'd like to have disk i/o only on the first read and the final write.
And, is any of this subjected to the 2gb limitations on NTFS?
Thanks, Stanley |
| |
| |
| | | |
|
| | |
| |
Posté le 31 mai 2016 - 13:32 |
| |
| |
| | | |
|
| | |
| |
Posté le 01 juin 2016 - 08:17 |
Thanks Paulo, I'll now do my homework with your suggestions.
Stanley |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|