TL;DR - read next message instead.
>It is possible to know, though, since there are two HMACs and the first would indicate whether the proper key was provided.
Ah, good idea to have 2 levels, nice bit of design there. In my case the password is definitely OK as the output file, post error message is readable, it's actually an encrypted rar (I said zip before, it's actually a rar). The file/folder names are also encrypted but it opens successfully and shows the directory structure, albeit with a 'the header is corrupt' message which might imply the problem was at the the end of the file, or not, but it then extracts the structure and content. I didn't do any kind of serious check for completeness but if the AES password was wrong then surely I'd just get gobbledygook, it'd be deeply worrying otherwise
.
>I just worry about ignoring this error in the general case.
I'm certainly not ignoring the error, valuable info to know the file got changed somehow after encryption and makes me happy I keep generations and copies on other drives and cloud storage but I still wanted to see what could be recovered, and in this case couldn't find anything obviously missing. Of course if a bit or two got flipped in a piece of source or something it wouldn't be obvious anyway but presumably rar extract would give an error when a file checksum looked wonky, if it checksums at the file level anyway.
>What concerns me is the fact that the file was corrupt in the first place. I sure hope it wasn't AES Crypt that produced the corrupt file!
I really don't think it can be AES, a bug like that would have come out years ago surely, I'm not doing anything unusual with it.
AESCrypt command was of the form;
Code: Select all
$CommandText = "C:\Program Files\AESCrypt_console_v310_x64\aescrypt.exe"
$Arguments = @('-e', "-p" + $Password, "-o" + $AESFileName, $FileName)
The 6Gb file it happened to was created as an encrypted rar on a local drive, AESCrypt'd, then RoboCopy'd to an external USB drive (I checked the date, 20th June, I thought it was longer ago), then the other day I copied it back with File Explorer to local to dig out an old SQL backup. As impossible as it seems, I guess it must have happened during the copy back and forth... applying the old Sherlock Holmes maxim of once you have eliminated the impossible seems to leave no possibilities !
Would a hex dump of the first or last X bytes of the AES file be of any use ?
I can also check other copies of the same file from another archive, I'm downloading a cloud version of it right now but it's coming slowly, will report back later.
The wisdom of the 2-level AES encrypt of an encrypted rar may be questionable, not really my area of expertise ! - perhaps there are predictable patterns in the zip header that might make brute-force cracking the AES take a decade less than usual or whatever but in the end it's just my source code, not the recipe for coca cola so it's fine - the reason I AES the file is because I upload backups to cloud storage too, and figure AES is stronger than a plain rar but haven't really investigated, that's off topic though !