AES Crypt Error message: Message has been altered and shou

Discussion related to AES Crypt, the file encryption software for Windows, Linux, Mac, and Java.
User avatar
paulej
Posts: 566
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: AES Crypt Error message: Message has been altered and shou

Post by paulej »

Oh, I can definitely fake a tampered file. I tested that rather extensively when writing AES Crypt, after all. Guarding against that is why there is an HMAC. Sadly, there is a bug in the logic, though, that I did fail to find. There is one octet near the end of the file called the "modulo" octet in the file format that is not included in the HMAC, but should. So, it's possible to change that one octet on disk and cause an invalid file to be reproduced by AES Crypt. That's on the "Wish List" page with a "security vulnerability" tag. I plan to fix that by re-engineering how this is done. The modulo octet "leaks" info, too (specifically, the exact file size). In the next version, I intend to introduce a more robust solution (e.g., ciphertext stealing or something).
CuriousChris
Posts: 3
Joined: Thu Jul 15, 2021 2:52 am

Re: AES Crypt Error message: Message has been altered and shou

Post by CuriousChris »

Fair enough re that bug, doesn't seem like a security vulnerability really, just a way somebody could thumb their nose at you for no practical gain.

The next entry on the list is fair warning, though not really an issue for me, my backup system leaves the encrypted [blah].rar and the further encrypted [blah].rar.aes files in the same local folder anyway. Only the .aes files get shifted out to the cloud and removable drives so doesn't leave me any more vulnerable. I added the extra .aes step recently for files that get uploaded and for giving random off-site backup USB sticks to mates to throw in a dark cupboard.

If somebody can get at my local drives then they can ignore the archives and look at the clear text originals anyway - the few proper-secret files with credentials are always at rest in .txt.aes files.

I've now added a hash compare of each file after RoboCopy has done it's thing, so it should catch if a file gets mangled on the way out like last time.

Cheers for the link about ciphertext stealing, though my head started to rotate after about 4 paragraphs so I stopped reading to preserve my sanity ;)
Post Reply