FAQ - Frequently Asked Questions
Yes, it does. Just be sure to download the 64-bit version of AxCrypt. The 32-bit
version will not install on 64-bit platform.
Yes, as far as we know. It has not been extensively tested yet on Windows 8, but
users have reported success. Please let us know if you have any issues.
Why do you need encryption? In two words: privacy and confidentiality.
As private persons, we nowadays store lots of information on our computers that
is not necessarily secret, but just simply private. Many of us also at times have
the need to use employer-owned computers and servers, as well as public servers,
to store such information. It might be copies of electronic invoices, private letters,
your CV etc.
In all these situations you might feel a little more comfortable knowing that regardless
of physical access to the files by network administrators, service personnel or
even other family members in your home network, your private information is still
kept private.
As employees we frequently are responsible for information that is sensitive in
various ways. It might be salaries if you're a manager, or customer data if you're
in sales or support etc. This information is kept in confidence by you, and you
have a responsibility to care for it as best you can.
In many cases it's not really enough to just store it on the corporate network server
and apply appropriate restrictive access permissions. The information and files
are still always available to support staff, network administrators etc. Even if
you trust your colleagues, as you should, mistakes do happen and sometimes it's
simply human to be curious. Anyone finding a file with his or her name on it will
be sorely tempted to sneak a peek...
Finally, there are an increasing number of cases where legislation and similar rules
come into play such as the FDA 21 Code of Federal Regulations Part 11; Electronic
Records; Electronic Signatures and the Health Insurance Portability and Accountability
Act, HIPAA, where encryption of confidential data is required under certain circumstances.
In these and similar situations encryption programs such as AxCrypt provide a secure
and convenient method to provide privacy and confidentiality as appropriate.
Because it endeavors to only use accepted practices and algorithms and does not
attempt to invent any new encryption algorithms or methods, and is Open Source.
Anyone may inspect the source code, check it for errors, omissions or back doors.
It's designed to run on Windows 2000/2003/XP/Vista/2008/7. Older versions ran on
Windows 95, 98 and ME, but since Microsoft has dropped all support for it and AxCrypt
required features from Windows 2000 and higher, AxCrypt also dropped support for
for these versions during 2008. Version 1.6.3 is the last version to support 98/ME/NT.
No version 1.x does not directly. However, some users have been successful in running
AxCrypt under Wine, the software which lets
you run Windows software on other operating systems.
Also, in November 2012, pre-release versions of AxCrypt 2.x are released, and they
are available via the downloads
page when you are logged on.
When you enter a passphrase, either when encrypting or decrypting, there is a checkbox
at the bottom of the dialog labeled with the text 'Remember this for decryption'.
AxCrypt maintains an in-memory cache of used passphrases - one to be used by default
for encryption, and as many as you like to be tried for decryption before prompting
you with a dialog. This cache is cleared every time the computer is restarted, or
a new user is logged on.
This feature makes the usage of AxCrypt much more convenient, and saves you from
the trouble of re-entering the passphrase every time.
But, you say, what's then the use of AxCrypt if anyone can walk up to my PC and
just double-click?
Under the heading Security, sub-heading
Local PC Security you will find a discussion about what is needed to protect
your PC locally, and why. The important thing for this discussion is: If anyone can
walk up to your PC and it's not protected by a password-protected screen-saver you
have no protection anyway! All that is needed for a would-be attacker is access
to a PC with for example a diskette or CD-drive, a USB-port or an Internet connection,
and it's a few seconds work to install a key-logger or a trojan. Do not trust a
PC that has been left unattended and unprotected.
The second reason for the passphrase cache is that if you do not need to enter it
every time, you may actually find it reasonable to use a longer and stronger passphrase
than otherwise, thus increasing security.
Of course, if you still don't like it, just uncheck the checkbox 'Remember this
for decryption'. It's 'sticky', so you'll just have to do it once. You can also
manually clear the passphrase cache from either the right-click context menu or
the Start-menu.
No, the official distribution does not intentionally contain anything that even
remotely can be called malicious. It is very unlikely to be infected by anything
unintentionally. Please read a lengthier
blog post for details why we can make that statement.
Short answer: You can't. Followup question: Why would you want to?
If you install AxCrypt, anyone with access to your computer can encrypt your files.
This is sometimes seen as a risk with installing AxCrypt. However, this is not the
case. The real risk is with '...anyone with access to your computer'. Anyone
who can access your computer and run an installed copy of AxCrypt, can also install
AxCrypt or any other encryption or deletion software. Anyone who can access your
computer can delete your files, and probably format your hard disk. Anyone with
physical access can also throw it out the window, steal it, use it as target practice
or any other activity that may prove detrimental to the health of your files.
The point is that it makes no sense to restrict access to AxCrypt - it's access
to the computer that needs to be restricted! That's why you should always use a
password protected screen saver and always have a password on your acccount. Because
then, if your files are encrypted with AxCrypt, your information will stay safe
even in the face of loss or theft your your computer or media with the files on.
AxCrypt is a file encryption program, for better or worse. There are some advantages
to encrypting single files, and some disadvantages. Other models for encryption
include folder encryption, virtual disk encryption and whole disk encryption. Each
has it's uses, but unfortunately the underlying technology is very different. Therefore,
it's not as easy as it may seem to for example support folder encryption with AxCrypt.
In fact, a folder encryption program is in many ways a very different program.
AxCrypt is intended for file encryption, and will likely stay that way. So, no,
it's not possible to encrypt a whole folder with AxCrypt. In some cases, a hybrid
approach is possible, where a zip archive is used to bundle files together, and
then that zip-file is encrypted with AxCrypt.
AxCrypt is accessed via the right-click context menu, under the heading 'AxCrypt'.
There is also a built-in encryption in some versions of Windows, which is accessed
in a similar way, but under the heading 'Properties', then the button 'Advanced'
and finally the check box 'Encrypt contents to secure data'. This encryption uses
a feature called
Encrypting File System, or EFS for short.
There are typically two reasons for getting 'Access Denied' messages. Both occur
when files are either moved to a new system, or Windows is (re)installed on an existing
system. One situation is a problem, the other is not.
If the file names in Windows Explorer are shown in
black text, then you're likely just having an NTFS ownership issue, and
this is easily remedied. Please Google for 'ntfs take ownership' (without the quotes)
to find suggested solutions.
If the file names in Windows explorer are shown in
green text, then you've inadvertently encrypted the file with EFS, and
may have a bigger problem. Possibly your files are lost. Please Google for 'efs
access denied' (without the quotes) for explanations and possible remedies.
EFS may in some cases be a useful feature, and can for some scenarios be a better
solution than AxCrypt. However... Beware: There be Dragons!
Because of the way EFS is implemented, it is also likely to be the single most common
cause of data loss in Windows-environments. If you're a computer security wizard,
and have a full understanding of X.509 encryption certificates, and how the Windows
Certificate Stores work and interact with user logon credentials, then you won't
have a problem as long as you're careful to ensure backups of the appropriate certificates
and keys. If, however, the previous sentence confuses you then you should probably
not be using EFS because of the mentioned risk of data loss when moving files to
a new system, or (re)installing Windows, or resetting passwords, or...
In November 2012 the first AxCrypt 2.x iOS app was released. At the time of writing,
no Android app is available, but it may change faster than this page is updated.
Head over to the beta download
page to see what is available.
AxCrypt 1.x is specifically targeted at Windows, and is not really possible to implement
on Android or iOS.
AxCrypt 2.x which is under development at the time of writing, is written in Mono-compatible
.NET C#. This means that it is possible to implement with reasonable effort on all
platforms supporting Mono, which includes Android and iOS. However, these device
environments are rather different from a desktop environment such as offered by
Windows or Linux, making it a more complicated issue than just moving the code to
the new platform. But it is possible with reasonable effort, it 'only' requires
a new user interface. Hopefully this will be made possible either by us, or by you.
If you are a developer with the skills to implement an app on Android or iOS based
on the Mono framework, and would like to contribute, please contact me!
AxCrypt is intended to show a menu named AxCrypt, with subsequent menu choices such
as 'Encrypt' and 'Decrypt' when you right-click a file. This is called 'Context
Menu' in Windows. If you don't see this menu, your first options should be to uninstall
AxCrypt, and then re-install. Always being sure to really reboot when asked to.
Don't take any shortcuts here!
If it doesn't work after re-installing, you may have a conflict with some other
program causing the AxCrypt menu not to be shown, and possibly others. A tool which
has proven useful is ShellExView
by Nir Sofer at NirSoft. Axantum is not affiliated with NirSoft in any way, and
cannot guarantee anything, but the tool has proven useful for other AxCrypt users
facing this kind of problem.
A program such as AxCrypt which installs menu choices in the right-click context
menu is called a Shell Extension. ShellExView will list all the extensions installed,
and give you the option to enable and disable each such extension which may make
it easier to find just which if any shell extension is stopping AxCrypt from showing
it's menu.
The short answer is that there's no reason for you to change it, and there's a risk
of making a mistake if you do. Please see my
blog post for a longer answer.
Nothing. They remain unchanged an encrypted. AxCrypt encryption is independent of
if the AxCrypt program is present or not. You still need AxCrypt plus the passphrase
to decrypt the files of course. It would not be very secure if all that was needed
to decrypt the files was to uninstall the program.
Any AxCrypt-encrypted files can be decrypted on any PC that has AxCrypt installed
or otherwise available, and if you have access to the passphrase and the key file
(if such was used to encrypt the files).
Should you wish to permanently stop using AxCrypt, you should decrypt all your encrypted
files before uninstalling. If you forget, or miss a few, it's not a big problem.
Just re-install, decrypt, and then un-install again. Do try to remember your passphrase
though!
The basic rule is: If you lose or forget your passphrase or key-file, your documents
are lost. There is no back-door into AxCrypt.
The only way to recover a lost passphrase is to try all likely combinations. If
you have used a key-file, and lost that, there is nothing to do at all - the number
of combinations is simply too large. That is why you must print a paper backup copy
if you use key-files.
All that being said, there is a special case where I could possibly help you. If
you think you know your passphrase, but not quite, or if it's less than 5 characters
long - then I can write and adapt a special program that will try many combinations
automatically. This is called a brute force attack.
AxCrypt is specifically engineered to counter brute force attacks, and does it rather
well, so this will only work when the number of combinations to try is very small,
let's say less than a million.
If you think you may be in a position where you can narrow down the possible combinations
enough for me, then there is a slight chance to recover the passphrase.
A brute force attack requires custom programming and many hours, days and possibly
weeks and months of computer time, thus I will only do this when compensated and
when I feel that that it might be possible. But it's always done on a no cure -
no pay basis, this means that if I can't find the passphrase, there's no fee. The
fee depends on the amount of programming necessary, typically it'll vary between
USD/EUR 50 to 250.
(I've attempted this four times so far, and succeeded once. The password was a word
with four letters, where the first letter turned out to be a 'y' instead of 'm'
as the user apparently had mistyped. That's the kind of situation where a brute
force attack may be successful.)
If your encrypted file is corrupt, you will get a message which in English is "File
damaged or manipulated, integrity checksum (HMAC) error." This messages
implies that the file is recognized by AxCrypt, and that you have entered the correct
passphrase and/or key-file, and there is hope!
Another message that may be seen is "The file does not appear to be produced
by AxCrypt. GUID mismatch." This indicates a severe error in the file
to the extent that it's not even recognized as an AxCrypt file. In most cases this
is because the file is simply not an AxCrypt encrypted file.
AxCrypt has some features for recovery of damaged files, but there are some limitations.
You must also be careful, and start by marking the original (damaged) file as read-only,
and then make a copy of it - and always only work on the copy!
- If you are not running the latest version of AxCrypt, start by upgrading and verifying
that the upgrade works as intended.
- Download and run the registry file AxCrypt-EnableTryBrokenFile.reg .
- Select the copy of the damaged file in Windows Explorer, right-click and select
AxCrypt | Copy Meta Info. Start Notepad, and do a 'Paste'. You should now have a
text-file with columns of data in it. Save this file - it may be useful for further
analysis if you need to contact Axantum Software. It contains the first 512 bytes
of the file, coded as hexadecimal data. This can be used to check the format of
the headers and possibly effect repairs.
- Select the copy of the damaged file in Windows Explorer, right-click and select
AxCrypt | Decrypt. Enter the passphrase and/or key-file and answer 'Yes' to confirmatory
questions that may appear.
- If you are lucky, you will now have a decrypted (but likely) still damaged copy
of your data. It's now up to you to use whatever tools you have available to repair
the file as much as possible. In most cases, you will lose some but perhaps not
all data.
- You can now restore normal functionality to AxCrypt by downloading and running the
registry file
AxCrypt-DisableTryBrokenFile.reg .
There are some limitations and factors to be aware of also.
- The way AxCrypt encrypts, means that in the best of case, a one bit error will cause
32 bytes (256 bits) of damage.
- AxCrypt includes optional automatic compression, which is invoked if it's deemed
worthwhile by the program, i.e. if the savings are enough to outweigh the extra
time. If the data was compressed before encryption and the file
gets damaged, you will probably lose at least 64K of data. In earlier versions you
may effectively not be able to recover any data because the decompression will never
get back in sync after an error. Later versions output sync blocks every 64K, at
a slight expense decreased compression ratio.
- Even if the attempt to decrypt the damaged file appears successful, there may not
be any recoverable data left, and it may also be the case that the original program
that created the file is incapable of working with damaged files, and you thus effectively
lose all anyway.
Your protection against data loss is regular backups. Please backup all your important
files - encrypted as well as unencrypted. AxCrypt is not intended to provide any
protection against data loss - only against disclosure and undetected manipulation.
Encryption protects your information from prying eyes and undetected modification
or corruption. It does not protect against destruction, willfully or by accident.
It bears repetition: Your protection against data loss is regular backups.
Technically it's not really possible to reliably protect your data against destruction
with software - except backup software. Of course, software can add safeguards that
make it harder to do it by mistake, or even maliciously but in the end you can't
protect against vandals that way.
If you are running Windows 2000, XP or later you should be using the NTFS file system
and let every user of the computer log on as a separate, restricted, user. No-one
should normally run as administrator. This will protect your files against
deletion by other users of the same computer, but it will not protect against
yourself - or any agent acting on your behalf. Please remember that viruses and
trojan intrusions will be acting as if on the behalf of the compromised user!
(Most worms will even be acting as if being an administrator!)
If your system is compromised by a virus or a trojan, your encrypted data will be
protected from theft - but not from destruction.
AxCrypt is not intended to protect against destruction, and there is to my knowledge
no such serious software available except for backup software. Any software claiming
to provide such protection should be examined carefully to understand exactly what
it is it protects against and how. Always backup your data regardless of other measures
taken.
If you represent a company thinking about using AxCrypt, you may be worried about
the case of an employee quitting and not telling the password to his files. The
question then is if you can set a password recovery policy?
If an employee quits, and refuses to give back company property your response should
be to report the person to the police for theft, and/or take other legal action.
This applies just as much to his laptop as the intellectual property owned by the
company which is stored on the laptop or the company servers.
There are enterprise encryption solutions that do implement functionality like this,
but the most common reason to use AxCrypt is because of it's simplicity to implement.
Enterprise solutions demand quite a bit of infrastructure, maintenance and can be
quite complex to install. Unfortunately, enterprise encryption solutions do not
really protect against disgruntled (ex-)employees anyway, although they do provide
protection against accidental key loss, and also facilitate key sharing once the
solution is in place.
So, AxCrypt is kept simple to use and deploy, at the cost of no key recovery. Data
loss concerns should be adressed via backup procedures of both keys and data, and
issues with employees leaving without divulging keys should be treated as any other
destructive or illegal behavior by such a person.
This indicates that you have somehow gotten a "mixed" installation, or
corrupted installation. AxCrypt has it's own integrity check based upon digital
signatures of all the executable files as well as the configuration files.
Please proceed to do as follows (the reboots are crucial):
- Uninstall. If the uninstall also fails, ignore and proceed to the next step.
- Reboot
- Delete C:\Program Files\Axon Data\ (if you're using the standard install location)
and all below. Do NOT right-click in Windows Explorer before doing this after reboot.
"Program Files" may be called something else if you're running a non-English
version of Windows.
- Reboot
- Verify that the folder mentioned above was deleted.
- Download the latest version and reinstall.
That should resolve your problem. Other possible causes are a damaged download of
the installer, and an active virus or similar in your system that modifies one or
all of AxCrypt files.
This is known to be caused by a problem with a program called
Eraser, version 5.x. Version 6.x does not appear to have this issue. When
Eraser is run to erase unused space and the 'Clear Cluster Tips' option is enabled,
Eraser apparently corrupts files in certain cases, and the AxCrypt file Messages.dll
is one of these cases. At the time of writing this, the behavior as such has been
verified, but the root cause of the problem in Eraser has not been determined. Version
5.x of Eraser will be phased out and replaced by version 6 or later and these versions
do not have the problem apparently.
You should upgrade Eraser to version 6 or later, and you should ensure that you
have AxCrypt 1.7 or later installed. The reason for using AxCrypt 1.7 is because
it uses a more robust installer technology and is easier to repair in the case of
corruption than version 1.6.4.4 or earlier. For instructions on how to uninstall
a corrupt installation of AxCrypt manually see above.
There is no such thing as HIPAA compliant encryption or software. Only organizations
and procedures can be HIPAA compliant.
The appropriate use of encryption and other Technical Safeguards is governed by
the HIPAA Security Standards, 45 CFR 160, 162 and 164. The relevant section is 164.312
Technical Safeguards. No recommendations or requirements concerning specific encryption
technologies are made there either, it's specifically pointed out that the regulation
is technology-neutral. It's up to each and every organization to evaluate it's position
and risks, and then implement required or addressable specifications.
Although the standard in no way refers to it except in comments, the CMS Internet
Security Policy, which is the current view of Centers for Medicare & Medicaid
Services for their own use, does specify some minimal technology levels for certain
cases. AxCrypt meets these requirements for transmission over the Internet - but
your organization must independently evaluate if is sufficient to use the same level
as the Centers for Medicare & Medicaid Services.
The parts where AxCrypt may (and should) suffice as (part of) a Technical Safeguard
are:
- Access Control/Encryption and Decryption - AES-128
- Integrity/Authentication - HMAC-SHA1-128 Transmission
- Security/Integrity Controls, Encryption AES-128/HMAC-SHA1-128
The HIPAA Security Standard does allow the use of encryption as the basis for Access
Control, that is to say to protect the privacy of data at rest (stored on a hard
disk as opposed to traversing the Internet for example). AxCrypt will meet most
organizations requirements here too.
Security is a chain only as strong as its weakest link. In your local system, there
are so many other ways to get at your data, that to sacrifice the convenience of
a secured passphrase cache just to 'feel' safer, was not thought to be a good idea.
You can always de-select the check-box 'remember this password'.
If you are concerned about physical access to your own computer there are other
measures you should take first. For special situations, there is a link installed
in the Start-menu called 'Clear and Unload from Memory' that you may invoke manually
or programatically.
128-bits is currently enough, and since AxCrypt is password based it's important
to realize that it's not reasonable to provide the full 128-bits
strength via the keyboard. AxCrypt will support 256 bits in the future,
but mostly in order to satisfy formal requirements rather than any real increase
in securty. The really important question is not 128, 256, 448, 2048 or millions
of key-bits - it's how they are used. In general, excessive amounts of key-bits
is a sign of snake oil. AxCrypt uses proven modes of operation, entropy collection
and random number generation as well as dynamic
key stretching and unique session keys for every encryption. See below for
details.
Seagate has published an interesting paper comparing and explaining the
difference between 128-bit and 256-bit encryption.
A key file is any file, where the content is used as an additional part of the passphrase
provided. AxCrypt can generate key files from the right-click context menu, and
will produce a short text-file long enough to really use the full strength of the
encryption algorithm, which is hard to do with just a manually entered password.
If you generate and use a key file, you must keep this secret, preferrably on a
USB memory stick or similar removable unit.
Whatever you do - do not encrypt the key file with itself! If you
do, all data encrypted with that key file is lost, unless you have a backup of the
key file. It is always recommended to print the key file on paper
and store that paper in a safe place.
On Tuesday, February 15 2005, Bruce Schneier
reported a cryptanalytic result stating that an algorithm producing collisions
in SHA-1 in less than brute-force time had been published. In common parlance -
SHA-1 was broken.
SHA-1 is one of the cryptographic primitives used by AxCrypt, along with AES-128.
Does the "breaking" of SHA-1 mean that AxCrypt is now insecure?
In short, no it does not for the following reasons:
- SHA-1 does not protect the privacy of data in AxCrypt, it only protects the integrity
and only as part of a keyed hashed message authentication code, a HMAC.
- The result does not in any way affect the use of SHA-1 as a preprocessing stage
for the passphrase. Your passphrase is just as secure or insecure as before.
The attack against SHA-1 makes it possible to produce collisions with less effort
than brute force, an effort of 2^69 instead of 2^80. However, since AxCrypt uses
SHA-1 as an internal function of a Message Authentication Code (MAC) not as a hash
function we're not worried about collisions, but forgeries. Since the HMAC includes
the use of a secret key, the collision resistance of the hash function used is of
no importance. You can find further detailed explanation
here for example.
The question breaks down to key lengths. The key length used is 128 bits - exhaustive
search is not currently believed to be an option, it's computationally infeasible
in cryptographic terms.
The problem lies with the passphrases used. This is the weak point.
Using purely random printable characters as your passphrase, you need to specify
twenty characters. Tough to remember though ;-)
Using English words, it's more difficult to say, but assuming there are 1 million
English words (an optimistic estimate to say the least), that would be equivalent
to 20 bits/word. Thus using only English words, you need to specify a sentence with
at least 6 words to even approach using the full 128-bit key length. In practice,
any normal sentence will consist of words from a much smaller subset of perhaps
10 000 words, equivalent to 13 bits. You then need at least 10 words...
So - the conclusion is: be verbose, be deliberately obtuse, and please mix in something
not part of natural language in your passphrases if you want to really use all security
the algorithm supplies. And don't use a famous citation, such as the declaration
of independence, or anything else likely to be found in a global literature, web
or news text archive search.
Your best bet is to use the passphrase generator
we provide. It'll give you strong but manageable passphrases for various situations.
The cryptological primitives are AES with 128-bit keys for encryption, and SHA-1
for hashes.
The real answer is much more complex, as there are many ways to use and combine
these basic primitives.
In the July 2003 issue of PC World magazine, there is a description of how to password
protect files using the built-in Windows Compressed Folders of Windows XP and ME.
This is a WinZip compatible extension of the Windows Shell (Windows Explorer).
The problem is that since it's WinZip-compatible it suffers from the same weakness
as does WinZip. WinZip (and thus Compressed Folders) password protected archives
use a proprietary and weak algorithm that is known to have the following weaknesses,
exploited in numerous 'Password Recovery' products and services:
- If the attacker knows the contents of one of the files in the archive, the password
is susceptible to a so-called known plain-text attack. AxCrypt is never susceptible
to this kind of attack.
- If the archive contains 5 or more files, password recovery (i.e. cracked protection)
is guaranteed. With AxCrypt you can have any number of files encrypted with the
same passphrase without affecting the security.
AxCrypt also supports numerous additional features such as convenient editing of
encrypted files - if a file is stored in a Compress Folder, you must manually extract
it, edit, and then drag and drop it back into the archive (you can view it inside
the archive without manual extraction, but not modify it).
A very convenient way to get the best of both worlds is to install the full WinZip-utility
and then AxCrypt your sensitive zipped archives. WinZip full-version also supports
strong encryption of individual files in the archives, but as WinZip is primarily
an archiver (the best in my opinion), and AxCrypt is fully focused on encryption
(the best in my opinion ;-), you get a nice best-of-breed application when you combine
the two.
Normally, AxCrypt files will display the .axx extension or not, depending on your
global Windows settings. This behavior may be changed by modifying the Windows registry.
AxCrypt does not implement any configuration settings to keep things simple, but
if you really want this, two registry files are included in the distribution to
make it easier for you.
They are named AxCrypt-HideAxxExtension.reg
and AxCrypt-ShowAxxExtension.reg
respectively, and are located in the AxCrypt 'etc' directory which usually is "C:\Program
Files\Axantum\AxCrypt\etc".
Product Activation in AxCrypt does nothing. More precisely, the GPL version is already
activated using a generic activation code.
The reason it’s there is to showcase the
technology as such, since it's rather advanced and is available for licensing
to OEM's. It uses a strong, but short, true digital signature based on elliptic
curves.
The default operation of AxCrypt when encrypting a plain-text file, is to store
the original files time-stamps inside the encrypted archive and to set the time-stamps
of the resulting encrypted file to the time of encryption. The rationale for this
behavior is as follows:
- Many backup and file-synchronization software programs depend on the modification
time of files to determine if it has been modified since the last run. This test
fails, if the encrypted file retains the original date of the plain-text file and
at worst the file does not get copied/backed up etc.
- Good encryption programs will take care to ensure that encrypting the same file
twice produces completely different encrypted files, to make it harder to determine
if the file is the same as another file, or another earlier version of a file. If
the time-stamp is retained, an attacker will get a high-precision time-stamp that
more or less uniquely identifies each and every file thus leaking what might be
important information about the file. (File size will remain the same, since the
encryption is deterministic, but this is a much weaker assertion).
- Semantically, an encryption is a transformation of the file, and this should be
reflected in the time-stamp. Note that the original plain-text time-stamps still
will be restored on decryption!
- If AxCrypt ever should support multi-file archives, there's no choice but to use
the time of encryption, otherwise it'll make it very inconsistent - which time-stamp
should a multi-file AxCrypt archive which happens to contain exactly one file use
(which by the way is the case today, the file format supports multiple encrypted
files, but AxCrypt has not implemented this functionality yet).
Should you still not be convinced, you can optionally enable AxCrypt to use the
time-stamp of the original plain-text file for the encrypted result. Change the
registry by setting HKEY_CURRENT_USER\Software\Axantum\AxCrypt\ DWORD KeepTimeStamp
to a non-zero value. You can check the Registry section for more detailed information.
File2File is a subset of AxCrypt, i.e. AxCrypt does all that File2File does, and
more.
|
|
AxCrypt 1.5 or later
|
File2File
|
|
Algorithm
|
AES
|
AES
|
|
Key length
|
128
|
? (128 likely)
|
|
Mode
|
CBC
|
CBC
|
|
Separate Key and Data Encrypting Keys
|
Yes
|
No
|
|
Secure Data Encrypting Key Wrapping
|
NIST AES Key Wrap
|
No
|
|
Open & Re-encrypt
|
Yes
|
No
|
|
Open Source
|
Yes
|
No
|
|
Documented Algorithms
|
Yes
|
No
|
|
Self-decrypting .exe
|
Yes
|
Yes
|
|
File Integrity check
|
HMAC-SHA1-128
|
No
|
|
Valid Key check
|
Yes
|
Yes
|
|
Command line
|
Yes
|
No
|
|
Secure key cache
|
Yes
|
No
|
|
Installer
|
Yes
|
Yes
|
|
Shell Extension
|
Yes
|
Yes
|
|
Stand alone program
|
Yes, Decrypt only
|
No
|
|
Integrated shredder
|
One pass PRN overwrite
|
No
|
|
Integrated compression
|
Yes, Zlib
|
No
|
|
Multi-file archives
|
No
|
No
|
|
Multi-file and folder selection
|
Yes
|
Yes
|
If you know of any features or functions that File2File has, but AxCrypt does
not, please let me know - I want the comparison table to be as objective as possible.
Passphrases are hashed with SHA-1 to 160 bits, whereof the most significant 128
bits are used as a Key Encrypting Key.
Using a Pseudo Random Number Generator specified in FIPS 186-2 operating on a 160-bit
Seed and a 160-bit Key with SHA-1, a 128-bit Master Data Encrypting Key is produced.
Header data and plain text data is encrypted with different derivations of the Master
Data Encrypting Key.
The PRNG Seed is a constant accumulating value, dependent on (the presumably secret)
user entered keys as well as a 256-byte entropy pool collected continuously through
mouse and windows movement, together with further entropy from the system timer
and time, as well as a free running bit counter, and the Pentium time stamp counter
if available. 128 bytes of the entropy pool are also saved persistently in the registry.
The data in the file consists of many header sections containing information about
the file size, file name and file modification times as well as version information,
integrity checksum etc. Where appropriate, these are kept encrypted under a separate
derived key.
The Key Encrypting Key is wrapped with the NIST AES Key Wrap Algorithm, with increased
round count to at least 10 000. The actual count is determined dynamically - faster
processor = higher count.
All data concerning the file, namely exact size, original name, file modification
and the actual data, is encrypted in Cipher Block Chaining mode with standard padding
under different subkey variants of the Master Data Encrypting Key, obtained by encrypting
non-secret constants with the Master Data Encrypting Key.
The Initialization Vector for CBC-mode (the same is used for all subkeys) is generated
with the same PRNG as above.
Before encryption, the data is compressed using the standard deflate algorithm from
RFC 1950 and RFC 1951, if it's determined to be beneficial.
For integrity checking, a RFC 2104 HMAC-SHA1-128, is created for all data (after
encryption) except the initial header containing the magic number GUID for file-type
id and the HMAC itself. Sometime in the distant future I may write a white-paper
describing the algorithms exactly in a more readable form than C++-code - which
is what you may look at currently for more details.
Wipe and Delete only overwrites once, with pseudo random data. I'm currently not
planning to implement DoD 5220.22 (NISPOM) sanitization, nor Gutmann 35-pass secure-wipe.
The cost of retrieving single-overwritten data is prohibitive as it is, if the attacker
has the resources for that (as well as getting physical access to the disk) there
are many easier and surer ways of getting at the data.
A PC is such an insecure and uncontrolled environment, that to use DoD-style wiping
in a running system is severe overkill and misleading. Such wiping should be used
prior to destruction or re-use of hard disks, and then only from a stand-alone diskette
and CD so that the entire disk surface may be wiped, regardless of operating system
structures. I recommend Boot and Nuke for this purpose.
The purpose of AxCrypt wiping is to protect from use of common un-delete tools,
not to protect from electron microscopy or special diagnostic hardware and software
available to hard disc manufacturers. Wiping 35 times also takes a lot of time...
If a file has the 'hidden' attribute, AxCrypt prior to 1.5 will not see it, and
thus not give you the choice of either encrypting or decrypting. Please upgrade!
Probably because you have missed something in the instructions included in the file
'HowToBuildAxCrypt.txt' which is included with the source code.
Notes for users of other versions than Visual Studio 2010
AxCrypt is distributed with Visual Studio 2010 project and solution files. Microsoft
in it's infinite wisdom apparently makes the decision to change the project and
solution formats for every release of Visual Studio.
We have not tried compiling under any other compiler than Visual Studio 2010 - your
mileage will vary.