Musing on Safaricom Cryptanalysis
Error Detecting Code on Safaricom Scratch Cards
Exactly 10 years ago, I wrote an article on “Breaking Safaricom Scratch Card Code”. In the article, subtracting the sixth digit from the third always yielded one. This meant you derive the sixth digit by simply subtracting one from the third digit.
I decided to check back after 10 years if the analysis still holds. So off I went to find Safaricom scratch cards. Luckily, Twitter came to the rescue and found half a dozen recent scratch cards.
In the sample data above, subtracting the sixth and the third digits yields zero instead of one, as in the previous analysis. This means that the third and sixth digits are the same. The code has evolved. It might have something to do with time years — we need another decade to find out.
While mulling over the change, a comment from a reader named polarise in the previous article caught my attention:
The correlation likely implies that the tokens have a check digit so that the application can catch transcription errors. See https://en.wikipedia.org/wiki/Check_digit. Effectively, this is a redundancy so I don’t think this leaks any info. The code generation is very likely to be designed to be pseudorandom, hence the approximately-normal distribution.
A checksum is an error detection technique that adds redundant bits of data to a code and utilizes the bits to check errors in the code. For example, if a 5 is printed as a 6, the checksum should be to able to catch the error. A very simple check digit method would be to take the sum of all digits (digital sum) modulo 10. This would catch any single-digit error, as such an error would always change the sum.
It is therefore plausible that the third or the sixth digit is a check digit for error detection and it is simply generated by adding or subtracting from any digit in the reload number.
However, I’d still like to know why the difference in the third and sixth digits changed after 10 years. See you in a decade.
