Checking a key before actually using it

Question

I have a block of data crypted using twofish with a key of 128 bit.

The data must be accessed from a GUI, the user gives the key, the block is decoded and the real data is accessed.

Problem is that I need to be sure that the key is correct before trying to decode the block.

My current solution is to have a file (say chk.blk) that is the encryption of some data I can use to test the correcteness of the key.

Initially I had a file chk.blk being the encryption of a known data (say the text 12345678) then I thought that this could compromise the key. Is that true? Is there any weakness in twofish if the attacker has both the original and the encrypted data?

Fearing this could be the case, I now generate a random text with a given property (e.g. x...x..x where . is any character different from x). I take the key, decode chk.blk and verify the result has the desired property. The idea is that now the attacker does not have a known text to use but a rather large group of them. Of course I can't be sure that the key is really correct, the user might have taken, by chance, a key that produces a decoded text which have exactly the desired property, but I think the probability is extremely low. Do you think there any issue with this approach?

Any suggestion?

Usage scenario

I'm adding some more info here to clarify the intended usage.

Imagine you have a rather big set of documents (5Mb of data) that must be sent to a large number of recipients (say 10.000). Those documents have to be kept absolutely secret until a given date/time (say 21 Dec 2012 21:12).

Between now and then all the reciepients will be able to download the documents along with a decryption program on their PC. They will reach their designated destination and will wait there to receive the decoding key at the proper time.

Exact syncronization is not important but they all have to read the documents at (almost) the same time.

It is absolutely mandatory that none of them can read the documents before the given date.

They will be located in places where they might not be connected to the internet, that's why they have to download the docuemnts beforehand.

They will all, however, be able to receive a message with the key (e.g. via SMS, via phone, broadcasted by a TV channel or a radio number station, ...).

So, the idea is to distribute the documents encripted with 128 bits of security, which should be enough to protect the key for few months, and then distribute the key as a string (26 characters).

Answer 1

In order for a symmetric block cipher to be considered secure by modern standards, it has to be IND-CPA, that is indistinguishable from a random oracle under a chosen plain text attack. It also has to be IND-CCA and IND-CCA2, but IND-CPA is sufficient for it to also be secure under a known plain text attack.

Presuming TwoFish is still unbroken, it should consequently be safe to use the cipher text of a single known block as a key verifier. Or, to be more precise, storing that chk.blk file together with the encrypted file will not reveal significantly more information about the key.

However, there are other issues with your approach you might or might not already be aware of.

Firstly, do you really think it is feasible to get a user to enter a completely random 128 bit key using a GUI? Most application use pass phrases for such scenarios, and in such case your approach should be slightly different. For starters, where do you store the salt for the PBKDF? Will the key be used for encrypting more than one file? What information will the adversary be able to deduce just by looking at the cipher text of two files that are known to be encrypted using the same key?

Secondly, your approach is really only secure if the only threat is an adversary, without access to the key but with read only access to both the verifier and the actual cipher text, trying to guess the plain text contents corresponding to the cipher text. Your scheme is insufficient to prevent anything beyond that scenario.

Answer 2

Given your specific problem, I would suggest embedding a MIC inside your payload. A message integrity code is a check sum embedded inside the message and is encrypted along with the message. You don't have to use a secure hash, it could be anything. I prefer Fnv1 because of its simplicity to implement.

The problem with the check block is that the attacker knows the contents of the check message, the check message is small in size, and so the attacker can use the smaller message as a proxy for the attack on the larger. A smaller message takes less time to decrypt.

With a MIC, the entire contents of the message have to be decoded with the candidate key, and then the MIC computed. This adds additional computational burden to the attacker.

It's possible you may have thought of this already, and it makes me wonder if the decryption code is not under your control.