Perfect Encryption II

Posted by Janey Hawkins (Lead Security Architect), 2 Sep 2011
In my last blog post, we saw that perfect encryption exists, and is actually quite simple. I demonstrated an encryption algorithm for which it's literally impossible to obtain the original plaintext without knowing the encryption key. In that case, the job of the code cracker is not just very difficult - it's impossible.
So why don't products like our own Conseal USB, which are known for their extremely high security, use this ultimate encryption algorithm?

The answer is that all perfect encryption algorithms have a massive flaw which impacts both their security, and their viability for everyday use.

In my last post, I gave the following example:
Plain text: AARDVARK
Encrypted: CIAWCULR

To demonstrate the flaw in this algorithm, think about the answer to this question: how long would the key have to be in order to encrypt the whole works of Shakespeare?

The answer is, you'd need a key as long as the whole works of Shakespeare. And that is the whole problem. To encrypt, say, a 500GB hard disk you'd need to use a password which was 670 billion characters in length. That would take an experienced typist about 5000 years to type in!

That is pretty clearly a bit of an issue.

Is there a solution to it? Well, perhaps. There are two which are potentially viable:

1. Carry the password on a separate disk.
This is certainly a possibility. Rather than having the user type in a password, they could enter a second hard disk which contains the key.

This causes a number of problems itself. From a cryptographic point of view, we have a problem when re-writing sectors of the disk. It comes from the fact that if you know the plaintext and cyphertext for a certain sector, you can derive the part of the encryption key which affects that sector. This means that if an attacker got hold of the plaintext content of a file, and knew where on disk it was stored, they could decrypt any file subsequently stored there. A pretty big flaw! This is possible, too, without any particular intelligence gathering: a lot of hard disks contain much the same content - it is fairly possible to guess what lies where in, for example, a standard install of Windows.

If you tried to work around this by changing the encryption key for the sector every time that the sector is overwritten, you'd have to find some way of letting other keyholders hear about the change. It's not viable to decide beforehand on what the encryption key is going to be after a rewrite, because that multiplies the size of the key. For example if you wanted to account for just 20 rewrites per sector (a very small number), the pass key for a 500GB drive would have to be 10 terabytes long!

Even if this were used in a situation where that kind of storage requirement were not an issue, it would still mean that the key would need to be stored on a separate drive which in practice would end up being stored close to the protected drive!

2. Use a smaller key to generate the large key
This is certainly possible, but it seriously compromises the security of the algorithm. It would no longer be perfect - by a long way - because the encryption key for every sector is inextricably linked to that of others. So knowing the plaintext for certain sectors could tell you the plaintext for others. And by knowing the plaintext of just a few sectors, you could decrypt the whole disk. (It's said to be vulnerable to a "known-plaintext" attack.)

It turns out that these flaws are just too great for the method to be relied upon in general usage. In general, AES - the current king of encryption algorithms - is still by far the most secure.


Post a Comment