Security

Why is AxCrypt secure?

AxCrypt is secure because it endeavors to only use accepted practices and algorithms and does not attempt to invent any new encryption algorithms or methods. It’s also open source; Anyone may inspect the source code, check it for errors, omissions or back doors. It has been used and inspected for vulnerabilities for over 15 years and tried by more than 30 million users, without any known weaknesses.

How secure is AxCrypt?

This question breaks down to effective encryption key lengths. The key length used is 128 or 256 bits – exhaustive search is not currently believed to be an option in either case and it is computationally infeasible in cryptographic terms. The problem lies with the passwords used – this is the weak point. You can read more about what to consider when choosing a password below.

Password considerations

AxCrypt uses AES-128 or AES-256 in the Premium version – but if you want to achieve that level of security you must give it 128 or 256 bits of truly ‘random’ data. This is very hard to do, but the easiest way to even approach this is to use the password generator included in Premium.

To actually get 128 or 256 bits, you’ll in practice have to save this password in a text file, and then keep that text file very secret.Using typical English language in a password, 128 bits is approximately equivalent to 10 ‘random’ words, and 256 bits thus twice this. Do not use meaningful sentences and absolutely not famous or even obscure quotations!By introducing variations on the case, as well as non-alphabetic characters you can reduce the number of words necessary. It’s not recommended to use less than 5 words. If you use a completely random selection of upper and lower-case letters and digits, you need 22 characters to achieve 128 bits security, and thus 44 characters for 256 bits. (The above is a slight simplification of the issue, but it should serve.)The shredding, or wiping, feature of AxCrypt allows you to erase files in a way that makes it impossible to recover the contents with undeletion software. However, there are some caveats:

• The name of the file, as well as the size, may be recovered.

• If the file has been viewed or edited with an application that creates temporary copies of the content (such as Microsoft Office), those temporary copies may still be available for undeletion on your hard disk.

See the section on local PC security for tips on how to increase your security margin for these matters.

Local PC Security

AxCrypt by itself will not protect your local PC from, for example:

Data exposure due to:

• Your applications maintaining clear text in memory, which subsequently is placed in the paging file.

• Your applications creating temporary files, which are not properly wiped.

• Deep reading of overwritten hard-disk data with custom software and laboratory equipment.

Password exposure due to:

• Untimely power cycling of your computer and subsequent cryptanalysis.

• Keyboard-sniffers, either in hardware or software.

Neglect to use:

• Strong passwords, either with AxCrypt or your sign in.

• Password-protected screen savers.

Account Keys

An account key is what enables the implementation of various new rich features, such as allowing other team members to open secured files with their own passwords. In technical terms, an AxCrypt Account key consists of a public key pair composed of a public (non-secret) and a private (secret) part and some other meta data.

The account key is always kept secured with your password as well, although one part of it is not secret and is used when securing files for you and your team. For you, the benefit is that you can change the password for all files in one single operation. For your team members, the benefit is that you and your team can allow each other to open secured files without sharing passwords by just specifying the email address of the other member.

Anyone can use your email address to allow you to open a secured file with your own passphrase, and you can allow anyone with an email address to open a file secured by you. All this is enabled by the public part of the account key being available on our server.

Algorithms

The cryptological primitives are AES-128 or AES-256 for bulk encryption, PBKDF2 with HMAC-512 for key deriviation, 4096-bit RSA for the account key, and HMAC-512 for integrity checking.

The algorithms used are deemed secure as such, to the best of our knowledge, by the US Government and the Internet community. Please see the documents package and the source code for details.

Key wrapping of the password is done using the NIST specification for AES Key Wrap. The key derived from the password with PBKDF2-SHA512 is only used as a key encrypting key.

As a brute force counter measure, key wrapping is done with at least 5 000 iterations, increasing the work effort with approximately 12 bits. The actual iteration count is determined dynamically, a typical value is 25 000 to 100 000, adding 14-17 bits of effective key-length. The faster machine you install AxCrypt on – the better the security!

AxCrypt uses the Advanced Encryption Standard with 128-bit or 256-bit keys in Counter mode with a ‘random’ IV for the data encryption.

For integrity verification AxCrypt uses HMAC-SHA512, i.e. Hash Message Authentication Code using SHA-512 with 512-bit output.

The pseudo random number generator (PRNG) used is primarily the operating system provided one, in some cases with added entropy added.

There may well be bugs in our implementation though – that is why it’s open source, so you and our peers may review it and keep it safe. This should not be taken as a low level of confidence in our code – anyone who tells you their code is flawless is either inexperienced or lying.

Is AxCrypt HIPAA compliant?

There is no such thing as HIPAA compliant 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 its 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/AES-256

• Integrity/Authentication – HMAC-SHA-512 Transmission

• Security/Integrity Controls, Encryption AES-128/AES-256/HMAC-SHA-512

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.