On 10 July, researchers from Wroclaw University of Science and Technology posted a preprint demonstrating that QR codes can carry cryptographic signatures without exceeding their static capacity [S1][P2]. The fix targets a vulnerability most people have never thought about: anyone with a printer and a sticker can overlay a legitimate QR code and redirect payments, credentials, or personal data. The question is whether the solution scales beyond a proof-of-concept — and what it breaks for the billions of phones already scanning without a second thought.

The problem hiding in plain sight

QR codes are everywhere — parking meters, restaurant menus, event tickets, payment terminals — and millions of people scan them without hesitation [S1]. But a QR code is just a 2D barcode. It encodes a URL or text string. It carries no signature, no watermark, no way to prove who created it.

The authors call the attack "quishing" — QR phishing [S1]. The scenario is concrete: a scammer prints a fake QR code on adhesive, walks up to a self-service parking machine, and covers the legitimate code. A driver scans it, lands on a lookalike payment page, and enters card details. The driver thinks they've paid for parking. They've paid the scammer.

No special skills required. No exploit. Just a printer.

Fitting cryptography into a postage stamp

The researchers' proof-of-concept works entirely offline [S1]. It uses three components:

  • EdDSA signatures on the Ed25519 curve — a fast, compact digital signature scheme that proves a QR code was generated by a specific key holder
  • CBOR-encoded certificates — CBOR (Concise Binary Object Representation) is a binary data format far more compact than JSON, squeezing certificate data into the QR code's limited pixel budget
  • ZLIB compression — to further shrink the payload so the signature and certificate fit alongside the original data

The key insight: a standard QR code has a fixed maximum capacity. You can't just append a signature and hope it fits. The combination of CBOR's binary encoding and ZLIB compression keeps the total payload small enough that the QR code remains scannable at reasonable sizes [S1].

The offline model proves the concept works. But offline has a hard limit.

Where offline breaks down

A fully offline system can't revoke keys in real time [S1]. If a private key is compromised, every QR code signed by that key remains valid until it physically expires. For a handful of parking machines, that's manageable. For a smart-city deployment with thousands of IoT endpoints — meters, sensors, kiosks — the inability to revoke a stolen key instantly is a serious gap.

The authors acknowledge this directly, noting that a purely offline design cannot revoke keys on demand across large smart-city IoT installations, which limits how far the approach can scale [S1].

The hybrid fix

To close that gap, the researchers propose a second architecture: a Hybrid Web PKI model [S1]. It layers three things on top of the offline foundation:

  • JWKS endpoints — JSON Web Key Set URLs where public keys are published and can be rotated or revoked
  • A Central Trust Registry — a single authority tracking which keys are valid and which have been pulled
  • URL fragments — the part of a URL after the # symbol, which browsers don't send to servers but apps can read locally, keeping the cryptographic material self-contained

The hybrid model is built to stay backward-compatible: ordinary native camera apps can still scan the QR code and open its URL, while compliant apps check the registry in real time to validate the code [S1]. The authors argue that combining offline handling for simple cases with the hybrid model for larger deployments offers a workable route to stopping QR spoofing [S1].

What it means

Every QR code you've ever scanned could have been replaced with a sticker. That's not a theoretical risk — quishing attacks on parking machines and public kiosks have been documented enough to earn a name. The researchers' contribution is showing that the fix doesn't require a new barcode format or a server-side overhaul. The cryptographic tools — EdDSA, CBOR, ZLIB — already exist. The question was whether they could fit inside a QR code's tight capacity. The proof-of-concept says yes.

For a regular person, this means a future where scanning a parking meter QR code could cryptographically prove the code was placed by the city, not by a scammer with a label printer. The verification would happen in the scanning app — silently, in milliseconds, before the browser even opens.

What it means for business

For operators who deploy QR codes at scale — parking authorities, event organisers, restaurant chains, ticketing platforms — the implications are concrete:

  • Parking operators and councils: The quishing scenario the authors highlight is already a real problem. A signed QR code on a parking machine would let a compliant app flag a swapped code before the driver enters payment details. The offline model is sufficient for a single machine; the hybrid model handles fleet-wide key rotation.
  • Small businesses using QR menus: A cafe with a table QR code linking to a menu is a lower-value target, but a signed code would prevent a prankster or competitor from redirecting customers to a fake page. The offline proof-of-concept could be implemented without any server infrastructure.
  • Ticketing and event platforms: A signed QR code on a paper ticket could be verified offline at the gate, proving authenticity without a network connection — useful at festivals or remote venues with poor signal.
  • Compliance and security teams: The hybrid model's Central Trust Registry introduces a new piece of infrastructure to manage. Key rotation, revocation procedures, and registry uptime become operational concerns. This is the cost of real-time validation.

The trade-off is adoption. Standard native camera apps can scan the hybrid QR code and open the URL, but they can't verify the signature [S1]. Cryptographic verification requires a compliant application — meaning the security benefit only materialises once scanning apps, or dedicated verification apps, are widely deployed.

What we don't know yet

This is a preprint, not a peer-reviewed paper [S1]. Several critical questions remain open:

  • No quantitative metrics: The abstract provides no QR capacity overhead figures, no latency benchmarks, no scan reliability data. We don't know how much larger a signed QR code is than an unsigned one, or whether it remains scannable on older phone cameras at typical printing sizes.
  • No independent implementation: The proof-of-concept hasn't been independently audited or replicated. No third-party security review is cited.
  • No deployment data: The system has not been tested in live production environments. The smart-city IoT scalability claims are architectural proposals, not measured results.
  • Adoption path unclear: The hybrid model's backward compatibility is elegant, but the security benefit only activates when users have compliant scanning apps. Who builds those apps, who maintains the Central Trust Registry, and how adoption is incentivised remain unanswered.
  • Key revocation latency: The hybrid model addresses the offline model's revocation gap, but the authors don't specify how quickly revocation propagates through the registry in practice.

The next concrete signal to watch: peer review and any follow-up paper with quantitative performance data. Until then, this is a promising architecture, not a shipping product.

If this is the kind of story that makes you feel smarter before your coffee gets cold, subscribe — there's more every week.

Sources

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.