Feature Request: Bring Back the Hidden Custom Extension Support in AESCRYPT

Discussion related to AES Crypt, the file encryption software for Windows, Mac, and Linux.
Post Reply
Joe Neo
Posts: 2
Joined: Fri Dec 20, 2024 6:52 am

Feature Request: Bring Back the Hidden Custom Extension Support in AESCRYPT

Post by Joe Neo »

Subject: Feature Request: Bring Back the Custom Extension Support in AESCRYPT

Hey!

First off, mad props for the work you’ve done with AESCRYPT – seriously, it’s one of the best tools out there for keeping files safe, and I’ve been using it for ages. But hey, there’s something I gotta mention. There was this awesome feature in version 3.16 that seems to have been accidentally removed in the newer versions, and I think it should make a comeback.

In 3.16, there was this kinda hidden gem – the ability to encrypt any file and still keep the original extension. So, you could encrypt a [.mp4], [.jpg], [.docx] – whatever, and still make it look like a regular file. No forcing it to be [.aes], which is super obvious. It was like a ninja move for keeping your files encrypted but not raising suspicion.

Honestly, I think a lot of people didn’t even realize it was possible – it was kinda like a fluke, a cool little quirk of the old version that worked because of some unfinished code or something. But it was huge for privacy. You could just rename the encrypted file to anything you wanted and it would look completely normal. It felt like a cheat code for privacy, like hiding in plain sight.

Now, in the newer version, it’s all [.aes] again, and it pretty much kills that stealth factor. If you change the extension now, you can’t decrypt the file anymore. It’s a pain in the ass because you’re stuck with that [.aes] label, which is way too obvious. I really think this little feature should be brought back. Here’s why:
  • Total Flexibility: You could encrypt any file and give it any extension you wanted. It wasn’t just [.aes]. I could make a file look like a [.png], [.mp4], [.jpg], or whatever I wanted, while it was still encrypted. That extra flexibility made AESCRYPT way more versatile.
  • Stealth Mode: Activated – The best part was that nobody could tell it was encrypted. A [.jpg] or [.mp4] would look completely normal, and that was huge if you wanted to keep things private.
  • Privacy 101: When you’re dealing with important or sensitive files, you don’t want them to scream “hey, I’m encrypted!” With the original extension, your files just blended in with everything else. No one would know, and it made it a lot harder for someone to even try to flag your encrypted files. This feature was literally like a privacy weapon.
  • User-Friendliness: For non-tech users, this feature made AESCRYPT super easy to use. You didn’t need to be a pro to keep your files safe – just encrypt them and let them blend in with the rest of your files.
  • Unique Feature: This wasn’t just another regular feature – it was unique. It was the kind of thing that made AESCRYPT stand out from the pack. It was like having a secret weapon in your pocket for privacy. If there’s any chance this could come back, it would add that extra level of privacy and flexibility that made AESCRYPT so great.
To give you an idea of how this worked, here’s an example of how encryption was possible in version 3.16:

Code: Select all

#!/bin/bash

# Check if input file was provided
if [ -z "$1" ]; then
  echo "Error: No input file or directory specified."
  exit 1
fi

# Set new filename with a timestamp (using Screenshot or My_File)
new_filename="Screenshot_$(date +'%Y-%m-%d_%H_%M')"

# Create a zip archive of the input
zip -r "$new_filename.zip" "$1"

sleep 3
echo "\nSTARTING ENCRYPTION... ========================================="

# Ask for password
while true; do
    echo -n "Enter Pass:\n"
    stty -echo
    read password1
    stty echo

    echo -n "Confirm Pass:\n"
    stty -echo
    read password2
    stty echo

    # If passwords match, proceed
    if [ "$password1" = "$password2" ]; then
        epassword="$password1"
        break
    else
        echo "\nPasswords do not match. Please try again."
    fi
done

# Encrypt and output as a PNG file
aescrypt -e -p "$epassword" -o "./$new_filename.png" "./$new_filename.zip"

rm "./$new_filename.zip"

This was an example of how you could easily encrypt and then rename the file to any extension (like [.png]), while still keeping it secure.

Right now, though, with the latest version, I can’t do that anymore – I’m locked into using [.aes], and it’s pretty obvious when a file has that extension.

So, just a friendly ask: any chance this feature could be reconsidered and brought back? It was such a unique and helpful option that added a lot to the encryption process, and I’m sure it’d be a game-changer for a lot of users who need that extra layer of privacy.

Maybe you could implement it as a separate option, along with removing the requirement for the *.aes extension to decrypt those 'hidden' files? Or perhaps making the same option ignore input extensions altogether?

Thanks again for all the hard work – AESCRYPT has been incredible.

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

Re: Feature Request: Bring Back the Hidden Custom Extension Support in AESCRYPT

Post by paulej »

Thanks for the kind words! I truly appreciate it!

It should still be possible to create an encrypted file using a different extension. Perhaps I'm misunderstanding the issue.

For example, you can do this with a file named "financial_report.docx":

Code: Select all

aescrypt -e -p abc -o butterflies.mp3 financial_report.docx
That will produce the encrypted file as "butterflies.mp3".

Code: Select all

aescrypt -d -p abc -o real_file.docx butterflies.mp3
This will decrypt the file butterflies.mp3 file (actually an AES Crypt file) and write the output to "real_report.docx".

The GUI version lacks this flexibility and always has, but for good reason: simplicity is vitally important for GUI users. However, the CLI version has far more flexibility and more features. The CLI arguments may be in any order, too -- even the filenames can be placed anywhere on the line.

Perhaps there is something I failed to understand?
Joe Neo
Posts: 2
Joined: Fri Dec 20, 2024 6:52 am

Re: Feature Request: Bring Back the Hidden Custom Extension Support in AESCRYPT

Post by Joe Neo »

Hey, you're absolutely right, it works! I was using the old version for testing with a script that automated everything, and it didn’t seem to need the -o option. Not sure why the new version didn’t work for me, though — I kept getting warnings saying the file I was trying to decrypt didn’t have the .aes extension.

Anyway, it’s great to know you can still use AESCRYPT this way. Thanks for the fix, I updated my scripts and now everything’s working fine! Appreciate the help.

Take care and cheers!
CodeCracker-OSS
Posts: 2
Joined: Mon Jan 06, 2025 5:26 am

Re: Feature Request: Bring Back the Hidden Custom Extension Support in AESCRYPT

Post by CodeCracker-OSS »

Joe Neo wrote: Sat Jan 04, 2025 5:40 am Hey, you're absolutely right, it works! I was using the old version for testing with a script that automated everything, and it didn’t seem to need the -o option. Not sure why the new version didn’t work for me, though — I kept getting warnings saying the file I was trying to decrypt didn’t have the .aes extension.

Anyway, it’s great to know you can still use AESCRYPT this way. Thanks for the fix, I updated my scripts and now everything’s working fine! Appreciate the help.

Take care and cheers!
Do know that AESCrypt does not have plausible deniability, so it doesn't matter if it has an .aes extension or not, you can still see its encrypted with AESCrypt (because the header is not encrypted)

You can see the header in a hex editor like xxd on linux, or maybe even by opening it in a text editor.

One of my files states: aescrypt-cli v# CREATED_BY_AESCRYPT...
User avatar
paulej
Posts: 617
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Feature Request: Bring Back the Hidden Custom Extension Support in AESCRYPT

Post by paulej »

Indeed. While it could be possible to create files without such headers, it makes it more challenging to version the data streams, allow for flexible KDF or iteration choices, hashing functions, etc. More importantly, security isn't derived from obscuring the file name. I think that's your point.

However, there is value in being able to create files that do not end in .aes. I do that, myself, as a part of my server backup solution. It's not to hide the file type, but just a function of how I name archived files.
CodeCracker-OSS
Posts: 2
Joined: Mon Jan 06, 2025 5:26 am

Re: Feature Request: Bring Back the Hidden Custom Extension Support in AESCRYPT

Post by CodeCracker-OSS »

"security isn't derived from obscuring the file name"
Yes, that is all I was referring to, as it appears op is doing this with the belief of extra security, thought I would just point it out.

Tools like veracrypt have encrypted header which would offer that sort of Plausible deniability normally thought to be useful for legal situations, but actually not so much. I personally do not need it, and It appears to be out of scope for aescrypt's simplicity anyway.

As for the usefulness of not using the aes extension, only thing I could think of is making it hard to search for encrypted files specifically, but I haven't really thought much of this. I prefer it, to make it well-known to me that it is an aescrypt file :)
Post Reply