Passwords are convenient. They may be so easy to remember that we don't need to write them down. They are also easy to crack as well. Passphrases, in general, are better because they are likely to be longer and may include more than just alpha-numeric characters. A whole lot of either and we may wish we had a better memory.

From a security view, better still is a password with random characters. Chances are though we are not going to remember them.

NIST have a formula for random characters: Entropy = log²(n^k) where log² denotes log to base 2, n is the number of available characters and k is the password length. The greater the entropy the more secure the password.

The formula clearly shows that the entropy increases as both n and k increase. This confirms that, in general, passphrases are better than passwords.

With a character set of lower/upper case and 0 to 9 we have, for 16 characters chosen at random, an entropy of 95.3 Alternatively, with a standard 94 character keyboard and 16 characters chosen at random we have an entropy of 104.9.

For a character set comprising the values 0 to 255, 16 characters chosen at random gives an entropy of 128.

In the latter case, we don't need the formula. Here we have the maximum possible entropy per byte, ie 8 bits, so the entropy is simpy 8 x 16 = 128.

A random binary string, or binary key, then gives the maximum entropy for a given password length.

Not surprisingly, many encryption applications have a key input as a hexadecimal string.

Few of us, if any, will be able to remember binary strings even when represented as hexadecimal. We are bound then to save them somewhere.

We could have the most sophisticated method to ensure that our keys are safe. By 'We' I mean the sender of the encrypted file. The object may be defeated if the recipient has the key stuck on the front of their monitor. I've never seen anyone mention this. Perhaps it is supposed to go without saying. Problem is that the sender cannot be 100% sure that this is the case.

Another method of employing a binary key is via a key file. Here, a file is hashed by a secure hash algorithm and the resulting hash value is used as the key. This method is used by TrueCrypt and KeePass to mention just two applications. This author's HashFile also employs this method. We have then a resulting binary key which does not have to be saved - we only have to remember the key file used. An image from \My Documents\My Pictures is handy as browsing with an open file dialog shows the thumbnails.

I haven't seen a criticism of this method but there may be one. My C: drive has just over 100,000 files. 100,000 may be represented as 2^16.6. This is tiny when compared with a 128 bit key giving 2^128 combinations. Of course, we are not talking about 2^16.6 keys but 2^16.6 hashes and the bigger the key file the longer to calculate the hash value.

However, it is a point even if the key files were on other media.

Suppose, instead of one key file we chose two. If the order is important then we must consider permutations. The formula for permutations is n!/(n - k)! where ! is factorial, n is the number of objects and k is the permutation size.

For k = 2 the formula reduces to n!/(n-2)! = n x (n-1). If we allow the same file to be chosen twice then this adds a further n resulting in a total of n^2.

So, by choosing two files we don't double the security, we square it. Our 100,000 files now gives 10 billion pairs and, therefore, 20 billion hashes.

What have I opted for then? None. It is left up to the user of PassKey.

Passkey will accept the following, ordered by security level.

One key file.

Two key files.

A binary key.

A binary key plus one key file.

A binary key plus two key files.

The level is debatable since it could be argued that a saved binary key may not be as secure as remembering two key files or even one.

If a binary key is used it will be hashed. This ensures that short or long keys, short or long relative to the chosen bit level required of the output key, are equal to the chosen bit level of the output key.

To keep things simple the hash algorithm used is SHA512 and clipped according to the bit level of the output key. Thanks to Greg Turgeon for his SHA512 implementation.

The bit level of the output key may be 128, 160, 192, 256 or 512. Of course, we can have others simply by further clipping by hand.

A cancelled key file browse will empty that key file, if it wasn't already empty.

Here is PassKey on opening:

There are no defaults, no drag and drop for the Input key, no obscuring and no indication of the key files chosen.

If you have any comments then let them rip.

PassKey is attached - zipped as a folder. No help file - that is why I've rambled above.

From a security view, better still is a password with random characters. Chances are though we are not going to remember them.

NIST have a formula for random characters: Entropy = log²(n^k) where log² denotes log to base 2, n is the number of available characters and k is the password length. The greater the entropy the more secure the password.

The formula clearly shows that the entropy increases as both n and k increase. This confirms that, in general, passphrases are better than passwords.

With a character set of lower/upper case and 0 to 9 we have, for 16 characters chosen at random, an entropy of 95.3 Alternatively, with a standard 94 character keyboard and 16 characters chosen at random we have an entropy of 104.9.

For a character set comprising the values 0 to 255, 16 characters chosen at random gives an entropy of 128.

In the latter case, we don't need the formula. Here we have the maximum possible entropy per byte, ie 8 bits, so the entropy is simpy 8 x 16 = 128.

A random binary string, or binary key, then gives the maximum entropy for a given password length.

Not surprisingly, many encryption applications have a key input as a hexadecimal string.

Few of us, if any, will be able to remember binary strings even when represented as hexadecimal. We are bound then to save them somewhere.

We could have the most sophisticated method to ensure that our keys are safe. By 'We' I mean the sender of the encrypted file. The object may be defeated if the recipient has the key stuck on the front of their monitor. I've never seen anyone mention this. Perhaps it is supposed to go without saying. Problem is that the sender cannot be 100% sure that this is the case.

Another method of employing a binary key is via a key file. Here, a file is hashed by a secure hash algorithm and the resulting hash value is used as the key. This method is used by TrueCrypt and KeePass to mention just two applications. This author's HashFile also employs this method. We have then a resulting binary key which does not have to be saved - we only have to remember the key file used. An image from \My Documents\My Pictures is handy as browsing with an open file dialog shows the thumbnails.

I haven't seen a criticism of this method but there may be one. My C: drive has just over 100,000 files. 100,000 may be represented as 2^16.6. This is tiny when compared with a 128 bit key giving 2^128 combinations. Of course, we are not talking about 2^16.6 keys but 2^16.6 hashes and the bigger the key file the longer to calculate the hash value.

However, it is a point even if the key files were on other media.

Suppose, instead of one key file we chose two. If the order is important then we must consider permutations. The formula for permutations is n!/(n - k)! where ! is factorial, n is the number of objects and k is the permutation size.

For k = 2 the formula reduces to n!/(n-2)! = n x (n-1). If we allow the same file to be chosen twice then this adds a further n resulting in a total of n^2.

So, by choosing two files we don't double the security, we square it. Our 100,000 files now gives 10 billion pairs and, therefore, 20 billion hashes.

What have I opted for then? None. It is left up to the user of PassKey.

Passkey will accept the following, ordered by security level.

One key file.

Two key files.

A binary key.

A binary key plus one key file.

A binary key plus two key files.

The level is debatable since it could be argued that a saved binary key may not be as secure as remembering two key files or even one.

If a binary key is used it will be hashed. This ensures that short or long keys, short or long relative to the chosen bit level required of the output key, are equal to the chosen bit level of the output key.

To keep things simple the hash algorithm used is SHA512 and clipped according to the bit level of the output key. Thanks to Greg Turgeon for his SHA512 implementation.

The bit level of the output key may be 128, 160, 192, 256 or 512. Of course, we can have others simply by further clipping by hand.

A cancelled key file browse will empty that key file, if it wasn't already empty.

Here is PassKey on opening:

There are no defaults, no drag and drop for the Input key, no obscuring and no indication of the key files chosen.

If you have any comments then let them rip.

PassKey is attached - zipped as a folder. No help file - that is why I've rambled above.

## Comment