Quote from: molecular on January 20, 2015, 08:20:33 PM

urm. Maybe I'm misunderstanding something, but shouldn't the qrcodes match:

QR codes are deterministic, but contain error-correction information in addition to the encoded payload. There are a lot of libraries that intentionally do a sloppy work in letting you specify the ratio of payload bits to forward-error-correction bits to be user-friendly (or loser-friendly). Get a good library and you'll get 100% reproducibility.

Moreover get a good QR reader that not only displays the payload bits but the signal/noise ratio for the decoded result.

Edit: OK, I need to explain the "loser-friendly" to avoid making it sound like a ~~vain~~ vapid insult.

One can intentionally produce "bad" QR code images in the sense that they aren't perfect representation of the correct encoded bitstream. Because of the redundancy in encoding they will still read correctly with a normal decoder (with S/N ratio of say 20dB). The "bad"-ness is a side channel that can still be read with a modified decoder that not only reads the "main" payload but also the "side" payload (with a lower S/N margin of say 3dB).

Tricks like that have been used in e.g. theft tracing or as a secret "cookie" in marketing campaigns intended to be read by some closed-source free app. So if your good QR reader some QR code with very large noise margin or surprisingly large ratio of FEC bits you may have a reason to believe that the QR code contains a side channel.

Edit2: Obviously with cryptographic application modified QR codes with side-channels can be used to leak the private key information, but I haven't heard of that happening yet.