Message Length Invalid?

Discussion related to AES Crypt, the file encryption software for Windows, Linux, Mac, and Java.
Post Reply
contracted
Posts: 5
Joined: Thu Apr 09, 2015 8:19 am
Contact:

Message Length Invalid?

Post by contracted » Thu Apr 09, 2015 8:28 am

So i rar'ed up some movies on my friends external and since it was fat32 the rar made several 4g files. Anyway i used AES crypt on them (for no reason other than to do it) and when i installed AES crypt on his box at his hosue to decrypt the files i got an error on 3 of the 4. the 4th was the smallest of the .part files and that decrypted fine but i cant extract anything because i need the other 3 encrypted rar files.

Anyway i ended up just copy/paste the movies and didnt bother encrypting them lol.

That being said, what is this error? here is the full text from the error dialog box:


Invalid input file C:\Usrers\josh\Desktop\folder.part1.rar.aes
Message Length Invalid




This applies to part2 and part3 but again, part4 decrypted just fine.
Any info would be great so I dont run into this problem again.

Thanks!

User avatar
paulej
Posts: 524
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Message Length Invalid?

Post by paulej » Fri Apr 10, 2015 4:20 am

FAT32 limits file sizes to 4GB. If those .part files are exactly 4GB then a file slightly larger than 4GB would be created for the .aes file. It sounds like the file is being truncated to 4GB, perhaps, and AES Crypt is detecting that part of the file is missing. That's the complaint about the invalid message length.

But, I am curious why AES Crypt did not complain when it tried to create the .aes file reporting an error "Unable to write to ...". I checked the code and it looks like every file write attempt is checked for an error, but perhaps there is a bug in the error reporting logic.

Did you use AES Crypt on the files sitting in a FAT32 file partition, or did you encrypt them on an NTFS partition and then copy them to FAT32?

contracted
Posts: 5
Joined: Thu Apr 09, 2015 8:19 am
Contact:

Re: Message Length Invalid?

Post by contracted » Fri Apr 10, 2015 8:28 am

I checked the format of the drive i sent the files to and it is indeed a NTFS. I however when doing the original RAR compression in WINRAR I had the "split to volume, size" or however its worded. But I am not sure if for some reason the drive was originally fat32 and WINRAR picked up on that when I was sending the RAR file there.
I will try and duplicate the problem and reformat the drive to FAT32 and place the files back on it and see if I get any other result.

contracted
Posts: 5
Joined: Thu Apr 09, 2015 8:19 am
Contact:

Re: Message Length Invalid?

Post by contracted » Fri Apr 10, 2015 9:03 am

No go.
I moved the files off the drive, formatted to FAT32, put the files back on and have the same issues. All files with exception of the ,part4 are giving me the original error.

I tried renaming the files and it has no effect on the results either, they remain the same.

For the properties size on disk is 4.00gb while size says 3.99gb I figure that's the extra data from AES crypt?

I also intentionally entered the wrong passwords to each .part and all but the last file (the one that is able to be decrypted) give me the same error as if I entered the actual password.

I would hate if these files were important and not just the bourne series lol.

I realized that what I just did was moot. I am thinking that yes as you said I created the RAR .part files on the FAT32 which created 4gb files then when they were encrypted it may have caused some problems. The first 3 files are all 64bytes short of 4gb. I assume that is why the 4th and last file is able to be decrypted is because there was plenty of space for the encryption as that last file (.part4) is only 1gb. I would have to compress and encrypt them again that way to find out I guess?

Hope this information helps you see if there is a bug or a missing "check" before encryption starts for drive format to see if its fat32 or NTSF because it is not a "available Space" problem it was a format limit. Not a coder so I hope the info is useful :/

User avatar
paulej
Posts: 524
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Message Length Invalid?

Post by paulej » Sat Apr 11, 2015 6:45 pm

It really sounds like there might have been an error writing to disk and that error want caught.

If you look at the properties dialog box when right-clicking on the file, it will tell you exactly how many bytes the file is. Tell me that for one of the broken parts and I'll create a file exactly that same size and encrypt it on a FAT32 USB drive and see if I get an error.

BTW, did you have plenty of space on the drive? I'll check for file size problems, but I don't want to overlook the "disk full" possibility.

contracted
Posts: 5
Joined: Thu Apr 09, 2015 8:19 am
Contact:

Re: Message Length Invalid?

Post by contracted » Sat Apr 11, 2015 10:53 pm

4,294,967,232 bytes for the fist 3 files, 64 bytes short of 4gb

Remember that I am not sure if the drive itself being fat32 forced the RAR compression to make .part files of 4gb OR if the drive itself was NTFS and I accidentally make .part files using WINRAR

*The drive was NTFS and I made .part files of 4gb each which ended up being 64bytes LESS than 4gb AFTER encryption

-or-

*The drive was FAT32 and upon selecting all 5 Movies and "add to archive" using WINRAR, the WINRAR program created 4 .part files, three of them at maximum size for the drive, 4gb and 1gb respectively and three of which ended up being 64bytes LESS than 4gb AFTER encryption.

I how this helps!

User avatar
paulej
Posts: 524
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Message Length Invalid?

Post by paulej » Sun Apr 12, 2015 12:57 am

I don't really care what RAR does. What's important is that after you ran RAR you ended up with a .part file of some size. As I understand, that .part file was the size you specified above prior to running it through AES Crypt, right? And the file system you used when creating the .aes file was FAT32, correct?

I just want to replicate the encryption process with the same size file on the same file system. Also, was that Windows 7 or 8? I can test either of those.

contracted
Posts: 5
Joined: Thu Apr 09, 2015 8:19 am
Contact:

Re: Message Length Invalid?

Post by contracted » Sun Apr 12, 2015 4:58 am

paulej wrote:I don't really care what RAR does. What's important is that after you ran RAR you ended up with a .part file of some size. As I understand, that .part file was the size you specified above prior to running it through AES Crypt, right? And the file system you used when creating the .aes file was FAT32, correct?

I just want to replicate the encryption process with the same size file on the same file system. Also, was that Windows 7 or 8? I can test either of those.
I do not know the file size BEFORE running encryption. The size I specified is after encryption.
I do not know what the original format of the drive was.
The part files were created by WINRAR either by me (unlikely) OR automatically by WINRAR
Windows 7 home.

I believe that the process went like this:

1.Dragged 5 movies consisting of >13GB (none of which were individually over 4gb) on to a FAT32 drive with 64gb of space.

2. Selected them all and compressed them resulting in four .part files, 3 of which were whatever WINRAR made them (as I said I do not know the file sizes before encryption) at maximum size for a FAT32 format.

3. Then I encrypted the .part files individually.

User avatar
paulej
Posts: 524
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Message Length Invalid?

Post by paulej » Fri Apr 17, 2015 11:12 pm

Sorry it took so long to get back to you on this.

The good news is that I found the problem. The bad news, of course, is that there was a problem. :(

It seems that in the Windows code, Linux code, and Mac code, the code was not checking to ensure the final write operation was working (i.e., the file closure and writing of any remaining data in the file I/O buffer). I tested the issue on WIndows and Linux. It appears that only the Windows GUI code exhibited this problem. Nonetheless, I changed both the Windows and Linux code (Mac code is built from Linux code) to check for errors when closing the output file. If there is a error when closing the file, that will be reported and acted on.

That will fix your 4GB issue (and I was able to reproduce the problem, BTW).

I did get a report from one other person that they had a similar issue with a 40GB file. I do not know if it is related or not, but in all the years that AES Crypt has been in use, this was the first time I had seen this issue and I got two reports in the same week. Odd.

In any case, version 3.10 of the Windows and Linux code are now posted. I also checked in the same code changes into the GitHub repository, though that code and the source code I publish here are still not fully synchronized. (I just need to find time to do that, which sadly never seems to happen. But, I will make time to fix bugs like this, as they can truly be a problem -- even if extremely rare.)

Post Reply