locked
Is it possible to incorrectly decrypt using the wrong key? RRS feed

  • Question

  • We have an application which I am debugging a problem in with decrypting data.

    The data is stored in a database and when it exports to file it decrypts the sensitive data and writes to file.

    The encryption key changes every year so when the export runs to decrypt, in the last batch of exports there will be some records encrypted with the old key and some with the new. This is bad on a number of levels and we are implementing a better solution but at the moment I am trying to under what has happened.

    In the past this has never been a problem as if the wrong key is used an exception is thrown and that item is not decrypted.

    But for some records this time the file contains nonsense where sensitive data should be.

    The code assumes that it is impossible to decrypt using the wrong key as you get an exception about padding. And In my experience of decrypting using the wrong key that is true.

    But if it were true then it must have successfully decrypted using the correct key and I need to look elsewhere for the problem.

    In an ideal world there will be validation and some index stored to say which encryption key was used. But i am more interested in how I have gotten into this situation and whether my assumption that it's not possible to decrypt using the incorrect key. The reason being is for some data it might be difficult to validate since the data being decrypted might look like nonsense even with the right key.

    I am using the Microsoft Patterns and Practices library with Rijndael Managed algorithm and a 2048bit key.

    Tuesday, June 18, 2013 7:57 AM

Answers

  • There is NO CRC checking built into standard encryption algoritms.

    If you get the decryption key (or other parameters) wrong the only thing that may trigger an error is the padding. If you happen to use no padding then there will be no error for an incorrect key. If you do use padding (default is PKCS7) I suspect there's still a chance to get no errors for a wrong key. The padding can be as small as a byte so in the end we're talking about the chance of an incorrect key producing a byte that happens to be correct. This change should be small but likely not 0.

    • Marked as answer by PaulMcCaffery Tuesday, June 18, 2013 12:18 PM
    Tuesday, June 18, 2013 10:55 AM

All replies

  • The encryption method has a CRC built into the algorithm which is validated as part of the decryption process.  The exception you get when a message fails to decrypt is based on the CRC check.  As with any CRC check the is a small possiblitly that you can pass the CRC check but still get wrong decrypted results.

    jdweng

    Tuesday, June 18, 2013 10:25 AM
  • How small a possibility are talking?

    So the decryption must be validated to gain absolute certainty of success?

    Realistically how would you validate as some data may appear to be nonsense even if its meaningful data to some application?

    Thanks

    Tuesday, June 18, 2013 10:29 AM
  • You can write a thesis paper on the subject, and many people have.  The possibility of decryption passing CRC check is based on the CRC algorithm.  The simpliest CRC is an 8 bit checksum which means there are only 256 possible results.  The probability of passing CRC would then be 1/256.

    There are many algorithms to break codes starting with WWII Enigma code.  Code Breaking requires some knowledge of what the decrypted results should look like.  But then there are double and tripple encoded/decoded algorithms.


    jdweng

    Tuesday, June 18, 2013 10:37 AM
  • There is NO CRC checking built into standard encryption algoritms.

    If you get the decryption key (or other parameters) wrong the only thing that may trigger an error is the padding. If you happen to use no padding then there will be no error for an incorrect key. If you do use padding (default is PKCS7) I suspect there's still a chance to get no errors for a wrong key. The padding can be as small as a byte so in the end we're talking about the chance of an incorrect key producing a byte that happens to be correct. This change should be small but likely not 0.

    • Marked as answer by PaulMcCaffery Tuesday, June 18, 2013 12:18 PM
    Tuesday, June 18, 2013 10:55 AM
  • As I say I am using the Patterns and Practices and I have been assuming I am using the default padding PKCS7.

    This still begs the question of how you validate the decrypted data to ensure you have the correct key.

    Admittedly the best solution is avoid using the wrong key which our new solution does and the data can easily be validated in my case as it should only contain numbers.

    Based on what you are saying though if I was to perform processing on 10000 records there is a small possiblity that it would throw no exception is using the wrong key, which is what I appear to be seeing.

    But presumably this a common enough problem to have a standard approach for validating the decryption. Are people forced to use a hash of the data before encryption to compare after decryption. I have read a fair amount on encryption but have never seen anything discussing this which surprises me.

    Thanks for all your input.

    Tuesday, June 18, 2013 12:16 PM
  • "This still begs the question of how you validate the decrypted data to ensure you have the correct key."

    Well, you can certainly use a hash or any sort of checksum. There's still a posibility that the wrongly decrypted data will pass validation but the chance is so small that it's irrelevant. Using the wrong key and ending up with a result that has the same hash as the original result... oh well... not in a million years :)

    Or if the data has a specific format maybe you can simply check a signature - like all dll files starting with PE. If it doesn't have a signature you can add one, it will be less expensive than computing the hash.

    "But presumably this a common enough problem to have a standard approach for validating the decryption."

    I'm not a cryptography expert but I suspect that if there was a way to tell if the encryption key is correct the encryption scheme would be weaker.

    And there's something I should have mentioned in my original post: There's still the possibility that your encrypted data has been corrupted. If the corruption does not affect the last block (which contains the padding) when there will be no exception but the decryption will spit out garbage for the blocks affected by corruption.

    Tuesday, June 18, 2013 3:24 PM