Encryption - How much is enough, how much is too much?

You might expect me to say that everything should be encrypted to the hilt. Well, that would be overkill. No, the trick is finding the right level of encryption.

I have been asked in the past what would happen if someone came up with an unbreakable code. Would that be game over for Cryptanalysis? Well, I confess that I am not a specialist in crypto but I feel pretty secure in answering this one. No, it would not be game over because there are already unbreakable codes. One time pad codes are unbreakable without the message pad because all possible messages are equally possible – the same cypher text (encrypted version) could decrypt to “Move $1 million to account 43445342” or “I want to buy a painting of a goat” and there is no way to tell which from the cypher text. The way to attack those would be to try to recover the pad - the sequence of nonsense that was used to code the plain text into cypher. That could be a very private thing such as a sheet of rice paper held by only two people in the world and eaten before the attempt by a third party to decrypt the code was made. It could be very public such as letters from a book chosen at random – each day, you advance one page. One of my favourites one time pad codes is the Solitaire Cypher where the order of a pack of cards is used to cypher text. It isn't perfect because the pad repeats but it was a war time favourite because the equipment required was a pencil, a bit of paper and some ordinary playing cards. Shuffle the deck and the key is lost forever.

However, I digress. Popular codes used today are things like 3DES (sometimes pronounced Triple-DES) and AES 128 bit or 256 bit. 3DES is very big in the financial world and replaced single DES. Essentially, 3DES does what DES does 4 times, processing its own output. Are they unbreakable? Not quite. DES is fairly easy to break with the right kit. 3DES would just take longer and require more kit. AES256 would theoretically take many millions or even several billion years to crack with a single desktop system – although the 1.105 petaflop/s IBM supercomputer at Los Alamos National Laboratory might manage it a darn sight quicker. Even with that, the process would, on average, take thousands of years. Does your data need to be safe for that long?

That turns out to be one of the important questions. Imagine you are choosing encryption for a password that will be sent across the wire – and let us ignore the use of hashes for the moment. A password is valid for 1 week and then must be changed. The user can change their own password for 1 week after the old password expires. After that, the help desk have to do it. If the encryption is good enough to stand up for more than 2 weeks, then it is good enough. Making it tougher adds nothing. However, the location of a vault is unlikely to change for hundreds of years. That needs to be secret for a lot longer.

Another important question is how sensitive the data actually is. What I bought on Amazon in the last year? You can see that if you want. A trivial encryption such as ROT13 will do the job here. My interactions with my bank and my lawyer? That is more sensitive. 3DES at least. The launch code for ICBMs? Even if they change fairly often, I think that we should use a good strength cypher on those!

However, there is something about encryption that people often don't consider. It does more than hide information from prying eyes. Imagine that I am running a client that is having a conversation with a server. The request is going over the wire, perhaps via SSL, perhaps via some other scheme. I make a request and the request is coded with a shared secret key that we exchanged at the start of the session – and which is only valid for this session. I get a reply and it is junk until it is decrypted using the shared secret. There is nothing odd about that at all. Millions of systems work that way. So, what would happen if someone tried to hijack the session and inject a new request? Unless they have the shared secret, their request will be decoded into meaningless goo. Since the request probably contains an encrypted copy of some sort of sequence number, it would probably fail at the first hurdle. Knowing the shared secret is a big part of proving that I am still the client that I was at the start of the conversation.

How about if an attacker tries to replay a recording of the conversation without understanding it? The shared secret is generated per session. They have the wrong one so the replay would fail very early. A well designed protocol can protect pretty effectively against session hijacks but there are always people out there looking for even the narrowest gaps to exploit.

What are the downsides to encryption? Well, they are several. It takes time. If you are reading from a disk encrypted with BitLocker, each byte read from disk will cost you around 30 additional CPU cycles – and blow your processor cache and pipeline. Ok, that is not the end of the world but it is a cost. How about data loss though? Bob has excellent data security. All of his files are stored on a machine protected by Truecrypt, all of his mail goes via PGP and all of his ZIP files and documents have strong passwords. If Bob is a paragon of virtue then then risk is that he will be hit by a bus and that data will be lost. That could be very serious indeed. Of course, it might be that Bob is not a paragon of virtue in which case, how would anyone find out?

I recall that the police were not at all happy when BitLocker came out. Several of them at the F3 conference (First Forensic Forum) described it as a paedophile's best friend since it made offline forensics so hard to do. Encryption is a tool and like pretty much all tools, it is morally neutral. It protects good and bad people equally well. Some would argue that those who have nothing to hide need not keep secrets but I am not so sure. If I share my data with (for example) the government because it is not encrypted from them then I am relying on their ability to keep my data as safe as I have or better. Given their past performance on this, I think that I will encrypt it myself, thank you.

Signing off

Mark Long, Digital Looking Glass