The barcode in the article decodes to "JGB S11221017031011395940006622112101 BC046285E760466C01" if anyone fancies having a crack at making a stamp keygen.
Likely, they use some authenticated hash like HMAC SHA-256 with a schedule of randomly chosen keys added periodically. (Can't really rotate out keys once generated.) GFL reversing the algorithm AND any working key.
Also, an "is it used" database has to be kept to prevent an analog replay attack by reusing the same barcode. The most efficient way to keep track of used stamps would be a bloom filter. A poor implementation would lead to false positives, and mailers being accused of fraud. It also has should be highly reliable, highly available, and geographically disperse.
Would pure random + a central database not be more practical? Assuming the barcode is a 10-by-50 grid, that's 500 bits of entropy. With 100 bits of entropy, you need over 100 trillion codes to have a 0.4% chance of a collision. Every added bit makes it twice as unlikely.
There's no need to have crypto if you're the authority on both assigning and verifying the barcodes. That way, no attacker will be able to create a barcode and have any hope of it working.
They're not the only ones creating barcodes -- stamps come with non-specific data, but bulk mailers are allowed to create their own, with embedded routing and billing codes.
We forget just how automated sorting of mail now is. Only probable manual part is by the person doing delivery, and that is just for their own convenience. Everything else is automated, with few hard to read addresses going through manual sorting. Where they are tracked too.
