Packetizer Forums

Hi Paul, did you know:
(Windows version)

- You can crypt an empty txt (ANSI encoding) but you can't decrypt it ( Input file is corrupt )
Why the software can crypt it but can't decrypt it?
- If i want to decrypt "picture.jpg.aes" and in the same folder i have another picture.jpg ( maybe it's a different file ) he automatically overwrite the old picture.jpg with the new picture.jpg. There is a way to avoid overwrite?

Thanks

johnmcloud wrote:Hi Paul, did you know:
(Windows version)

- You can crypt an empty txt (ANSI encoding) but you can't decrypt it ( Input file is corrupt )
Why the software can crypt it but can't decrypt it?

I don't have any issues decrypting a zero-length file on Windows, using either the GUI or the command-line. I also do not have this problem on Linux, either. (This is actually a test I perform every time I introduce a change in the encryption or decryption logic.)

johnmcloud wrote:- If i want to decrypt "picture.jpg.aes" and in the same folder i have another picture.jpg ( maybe it's a different file ) he automatically overwrite the old picture.jpg with the new picture.jpg. There is a way to avoid overwrite?

The GUI version on Windows does perform a check and will not over-write a file. However, the command-line version (Windows, Linux, Mac) will not: it will just over-write any existing file. That's a bit harsh, but it's fairly common practice for most command-line tools. I like it that way, myself, but it has caused some heartburn for folks who did not realize there was already a file with the same name. So, this is on the "to do" list, but not sure when that list will get addressed.

Paul

paulej wrote: I don't have any issues decrypting a zero-length file on Windows, using either the GUI or the command-line. I also do not have this problem on Linux, either. (This is actually a test I perform every time I introduce a change in the encryption or decryption logic.)

I have this issue, my s.o is Windows Xp, i'm using the command-line version
You can find my test on attachment, the password of the crypt file is:
1
I know it's not a secure password but was a test

paulej wrote: The GUI version on Windows does perform a check and will not over-write a file. However, the command-line version (Windows, Linux, Mac) will not: it will just over-write any existing file. That's a bit harsh, but it's fairly common practice for most command-line tools. I like it that way, myself, but it has caused some heartburn for folks who did not realize there was already a file with the same name. So, this is on the "to do" list, but not sure when that list will get addressed

I'm using the commandline version and i have an heartburn yesterday, luckly i don't have lost nothing.
Maybe you can add a paramenter for don't overwrite the file? By default overwrite, adding example -s don't overwrite. Please If you can do it i'll really appreciate, and my heart thanks you

That decrypted just fine for me. I can't explain why mine works and yours does not. The software is exactly the same. That's strange.

Not automatically over-writing is on the "to do" list, but I have many things on the to-do list. I'll get to it when I can, but likely will not be soon.

We need a package maintainer who has more time than I do for these things

You can decrypt that empty file? Really strange.
If you want i can make other test, i don't have idea what is the problem, i have try on another pc with the same s.o and i have the same error

johnmcloud wrote:You can decrypt that empty file? Really strange.
If you want i can make other test, i don't have idea what is the problem, i have try on another pc with the same s.o and i have the same error

Yeah. As I said, decrypting a zero-length file is always one of those "edge cases" that I check every time I change the encryption/decryption code.

I trust you are using the latest version? All versions should work, of course, but I only tested with the current code published on aescrypt.com.

Sure, anyway i have download it again
Console (Windows 32-bit)
Version 308a_win32_console

This is the output: Another strange thing, if i use the last GUI version work fine!
In the same package of the GUI ( v308_win32 ), if i'll try to decript with the command line i have the error, if i'll decrypt with AESCrypt32 GUI work
So i think something wrong in the command line version, this is the only thing possible, because give me two different result on the same file.

EDIT: Tested also this commandline version:
v307
v306
But same problem, i don't have found any other version on this site

EDIT2: News! If i crypt the file with GUI version, i can decrypt the same file with the commandline. So the problem isn't the decrypt of the command line because can decrypt the file from the GUI, but something wrong in the crypt method of the commandline, i think.

In summary:
GUI Version - Can decrypt the file created by himself or by commandline
Commandline - Can decrypt the file created by GUI version / give error if i try to decrypt the file created by commandline

You can see the output: You can find both file in the attachment, same password as before.

Hope all of this information can be useful for resolve the problem. Please check it out because i use only the command line

Thanks

Good news and bad news....

First the good news. I tested using the file you attached and I also got the same error. Previously, I just used the Windows GUI to decrypt the file and it worked fine. I then tied to encrypt and decrypt that file with the command line utilities. It all worked fine. What had not done was take your encrypted file and try to decrypt it using Linux. I did that tonight and it failed.

I checked the Linux code and it is rightfully reporting that the file is corrupt. There is an error in the file, but I'm not sure why. Here's a hex dump of the encrypted file you provided:
The problem is the line number "100". The 4th octet from the left has a value 0x08. Since this is a zero-length file, that octet should be 0x00.

The Windows GUI version ignores the fact that this is not 0x00. I actually had code to read the value of this byte, but did not have code to produce an error if it was wrong. It was an oversight. I just updated the source code so that the next release will. However, checking for the error here is of no significance since the contents of the entire file are validated with an HMAC. This was just an "extra" check that I prefer to have, precisely for these reasons. So, it's not a big deal.

The bad news is that I do not yet know why this byte would be bad in the first place. However, I think I might know why. In the command-line versions, I failed to initialize the structure that writes out this modulo octet. In all of my tests, the system initialized this to zero for me, so I didn't notice. IT is certainly possible on some systems that this does not initialize to zero. This might be why you have the error. Now the good news is that this only happens if the file has a zero size. Otherwise, the value would be properly set before it is written.

So, you succeeded in finding one more zero-length file corner case issue I missed. It's now closed in version 3.0.9. New source and binaries will be posted shortly. (I know others are waiting for other enhancements, but I had to post this one. I don't like bugs, and this is a bug.)

Noone like bugs, anyway this is minor bug because the problem is only with 0 lenght, maybe only with that txt ANSI coding (UTF-Unicode etc working fine )

I'm glad to help if i can, so i'll test the new 309 command line when you release it and let you know if i have the same problem ( i have clean XP-7-8 on VM )
Thanks for your effort.

EDIT: Tested the last version 309 on:
Windows XP-7-8
Everything work fine with that empty file, good work