Hacker News Reader

Comment by nine_k | Hacker News Reader

I suppose that color-based codes have more density per "pixel" (2-3 bits), so they can be used to encode relatively large amounts of information. Try encoding 1kb as a QR code; it will become pretty unwieldy, if it's possible at all. Think about the size of a reasonable cryptographic public key; would it be nice to have it optically readable sometimes?

Tagging things during manufacture is a different application area, with different constraints and requirements. Bar codes are not gone because QR codes are here, QR codes won't be gone because color codes appear.

View on HN

A B/W randomart image which uses alphanumeric and special characters, like the one used in ssh-keygen itself when generating keys, would be enough. With current tech, Adding colors is just a recipe for disaster in environments which need maximum reliability.

Personally, I think QR codes are just fine for manufacturing but as for encodings meant for end-users, I think we should be focusing on making them more human-readable or at least visually comparable, without sacrificing bit-depth.

Still, this tech was really neat to play around with and I hope something good comes out of all the work put into it.

Some kind of symmetry would already really enhance how nice QR codes look to people.

> 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.

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.

> Think about the size of a reasonable cryptographic public key; would it be nice to have it optically readable sometimes?

An ECDSA key would be 256 bits or 32 bytes long. At low error correction, it can fit into QR Code version 2 (21×21 modules). Or if you're thinking of RSA, then a 2048-bit key would fit in version 10 (57×57).

Reply on news.ycombinator.com