0

For example a credit card expiry month can be only of only twelve values. So a hacker would have a one in twelve chance of guessing the correct encrypted value of a month. If they knew this, would they be able to crack the encryption more quickly?

If this is the case, how many variations of a value are required to avoid this? How about a bank card number security code which is commonly only three digits?

Ian Warburton
  • 15,170
  • 23
  • 107
  • 189
  • How can they verify whether their guess is correct, and what's the encryption method? – Michelle Aug 20 '13 at 15:41
  • I'm not sure. But they'd have a one in twelve chance so they could work from twelve different assumptions - if that makes any sense. The encryption method shouldn't need to be a secret; its the key that should be secure. – Ian Warburton Aug 20 '13 at 15:43
  • 1
    so, In this case, stipulate that they actually have the card number. But not the expiry. Doing a test transaction for $1 would be enough to validate whether the hashed/encrypted expiry is correct or not. And this easy validation of the correctness of the hashed could threaten the security of the algorithm itself? – Andyz Smith Aug 20 '13 at 15:46
  • There's a huge range of symmetric encryption methods, and I can't tell from your question what your level of expertise is (and whether you're using, e.g., a home-grown Caesar cipher, or something). – Michelle Aug 20 '13 at 15:47
  • Contrast with wartime encryption. You can never know if you got th right message unTil troops start moving like you thought they would according to an unencrypted but confusing and possibly garbage message you decrypted. – Andyz Smith Aug 20 '13 at 15:49
  • @AndyzSmith Its encrypted. Not hashed. – Ian Warburton Aug 20 '13 at 15:56
  • Hashing is core to encryption. – Andyz Smith Aug 20 '13 at 15:58
  • ok, so could you experts please come up with an answer? :) – Ian Warburton Aug 20 '13 at 16:01
  • Interesting... http://stackoverflow.com/questions/1110152/breaking-aes-encryption-using-decrypted-data – Ian Warburton Aug 20 '13 at 18:43
  • This question appears to be off-topic because it is about cryptography rather than programming. – President James K. Polk Aug 21 '13 at 00:02

2 Answers2

1

If you use a proper cipher like AES in a proper way, then encrypting such values is completely safe.

This is because modes of operation that are considered secure (such as CBC and CTR) take an additional parameter called the initialization vector, which effectively randomizes the ciphertext even if the same plain text is encrypted multiple times.

Note that it's extremely important that the IV is used correctly. Every call of the encryption function must use a different IV. For CBC mode, the IV has to be unpredictable and preferably random, while CTR requires a unique IV (a random IV is usually not a bad choice for CTR either).

ntoskrnl
  • 5,714
  • 2
  • 27
  • 31
  • If I use a different random IV for every encrypt then how do I know which IV to use to decrypt? – Ian Warburton Aug 21 '13 at 08:53
  • @IanWarburton Some systems simply concatenate the IV to the beginning of the ciphertext, which is a valid approach. You could also store it in another field in the database. The IV does not have to be secret at all. – ntoskrnl Aug 21 '13 at 08:56
  • That's fascinating. So I will prepend it to ciphertext that gets stored in the database. – Ian Warburton Aug 21 '13 at 09:03
  • Do you think that substring-ing the first sixteen characters of a new Guid is a good random IV? – Ian Warburton Aug 21 '13 at 09:18
  • @IanWarburton No; that would only use 16 different ASCII characters of the 256 possible values of a byte. You should use a cryptographically secure random number generator. – ntoskrnl Aug 21 '13 at 09:38
1

Good encryption means that if the user knows for example as you mentioned that the expiration month of a credit card is one of twelve values then it will limit the number of options by just that, and not more.

i.e.

If a hacker needs to guess three numbers, a, b, c, each of them can have values from 1 to 3. The number of options will be 3*3*3 = 27. Now the hacker finds out that the first number, a, is always the fixed value 2. So the number of options is 1*3*3 = 9. If revealing the value of the number a will result in limiting the number of options to a value less then 9 than you have been cracked, but in a strong model, if one of the numbers will be revealed then the number of options to be limited will be exactly to 9.

Now you are obviously not using only the exp. date for encryption, i guess.

I hope i was clear enough.

TomF
  • 183
  • 11
  • Yes I'm encrypting exp. date by itself and putting the result in a database column used for storing just that value. – Ian Warburton Aug 21 '13 at 08:54
  • Sorry, i thought that the exp date it your key. There will be less possible solutions for output because of many duplicate date possibilities, unless you use a different IV for every user. Why do you need to encrypt it though? is it a secret? – TomF Aug 21 '13 at 10:50
  • @TomF Note that you are *supposed* to use a different IV for every encryption operation. – ntoskrnl Aug 21 '13 at 14:32
  • You don't HAVE to. for example if there is something as a sequence ID inside your data block to be encrypted then the same IV can be used because the inputs will not be repeated anyway. Although not recommended because that way is denying the IV of its purpose, if it can save you on bandwidth for example then a fixed IV can be used (using the Time for example, lets say with a resolution of 3 minutes) will cause recurring inputs inside that time window to be output-ed the same. – TomF Aug 21 '13 at 14:48