Tokenization is a form of cryptography

"Father," said one of the rising generation to his paternal progenitor, "if I should call this cow's tail a leg, how many legs would she have?" "Why five, to be sure." "Why, no, father; would calling it a leg make it one?"

Edward Josiah Stears, Notes on Uncle Tom's Cabin

Some security vendors are now promoting tokenization as an alternative to using cryptography. By not considering tokenization a form cryptography, it opens the door to using algorithms that are much weaker than would ever be considered for other uses. This is a mistake. Tokenization is definitely a form of cryptography and should be treated as such.

Both encryption and cryptographic hashing use the idea of a calculation being "easy" or "hard." If there's a polynomial time algorithm to perform a calculation, then we say that it's "easy." If a calculation isn't easy, we say that it's "hard." If a calculation is easy, it's feasible for an attacker to do; if a calculation is hard, it isn't.

Both cryptographic hash algorithms and encryption algorithms have the property that calculating them is easy, but reversing the calculation is hard. With a cryptographic hash function, there may be more than one way to reverse the calculation while there's a unique way to reverse encryption. It's also easy to reverse encryption if you have the right cryptographic key, while there's no easy way to reverse a cryptographic hash function.

If we consider what tokenization does, it certainly looks like it falls under what's commonly defined as either encryption or hashing. Tokenization takes an input value and creates a token from it. To protect the input value, it needs to be hard to recover the input value from the token. That's just like either encryption or hashing, isn't it? The only difference is that we're calling the output of the tokenization function a "token" instead of a "ciphertext" or a "message digest."

But because tokenization vendors don't call their technology "encryption" or "hashing," they can avoid having to worry about using peer-reviewed or standardized cryptographic algorithms. They can also use "security through obscurity" by claiming that their tokenization algorithm is proprietary. This has been known to be a bad idea for over 150 years, and it's still a bad idea today.

There are encryption technologies available that offer the same benefits as tokenization, but have rigorous proofs of their security. If you use one of these, you have a high level of assurance that your information is protected. If you don't, you're accepting the use of a potentially-weak cryptographic algorithm. Why would you want to do that?

Tokenization is definitely a form of cryptography. It should be treated like it is.