Security pitfall: Reverse DNS lookups

Posted by Tom Colvin (CTO), 12 Dec 2011
Why it's important to confirm the results of a reverse DNS lookup by performing a forward lookup.

Many web applications have the facility to limit services based on domain name. Conseal for example can prevent access to a USB device by users outside of a given domain.

In general a user's domain name is obtained by performing a reverse DNS lookup on the client's IP address. This is a very simple case of asking the DNS server associated with the IP for its associated hostname. This can return, for example, The domain name is then obtained from the latter part of this (ie,

However, relying on this information is naïve. More importantly it breaks the first principle of security: know where your information is coming from. Reverse DNS information comes from the IP address' owner, and is entirely separate from the domain information. It is not authoritative, and does not guarantee that a user is part of the domain they claim to be.

So for example my broadband provider allows me to set my own reverse DNS address. I could easily set it to, say, in order to pass myself off as a Microsoft employee.

What is the solution?
The solution is simply to check the results of every reverse lookup by performing a forward lookup. For example, if a reverse lookup on a user's IP gives, then this must be confirmed by looking up If this does not give the user's original IP address as one of the return values (forward lookups can return more than one address) then it simply should not be trusted.

You would be surprised how often developers fall into this trap - and it is so easy for hackers to exploit.

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.

Perfect Encryption I

Posted by Janey Hawkins (Lead Security Architect), 11 Jul 2011

Our current encryption algorithm of choice, AES, is extremely secure: to mount a brute force attack would take so much time that it is not even remotely possible. Even a billion supercomputers running for a billion times the age of the universe would not get anywhere near to cracking it. But mathematically speaking, a brute force attack is possible: there are a finite number of keys to try (2^256 in the case of AES 256-bit), and an algorithm which simply tried every one in turn would be certain to pick the correct one at some point.

So what if there were an encryption scheme for which we could prove any amount of crunching about would never get you any closer to the solution? In other words, one for which there is nothing you can do - literally nothing - if you lose the key. This would be a perfect encryption system.

The most interesting thing about perfect encryption is its existence. There really exists a scheme which is that secure. And it's really simple. AND it's mentioned in the James Bond books.

Imagine an encryption key which was exactly as long as the data. To pick a pretty simple mechanism for demonstration, let's say: give every letter a number: A=0, B=1, C=2, etc. Then letters can be added and if you get to 26, loop back round to 0.
So: B+A=B

Now we have a mechanism for taking plain-text data and encrypting it. Take a key which is as long as the data and just add it to the plain text.

Plain text: AARDVARK
Encrypted: CIAWCULR

Now the clever bit. Given that the key is totally random, there is no way to determine it from the encrypted text. By 'no way', I mean there is literally no way at all: there is no processing that you can do to find either the key or the plain text given the cypher text.

Put it another way: say you have the the encrypted text CIAWCULR. The key could be VEXQYNXL, giving the plain-text HEDGEHOG; or KINTGMJK, giving the plain-text SANDWICH. In fact it could be literally any 8 letter combination, and there is no way of figuring out which one.

This forms the basis of what is known as a one-time pad. A one-time pad is essentially just a long list of random digits shared between two parties. For one party to send a message to the other, they encrypt the message using some of the random digits, which are then discarded. The receiver uses his copy of the random pad to decrypt the data.

So why don't we use this principle of genuinely unbreakable encryption to secure all our data? Answer next time.



Posted by Tom Colvin (CTO), 25 Jun 2011

A quick post to let you loyal readers know that our competition is open! Our prize draw could land you with one of 25 prizes, including £50 Amazon vouchers or free licenses of Conseal USB. All you need to do is answer a few very quick questions on your experience of USB drives and security.

Of course, if you have any comments, questions or suggestions for Conseal itself, please contact us the usual way: we're here to assist how ever we can.


How To Break Unbreakable AES Encryption

Posted by Alf Norris (Conseal USB Lead Developer), 1 May 2011

The power of 256-bit AES encryption is awesome. To explain just how powerful it is takes numbers far larger than can really make sense to our brains... but it's worth a try.

The "256-bit" part of the name means that the key which provides access to the protected content is 256 bits in length - that is, it is one of 2256 possible combinations.

So imagine you have a a file encrypted using 256-bit AES, and that you can sit just trying combinations to crack it open.

Let's pick a crazy-high number: say you can try a million million million combinations every millisecond. At that rate, it would take about 3 million million million million million million million million years to try every combination. That's older than your grandma; even older than Bruce Forsyth.

It's more combinations than there are atoms on the whole planet. About 70,000,000,000,000,000,000,000,000 times more to be precise.

For it to take "only" as long as the age of the universe to crack, you'd need to type in about 2.8 x 1059 combinations per second - that's 280,000 with 9 "millions" after it.

That's why AES is considered, for now, an unbeatable encryption. The NSA have approved it to protect information classified as "top secret" - and that is genuinely the top endorsement possible.

...To which the obvious response is: Unbeatable! Well that sounds like a challenge!

How can it be beaten? As we've seen, trying to get the encryption key by brute force is not clever. But can we get hold of it some other way? Surprisingly, this might not be so difficult.

Take a normal encrypted disk: you provide a password and the disk unlocks. Inside, this works in one of two ways:

  1. The encryption key is based on the password itself. So for example it could be the SHA-256 hash of the password, or any other way of mashing it around to generate a 256-bit number.
  2. The password you enter is used to release the encryption key. Note (and this is important) that this means the encryption key is stored on the disk.
    Releasing the encryption key almost always works by the password itself being an encryption key which secures the actual key we're interested in.

In both of the above two cases, the password is the weak link. It no longer matters that we're using super-strength 256-bit AES encryption: just figure out the password and you've got the data.

In other words, we've reduced the complexity of the task from "decrypt 256-bit AES" to "crack a password".

As Tom has demonstrated previously, cracking a password is not always difficult, so long as you have the hash to compare it against (or you can do some processing to tell you whether it's the right password or not. Figuring out what processing is out of the scope of this post, but it need not be too complex).

So here's how to break unbreakable 256-bit encryption, on an encrypted disk:

  1. Get the hash of the password used to lock the disk (or figure out what processing you need to do)
  2. Run a dictionary attack against the hash to see if it's a known one.
  3. If not, try combinations one-by-one in an intelligent order, as the entropy of human-chosen passwords is low
  4. Use the password to get the encryption key
  5. Decrypt the disk's contents

...and that's it!

Don't actually do this of course, it's illegal.


How Random.

Posted by Tom Colvin (CTO), 5 Mar 2011

Computers aren't very good at being random. They're machines built entirely on rules, with no free choice. How can you tell them to pick something randomly?

They end up, in fact, producing only "random-ish" numbers - they look random, but are essentially predictable.

Humans are, by nature, much better at being random. We do completely weird unpredictable things. A lot of people exclusively do completely weird unpredictable things.

Which is why, at least from this perspective, the results of a NIST study on password security may be a little surprising. Their study is worth reading (or forcing your administrators to read). In a nutshell, it describes how much easier human-chosen passwords are to guess than machine-chosen passwords.

It describes the entropy of different types of passwords. Entropy, in this case, is a measure of how random the password is: a password of E "bits of Entropy" can be guessed in 2E trials. Or: the lower the entropy of the password, the faster it can be guessed.

And the really interesting bit is just how much difference there is in the entropy of computer-generated versus human-chosen passwords.

Take for example an 8-character password, chosen from upper case and lower case letters, numbers, and any one of 30 symbols. That gives a choice of 94 symbols for each of the 8 characters, or 948 different possible combinations. If it were truly random, it would therefore need 948 different trials to guess it, because any choice is as likely as any other. (948 is about 252.7, so we say it has 52.7 bits of entropy.)

But if the user were to choose a password themselves, some choices are more likely than others. For example a lot of passwords are based on dictionary words, and we can then analyse different letter combinations to gauge what is more likely. In English, the most common starting letter is 'T' and if the word starts with a consonant then it's likely that the next letter is a vowel.

Naturally one man has spent his career analysing all such patterns, and we derive an estimate of the entropy of human-chosen passwords from this. For an 8 character password chosen from an "alphabet" of 94 characters, there are just 18 bits of entropy. That is to say, you'll most likely guess the password within 218 attempts.

That result is astonishing. An 8-character random computer-generated password is 23 thousand million times harder to guess than a human-chosen one!

So how long would it actually take to guess the password? Let's say we can make 1 million password attempts per second. (This isn't unreasonable: if a hash of the password is obtained, which in many cases is readily available, a modern computer should be able to compare about 1 million keys per second to that hash.) Even at that fast rate, the computer-generated password would take nearly 200 years to crack. But the user-chosen one would take less than a second!

So what recommendations should we make to all those who ask our assistance?

  • Prevent users from choosing common passwords. Preventing users from having any one of the 50,000 most common passwords increases the entropy of their choice from 18 bits to 24 bits (for an 8-character password). In other words, it requires 64 times the amount of time to guess.
  • Apply "composition rules". Requiring at least one of each of a lower case letter, an upper case letter, a number and a symbol increases the entropy for the same 8-character password to 30 bits. That is still crackable in 16 minutes, but that's vastly better than "less than a second".
  • Use long passwords. The longer the password, the greater the entropy. A 12-character password has 34 bits of entropy (~5 hours) and a 20-character password has 42 bits (~51 days) when combined with the above 2 rules. Longer passwords needn't be harder to remember: just think of a mnemonic. For example, the first letter of each word in a verse of your favourite song.
  • Finally, consider computer-generating passwords for users. It's the single most effective way to increase entropy. The downside is that it makes passwords harder to remember, so users will probably write them down. Possibly on a sticky note attached to their monitor.