# Change in probability of collision when removing digits from MD5 hexadecimal hash values

I am aware that MD5 has a known collision vulnerability and should not be relied upon when uniqueness is required, but in the environment I am working on I only have access to MD5 hash function. Background detail below, but in general how much and how bad is the change in the probability of hash collision if I removed a few digits from the hexadecimal representation of MD5 hash values?

Background: I am working on migrating data between two systems. The target system has a built-in database column of length 30 characters that has unique/primary key resolution mechanism, meaning as long as I put a matching value in that column the system will map it to existing record if exists and create new record otherwise. Unfortunately the primary key from source system has length of between 50 to 100 characters so my best bet is to generate a shorter hash value from it. I only have access to MD5 hash function but the hexadecimal hash value is 32 digits long so I have to drop two of the digits. There is virtually zero probability of anyone wanting to use collision attack on the data so my concern is pretty much on the distant possibility of Heaven-assisted coincidence that two primary keys might generate the same hash value.

N.B. Possibly related to "Should I use the first or last bits from a SHA-256 hash?", but that question is about SHA-256 while this one is about MD5.

To answer your initial question, assuming that MD5 behaves "randomly" (which is kind of true as long as nobody is actively trying to produce collisions), then keeping $n$ hexadecimal characters means keeping $4n$ MD5 output bits, and collisions are expected to appear around $2^{2n}$ keys. With $n = 30$, that's $2^{60}$, also known as "approximately a billion billions", which is still kind of huge. Still, you'd better use a shorter encoding such as Base64, which avoids the issue altogether.