Society of Payment Security Professionals - Payment Security Blog

Cryptography Facts and Fun!

All of the PCI requirements specify the use of cryptography to secure
sensitive data. Many people apply this cryptography without really
knowing what it does, how it works, or where potential problems may lie
- and unfortunately, it is often in the implementation where the
security issues hide. So, I want to discuss some of the common
implementation issues, as well as some fun (well, I think they’re fun)
facts that I think all people who use cryptography as an important part
of their day-to-day business should know. Unfortunately, this post
will probably suffer from the TL;DR factor, but I’ll try to keep it as
brief as possible

Firstly, the mode of operation of a cryptographic function is often as
important to the security of the system as the function itself. For
instance, the ‘Electronic Code Book’ (ECB) mode of many symmetric
ciphers can actually reveal information about the data - even after
encryption. This is because all blocks of data that have the same
value as plaintext will be encrypted to the same value as ciphertext
(assuming the same key is used). Why is this a problem? Lets say your
encrypting a flat file full of card numbers and expiry dates which are
stored as comma separated ASCII values, and an additional [CR] [LF] is
used to separate the data for each card. Eg:

5600000000000000,0609,
5600000000000012,0610,
…

Using a cipher that has a block length of 8 bytes (eg TDES) each entry
is encrypted with the first 8 digits of the card number as the first
block; the last 8 digits as the second block; and the two commas,
expiry date, and [CR] [LF] as the 3rd and last block before the
encryption begins again with the next card entry. Therefore, all cards
that have the same values for the first 8 digits, last 8 digits, or
expiry date, will have the same value in that block of the file - even
after being encrypted.

Now, given that it can be expected that many cards will have the same
BIN (Bank Identification Number - the first 6 digits of the card
number), it is obvious that many of the encrypted values will be the
same. Combining these with hashes or truncated/masked values of the
card numbers (which are not uncommonly stored with encrypted values),
or other forms of knowledge about the contents, then the plaintext
values can be obtained despite the encryption.

There is generally no good reason to use the ECB mode, and lots not to.

Don’t do it.

The same problem holds for some of the other modes of encryption (eg
Cipher Block Chaining - CBC) when encrypting individual values in a
database with the same key and Initialization Vector (IV); card numbers
that have the same first 8 bytes will encrypt to the same value.
Depending on the exact implementation, this may be less of an issue,
but it is an important thing to bear in mind.

The second issue I want to talk about is that asymmetric (’public key’) cryptography is different to symmetric cryptography, and can introduce new problems that many people are not expecting. This sounds painfully obvious, but many people see cryptography as a monolithic thing, with all elements essentially interoperable. This can lead to some unfortunate situations.

For instance, great care must be taken when encrypting small values
with a public key. If you encrypt a value with an RSA public key, a
malicious party can ‘brute force’ the plaintext value by encrypting all
possible values (with the known public key) and comparing the result -
when the encrypted values match, they have found the plaintext. A
standard credit card number has 16 digits, which equals around 56 bits
of information, which is too large to brute force on a normal PC. But
if some of the information is available through a truncated/masked
value, then this becomes quite a valid method. This can be made easier
by certain properties of the modular exponentiation used in RSA when
the plaintext is not prime, resulting in an optimal situation where
only 2^28 values (instead of 2^56) need to be search through, which can be easily done on any PC.

This also applies to other situations where ’small’ values are
encrypted with a public key - such as when a single DES key is
encrypted for transport/storage.

Another commonly unknown fact about RSA is that there are multiple
decryption keys. For the commonly chosen public key values of 3 or
65537 (2^16+1), there are at least 2 decryption keys, and often more
than this. Now I’m being a bit unfair here, as this is really not a
problem at all, but it is a fun fact that many people who have used RSA
for years often do not know - to the point where I have seen people
vehemently deny it! If anyone needs proof of this, I can post some
python code that calculates the ’standard’ and ‘optimal’ encryption
keys for any set of input primes and encryption key.

Finally, I would recommend that anyone who uses RSA on a regular basis
runs through a small example by hand, using a pen and paper. This
sounds a bit scary, but it is actually really easy, and can help with
understanding what is happening much more than years of experience or
passive reading. If people are interested, I will post an example of
how to do this.

If you take one thing away from this (looong) post, I hope it is that
just because your cryptography works, it does not mean that your
cryptography is secure. Do some research, and ask some questions.
We’re here to help.