Hacker News Reader

Comment by Dylan16807 | Hacker News Reader

> Try encoding 1kb as a QR code; it will become pretty unwieldy, if it's possible at all.

So for reference, QR codes are specified up to 177 pixels wide, and at that size they can hold around 2KB with medium error correction.

But for practical use you probably want half that width, so a 400 byte payload is fine but not much more.

View on HN

Printing a 400 byte payload is pretty easy, but printing a 400 byte payload that's readable at high-speed(100 scans per second) is quite a different story. You'll find that in many usage scenarios the practical upper limit for a data payload is determined less by the symbology and more by the speed and reliability at which the symbology can be read by the equipment. Many thermal printers can do 200dpi or better which would allow you to print a QR code at maximum capacity into an area a little less than an inch, but you'll be hard-pressed to find a device which can scan those barcodes at a reasonable decoding speed and reliability.

You're much better off using the QR code to encode a unique key which points to a record of the desired size in some database in a networked system.

Edit: this is actually a discussion I've had in a professional context pretty recently.

> encode a unique key which points to a record of the desired size in some database

I'm sure you understand why this is not going to work the same way as reading the actual public key. Not only it needs a network, but it also is susceptible to stealing the values from the database by just generating the (short) unique keys.

I just made a short (2048 bit) key pair, and made the public key into a QR Code (as ascii armoured text, so it could have been more dense in straight binary)

https://flic.kr/p/2cYCwfG

I could only get it into a 141x141 by dropping error correction right down to 7%, but under ideal conditions (from my monitor to an iPhone) it reads reliably, as shown. I tried a 4096 bit key, but I couldn't (as text) get it into even a 171x171 QR Code at minimum error correction without truncating (and even in ideal conditions, my phone won't reliably read 171x171 resolution QR codes...)

RSA keys are significantly larger than elliptic curve keys, so for something like putting a pubkey in a QR code, you're much better off going with a 256 bit elliptic curve key than any other hacks to try shave bytes off encoding RSA keys.

Some friends and I experimented with this when running a CTF a few years back. We figured out that setting some of the Chinese Remainder Theorem values in the private key to zero, we could stuff it into a QR code and read it when printed using a receipt printer.

> it also is susceptible to stealing the values from the database by just generating the (short) unique keys

Even a very small QR code fits enough bits to prevent that.

> it needs a network

It depends on what the key is for. For many purposes a hash of the public key is sufficient.

I'm not talking about cryptographic keys, I'm talking about unique keys. Like a UUID or a serial number.

A barcode is not often used as the sole storage medium in an application. Typically it's used in conjunction with a piece of software that can connect to a database. In a manufacturing setting this could be a piece of shop floor control software. In that setting the barcode doesn't encode any information that could change in the database. It is instead used to encode a machine-readable identifier for the material that it is labeling.

Reply on news.ycombinator.com