FAQ - Frequently Asked Questions
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 is Open
Source. Anyone may inspect the source code, check it for errors, omissions or back
doors.
It's designed to run on Windows 98/ME/NT/2000/XP/2003. Older versions ran on Windows
95, but since Microsoft has dropped all support for it and AxCrypt required features
from Windows 98 and higher, AxCrypt also dropped support for Windows 95 during 2004.
Although not designed or formally validated on Vista, it appears to work well there
too.
No, it does not. It may in the future, and is designed with that in mind.
Yes, it does. However, there has been reports of installation failures (AxCrypt
-p returns -1073741819) when installing from a different drive than C:.
Yes, it does. However, the Shell Extension (the right-click menu) is a 32-bit component
and requires that it run under the
32-bit shell that is available in Windows x64.
No, not directly it does not. However, some users have been successful in running
AxCrypt under Wine, the Windows emulator.
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.
The basic rule is: If you loose 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.
- Locate the program folder where AxCrypt is installed, normally 'C:\Program Files\Axon
Data\AxCrypt'.
- In a sub-folder named 'etc', there is a file named 'AxCrypt-EnableTryBrokenFile.reg'.
Double-click this file, and answer 'Yes' to the question if you'd like to install
this in the registry.
- 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 loose some but perhaps not
all data.
- You can now restore normal functionality to AxCrypt by double-clicking 'AxCrypt-DisableTryBrokenFile.reg'
in the 'etc' program folder.
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 loose 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 NT 4, 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.
Why do I get
"Error loading signature XML" and how do I fix it?
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.
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 it's not reasonable to provide the full 128-bits
anyway using a conventional passphrase. In the future, when AxCrypt supports a hardware
token and/or RSA-based key encryption, it will support 256-bits. 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 work factor increasing key wrapping and individual unique encryption
keys for every encryption. See below for details.
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.
At the utmost worst, the current result implies that an attacker with knowledge
of your passphrase would be able to corrupt your encrypted data with a work effort
of 2^69 instead of 2^80, and the built-in integrity check would fail. This is bad
enough, and I'm sure will see that 2^69 shrink in the coming months and years, but
it's not a cause for immediate concern. 2^69 operations are still quite a bit of
work, and please note the caveat that the attacker will have to know your secret
passphrase to effect the attack.
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.
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\Axon Data\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\Axon Data\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!
For versions prior to 1.5.2: Ensure that you are using Visual Studio 6 and have
the latest service pack (at least sp5 - if you get error C2440 you need this), also
ensure that you have the latest
Microsoft Platform SDK (the one that comes with Visual Studio 6 is dated
and does not work with AxCrypt - you may receive errors about undefined symbols
and also errors in templates used for safe Handle-handling in AxCrypt).
Ensure that you are using Visual Studio 2003 or later, and have the latest
Microsoft Platform SDK installed. If you install it from the Visual Studio
distribution, all should be fine.
The following are typical errors when the Platform SDK is not properly installed:
- LINK : fatal error LNK1104: cannot open file '.\Debug\AxCryptM.res'
- fatal error C1083: Cannot open include file: 'AxCryptM.h': No such file or directory
- Any compiler errors about Messages.res or Messages.lib not being found.
- *.res : warning LNK4221: no public symbols found; archive member will be inaccessible
When installing the Platform SDK, remember to modify the Visual Studio directory
search order, add these SDK paths to the top of the lists:
- Tools -> Options -> Projects -> VC++ Directories -> Executable files
typically: C:\Program Files\Microsoft SDK\Bin
- Tools -> Options -> Projects -> VC++ Directories -> Include files
typically: C:\Program Files\Microsoft SDK\include
- Tools -> Options -> Projects -> VC++ Directories -> Library files
typically: C:\Program Files\Microsoft SDK\Lib
When you load the solution you may get a message stating that it can't find the
files for project "AxCrypt2Go" - this is to be expected, since that is
a work in progress for which the source code has not yet been release. Just ignore
this.
If you get the following error:
------ Build started: Project: Setup, Configuration: Release Win32 ------
Performing Custom Build Step
The system cannot find the path specified.
Project : error PRJ0019: A tool returned an error code from "Performing Custom
Build Step"
The most likely reason is that you have not installed NSIS. Get it at
http://nsis.sourceforge.net . AxCrypt is currently using NSIS 2.0.3 - your
mileage may vary with older or newer versions. We've not tried it...
Do not try to build component files such as Setup.nsh, stick to the projects mainly
'Setup' and 'AxCrypt'.
Notes for Visual Studio .NET 2002/2005 users
AxCrypt is distributed with Visual Studio .NET 2003 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 .NET 2003
- your mileage will vary.