Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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).

share|improve this question
Why the check block? Do you only get one chance to read the cipher text before its destroyed? –  Grant BlahaErath Mar 21 '12 at 22:39
@Grant: Imagine that the nature of the data is such that, once decoded, the user couldn't tell if it's correct or not before trying to use it (and failing in the attempt). I prefer to avoid the user having to fail to understand that the key was incorrect, I'd like to be able to warn him beforehand. –  Remo.D Mar 22 '12 at 10:38
@Remo.D: The conventional solution to the problem you describe in your comment is to use a MAC. The only reason to use a key check value, instead of just a MAC, is that it allows you to verify the correctness of the key before decrypting the bulk data. –  Henrick Hellström Mar 22 '12 at 12:14
@Remo.D: You can use a MIC or a MAC. A message integrity code is a checksum (even a non secure one like fnv1) encrypted with the message, a message authentication code is added outside the code to ensure message authenticity and integrity. Based on computation load the check block is least, followed by the mac, and then finally the mic. Higher computation loads make brute force more time consuming. –  Grant BlahaErath Mar 22 '12 at 21:52
add comment

2 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
+1 for mentioning PBKDF. You might also want to consider using the bcrypt or scrypt KDFs. –  Ilmari Karonen Mar 21 '12 at 15:43
The key has to be provided once by the user and is used only to crypt the secret file (and the check file). 128 bits can be expressed with a string of 26 characters like ABBCD-EFGHK-12345-LMNOP-XYZ12-3 which is not too bad to me. I can't imagine other scenarios except the one you mention: the adversary has no access to the key but (might have) read access to the crypted file. What else could go wrong? –  Remo.D Mar 21 '12 at 15:55
@Remo.D: A lot of things might go wrong. For instance, an adversary might modify the cipher text, and having a key verifier present will not be sufficient to detect this. Another thing: Is this some license key system and is the person entering the key also the typical adversary? –  Henrick Hellström Mar 21 '12 at 17:43
@HenrickHellström: Yes we may assume that the user is an adversary. It's not a license scheme, just a block of data that needs to be decrypted at a given time. If they modify the cipher text, what would this imply? –  Remo.D Mar 21 '12 at 19:05
@Remo.D: To begin with, if the user is the adversary I suppose you are sending the key and the cipher text off to a remote server for decryption, so that debuggers and hexeditors aren't a problem. This still leaves you with a scheme where the user might decode the key, use a TwoFish implementation to decrypt the cipher text, see what's inside, and guess how it might be modified to get the software to do other things it's not supposed to do. –  Henrick Hellström Mar 21 '12 at 19:19
show 3 more comments

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.