Download

AES Crypt Wish List

There are thousands of users of AES Crypt and from time to time, we received requests for new features and capabilities. As free software, it is very challenging for us to add new features. Even so, we do make revisions as time permits. To this point, we have had 3 major releases of the software with minor bug fix releases in between.

This page exists to document the features that people request most frequently that we plan to implement as soon as time permits as a part of release 4.0 or perhaps an interim minor release. Of course, we would warmly welcome contributions from others in the open source community.

If you would like to submit items to be added to the wish list, please join the mailing list and propose your ideas!

  • Security Vulnerability: an attacker could change the modulo octet and artificially change the file size of the encrypted file by up to 15 octets. (Will be addressed in File Format Version 3, but be aware that the size of the encrypted file may be altered by an attacker who gains access to your .aes file(s). Encrypted data is NOT at risk of being exposed.)
  • Security Vulnerability: If one uses AES Crypt in automated processing where a part of the decrypted file is exposed as output to users who are not privileged to see the whole file, an attacker could launch an attack by modifying file version 1 or 2 such that it appears as a version 0 file that contains only the "session key". AES Crypt would decrypt that modified file, exposing the session key to the attacker so that they could access the entire file. (Will be addressed in File Format Version 3, but we STRONGLY recommend that you do not use AES Crypt as a part of automated processing that exposes ANY of the file contents to non-privileged people, as this could accidentally result in exposing sensitive information to such users.)
  • Bug: Typing "aescrypt -d -o input_file.aes" (forgetting to enter the actual output filename) will result in deletion of the input file
  • Behavior change: change the Linux code base to not attempt to open file for output before it successfully opens the file for input.
  • Support for AES encryption using different key lengths (e.g., 128, 192, 256 bits)
  • Ability to securely erase the original input file (when explicitly requested by the user)
  • Change the AESCryptWorkerThreads::ProcessFiles() routine to create a copy of the file_list for use in the DLL so that the calling routine can free the file list immediately and the DLL (and thread) will have its own local copy. This avoids issues on Windows where some modules use "Multithreaded DLL" and some use "Multithreaded" (i.e., there are two different C runtime libraries and separate heaps)
  • On Linux, use the same umask for the output file as the input file (note: the authors are not favorable to this idea for security reasons)
  • Use the same timestamp on the output file as the input file
  • Rename the Linux package to a form like aescrypt-3.0.5.tar.gz (Linux package naming conventions)
  • Include the man page in the Linux distribution (presently only in the Apple console distribution)
  • Get rid of all GNU code so that the license terms are friendlier for commercial products that want to incorporate AES Crypt
  • The Windows code will report the error "invalid signature" to indicate that the file format is not recognized. Change the error to "Invalid AES Crypt file"
  • This causes a segmentation fault: "$ touch tmp; aescrypt -d tmp". The reason is that the filename length is not checked and an assumption is made that the file ends in .aes.