ISO 9564 PIN block calculator and key component combiner
Build and decode clear PIN blocks in formats 0 to 3, combine key components, and compute key check values.
Runs in your browser — nothing you paste is sent to a server
This works on clear PIN blocks, not encrypted ones. A live PIN block is encrypted under a PIN key from the pad to the HSM, and getting a PIN out of one requires that key — nothing here does that, or could. What this handles is the formatting either side of the encryption, which is the part that goes wrong and the part nothing else lets you see. Use test PINs and test PANs.
041225EEEEEEEEEE
- PIN field
- 041234FFFFFFFFFF
- format 0, length 4, then the PIN, then F padding
- PAN field
- 0000111111111111
- four zeros, then 111111111111 — the rightmost twelve digits of the PAN with the check digit removed first
- PIN field XOR PAN field
- 041225EEEEEEEEEE
How a format 0 block is assembled
PIN field 0 4 1 2 3 4 F F F F F F F F F F
│ │ └─────┘ └───────────────────┘
│ │ PIN pad with F to 16 nibbles
│ └── PIN length, in hex — a 12-digit PIN is C
└──── format code
PAN field 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
└─────┘ └───────────────────────┘
zeros rightmost 12 digits of the PAN
AFTER removing the check digit
block PIN field XOR PAN fieldThe check digit comes off first, and then twelve digits are taken from what is left. Taking the rightmost twelve of the whole PAN is the most common implementation bug in this area — it shifts every digit by one position and produces a block that is wrong in a way no error message downstream can describe.
Choosing a format
- Format 0 pads with F and folds in the PAN. It is what most of the world runs. Its weakness is that the F padding makes a short PIN recognisable from the shape of the block.
- Format 3 fixes that with random padding restricted to A–F, so the block differs every time while a padding nibble still cannot be mistaken for a PIN digit. Prefer it where you have the choice.
- Format 2 is for offline verification on the card itself, where there is no PAN to bind to.
- Format 1 is for when no PAN is available at all. Do not use it where one is: without the PAN binding, the same PIN gives the same block on every account, and a block captured from one account is usable against another.
Key components and check values
A key ceremony splits a key so that no single person ever holds it. Two or three custodians each carry a component, and the key is their XOR — so every custodian must be present, and any one of them alone learns nothing at all, because with one component missing every possible key remains exactly as likely.
The key check value is how two parties then confirm they loaded the same key without either revealing it: encrypt a block of zeros under the key and compare the first three bytes. Enough to catch a mis-keyed component, far too few to attack the key with.
Parity is the other thing worth checking. DES used only 56 of a key's 64 bits and made the low bit of each byte a parity bit, set for an odd number of ones. Nothing verifies it today, but HSMs and key-loading devices still frequently refuse a key without it — and because DES discards those bits, adjusting parity cannot change the check value.
Scope and limits
- Format 4, the AES-based block from PCI PIN, is not supported. Unlike formats 0 to 3 it is not a formatting operation — building one requires an actual AES encryption with a key, which makes it a different kind of tool. A block beginning with the nibble 4 is recognised and named rather than reported as a generic failure.
- Key check values use the zero-block convention — the first three bytes of a block of zeros encrypted under the key, which is what an HSM means by “KCV”. TR-31 also defines a CMAC-based check value for AES keys, which is a different number; if yours disagrees and the key is AES, that is the first thing to check.
- A key length is often ambiguous, so every reading is shown rather than one guessed at. Sixteen bytes is double-length 3DES or AES-128 and nothing in the bytes says which — quoting a single check value would send somebody to reload a key that was fine.
- The parity check is advisory. Nothing verifies DES parity today and no modern implementation depends on it, but HSMs and key-loading devices still frequently reject a key without it, and adjusting parity changes only bits the algorithm ignored.
Worked example
PIN 1234 on PAN 4111111111111111, in format 0 — the format most of the world runs. Every value below is computed by the tool above.
The two fields, and the XOR
- PIN field
- 041234FFFFFFFFFF
- format 0, length 4, then the PIN, then F padding
- PAN field
- 0000111111111111
- four zeros, then 111111111111 — the rightmost twelve digits of the PAN with the check digit removed first
- PIN field XOR PAN field
- 041225EEEEEEEEEE
Reading back with the same PAN returns 1234, as it must.
The failure worth knowing about
Decode that same block against a different PAN and it does not fail. It returns the PIN 1270 — a perfectly ordinary four digits, with a valid length nibble and nothing to suggest anything is wrong. The XOR has no integrity check in it, so a wrong PAN simply gives a wrong answer.
The padding is the only tell. Format 0 pads with F, and here it comes back as BBBBBBBAAA. That is why this tool warns on non-F padding instead of quietly handing you a plausible wrong PIN.
Frequently asked questions
- Does this decrypt a PIN block?
- No, and nothing here could. In a live system the PIN block is encrypted under a PIN key from the moment it leaves the pad until it reaches an HSM, and recovering a PIN from an encrypted block requires that key. This tool works on the clear block — the formatting step before encryption and after decryption, where the PIN, its length and the PAN are folded into sixteen nibbles. That is the step people actually get wrong, and it is the step nothing else lets you see.
- Which twelve PAN digits go into the block?
- The rightmost twelve excluding the check digit — and the order matters. Drop the last digit first, then take twelve from what remains. Taking the rightmost twelve of the whole PAN is the most common implementation bug in this area, and it produces a block that is wrong by one digit position with nothing downstream able to diagnose it. For a PAN shorter than thirteen digits the field is left-padded with zeros.
- Why did my PIN block decode to the wrong PIN instead of failing?
- Because format 0 cannot tell you. The block is the PIN field XOR-ed with the PAN field, so decoding with the wrong PAN still produces a valid-looking length nibble and four numeric digits — just the wrong ones. The padding is the only thing that gives it away: format 0 pads with F, so anything else means the PAN you used is not the one the block was built with. This tool warns when the padding is not F rather than quietly handing you a plausible wrong answer.
- What is the difference between format 0 and format 3?
- The padding. Format 0 pads with F, which makes a short PIN recognisable from the shape of the block. Format 3 pads with random nibbles restricted to A through F, so the block looks different every time while a padding nibble can still never be mistaken for a PIN digit. Both fold the PAN in the same way. Format 3 is the better choice where you have it; format 0 is what most of the world runs.
- Why combine key components with XOR?
- So that no single person ever holds the key. In a key ceremony two or three custodians each carry a component and the key is their XOR, which means every custodian must be present and any one of them alone learns nothing whatsoever about the result — with one component missing, every possible key remains exactly as likely. This tool also checks odd parity: DES ignored the low bit of each byte, but HSMs and key-loading devices still often reject a key without it, and the error they give says nothing useful.
- How is the key check value computed?
- The first three bytes of a block of zeros encrypted under the key — the zero-block convention, which is what an HSM means by KCV and what a key ceremony worksheet has a box for. Three bytes is enough to catch a mis-keyed component and far too few to attack the key with, which is the point. Note that TR-31 defines a separate CMAC-based check value for AES keys: if your HSM disagrees and the key is AES, that is the first thing to check.
- Why does one key show two different check values?
- Because the length does not say which algorithm the key is for. Sixteen bytes is a double-length 3DES key or an AES-128 key, and twenty-four is three-key 3DES or AES-192 — the bytes are identical and the check values are completely different. This tool shows every reading the length admits rather than picking one, because quoting a single wrong check value would send you to reload a key that was loaded correctly.
- Does adjusting parity change the check value?
- No, and that is why adjusting parity is safe. DES discards the low bit of every key byte in its first key permutation, so a key and its parity-adjusted form encrypt identically and produce the same KCV. If your check value does change after a parity fix, something other than the parity changed too.
- Is format 4 supported?
- Not yet. Format 4 is the AES-based block introduced for PCI PIN, and unlike formats 0 to 3 it is not a formatting operation — constructing it requires an actual AES encryption with a key, so it is a different kind of tool rather than a fifth option in this one. A block starting with the nibble 4 is recognised and named rather than reported as a generic failure.
Use it in your own code
This page is a front end for a function you can install. It is the same implementation — not a port — so it answers exactly what you see above.
npm i pymnt-tools
import { decodePinBlock } from "pymnt-tools/pin-block";Prefer HTTP? The same functions are a free keyed API, or browse the package on npm.