Luhn algorithm

The Luhn algorithm or Luhn formula, also known as the ” 10″ or “mod 10” algorithm, is a simple checksum formula used to validate a variety of identification numbers, such as , , in the United States, Canadian , Israel ID Numbers and Social Security Numbers (ΑΜΚΑ). It was created by IBM scientist and described in U.S. Patent No. 2,950,048, filed on January 6, 1954, and granted on August 23, 1960.

The algorithm is in the and is in wide use today. It is specified in -1. It is not intended to be a cryptographically secure hash function; it was designed to protect against accidental errors, not malicious attacks. Most credit cards and many government identification numbers use the algorithm as a simple method of distinguishing valid numbers from mistyped or otherwise incorrect numbers.

Contents

Description

The formula verifies a number against its included check digit, which is usually appended to a partial account number to generate the full account number. This number must pass the following test:

  1. From the rightmost digit, which is the check digit, and moving left, double the value of every second digit. If the result of this doubling operation is greater than 9 (e.g., 8 × 2 = 16), then add the digits of the product (e.g., 16: 1 + 6 = 7, 18: 1 + 8 = 9) or, alternatively, the same result can be found by subtracting 9 from the product (e.g., 16: 16 − 9 = 7, 18: 18 − 9 = 9).
  2. Take the sum of all the digits.
  3. If the total 10 is equal to 0 (if the total ends in zero) then the number is valid according to the Luhn formula; else it is not valid.

Assume an example of an account number “7992739871” that will have a check digit added, making it of the form 7992739871x:

Account number 7 9 9 2 7 3 9 8 7 1 x
Double every other 7 18 9 4 7 6 9 16 7 2 x
Sum digits 7 9 9 4 7 6 9 7 7 2 x

The sum of all the digits in the third row is 67+x.

The check digit (x) is obtained by computing the sum of the non-check digits then computing 9 times that value modulo 10 (in equation form, ((67 × 9) mod 10)). In algorithm form:

  1. Compute the sum of the non-check digits (67).
  2. Multiply by 9 (603).
  3. The units digit (3) is the check digit. Thus, x=3.

(Alternative method) The check digit (x) is obtained by computing the sum of the other digits (third row) then subtracting the units digit from 10 (67 => Units digit 7; 10 − 7 = check digit 3). In algorithm form:

  1. Compute the sum of the non-check digits (67).
  2. Take the units digit (7).
  3. Subtract the units digit from 10.
  4. The result (3) is the check digit. In case the sum of digits ends in 0 then 0 is the check digit.

This makes the full account number read 79927398713.

Each of the numbers 79927398710, 79927398711, 79927398712, 79927398713, 79927398714, 79927398715, 79927398716, 79927398717, 79927398718, 79927398719 can be validated as follows.

  1. Double every second digit, from the rightmost: (1×2) = 2, (8×2) = 16, (3×2) = 6, (2×2) = 4, (9×2) = 18

<!–

THERE HAVE BEEN MULTIPLE ERRONEOUS “CORRECTIONS” TO THIS ALGORITHM! PLEASE READ: Are you about to delete the “+” from “(1+6)” and “(1+8)”? PLEASE DON’T! The algorithm sums the INDIVIDUAL DIGITS, not numbers. Thus, “(1+6)” is more illustrative of what is being done. If you leave it as “1 + (2) + 7 + (16) + 9 + (6) + 7 + (4) + 9 + (18) + 4” it sums to 88, not 70. This is just plain wrong.

Another formulation: [ 4 + (2×9) mod 9 + 9 + (2×1) mod 9 + 7 + (2×3) mod 9 + 9 + (2×8) mod 9 + 7 + (2×1) mod 9 ] mod 10 except that each ‘mod 9’ produces 9 rather than zero if it divides evenly.

The description I found here was *also* incorrect however. It said you take the result of the sum, and divide it by 10 and then *truncate* it. Truncation is basically the *opposite* of taking the modulus. It happens to work out in the case because the sum is 64, but if the sum were 74, you’d get: 74 / 10 = 7.4, which truncates to 7. I’ve changed it so the sum is 65, which accordingly to the previous description I read would mean the check digit is still a 6, but in fact it should be a 5. I did my best to rephrase it to something that was mathematically correct and provided my poor attempt at a layman’s instructions on how to do the computation. Feel free to correct it, but don’t put it back to “truncation”. That’d be most bad. I would actually advocate using a different number whose sum isn’t a multiple of 9 to avoid this mistake being reintroduced.

–>

  1. Sum all the individual digits (digits in parentheses are the products from Step 1): x (the check digit) + (2) + 7 + (1+6) + 9 + (6) + 7 + (4) + 9 + (1+8) + 7 = x + 67.
  2. If the sum is a multiple of 10, the account number is possibly valid. Note that 3 is the only valid digit that produces a sum (70) that is a multiple of 10.
  3. Thus these account numbers are all invalid except possibly 79927398713 which has the correct check digit.

Alternately, you can use the same checksum creation algorithm, ignoring the checksum already in place as if it had not yet been calculated. Then calculate the checksum and compare this calculated checksum to the original checksum included with the credit card number. If the included checksum matches the calculated checksum, then the number is valid.

Strengths and weaknesses

The Luhn algorithm will detect any single-digit error, as well as almost all transpositions of adjacent digits. It will not, however, detect transposition of the two-digit sequence 09 to 90 (or vice versa). It will detect 7 of the 10 possible twin errors (it will not detect 22 ↔ 55, 33 ↔ 66 or 44 ↔ 77).

Other, more complex check-digit algorithms (such as the Verhoeff algorithm and the Damm algorithm) can detect more transcription errors. The Luhn mod N algorithm is an extension that supports non-numerical strings.

Because the algorithm operates on the digits in a right-to-left manner and zero digits affect the result only if they cause shift in position, zero-padding the beginning of a string of numbers does not affect the calculation. Therefore, systems that pad to a specific number of digits (by converting 1234 to 0001234 for instance) can perform Luhn validation before or after the padding and achieve the same result.

Prepending a 0 to odd-length numbers makes it possible to process the number from left to right rather than right to left, doubling the odd-place digits.

The algorithm appeared in a US Patent for a hand-held, mechanical device for computing the checksum. It was therefore required to be rather simple. The device took the mod 10 sum by mechanical means. The substitution digits, that is, the results of the double and reduce procedure, were not produced mechanically. Rather, the digits were marked in their permuted order on the body of the machine.

Implementation examples

Pseudo-Code

function checkLuhn(string purportedCC) { int sum := 0 int nDigits := length(purportedCC) int parity := nDigits modulus 2 for i from 0 to nDigits - 1 { int digit := integer(purportedCC[i]) if i modulus 2 = parity digit := digit × 2 if digit > 9 digit := digit - 9 sum := sum + digit } return (sum modulus 10) = 0 }

See Also on BitcoinWiki

External links

Source

http://wikipedia.org/