Live data from Hacker News

The Base45 Data Encoding

datatracker.ietf.org

21–30 of 50 posts

Re: The Base45 Data Encoding

#21
post #9

So instead of extending QR codes, which are inherently binary, to efficiently handle binary payloads, we invent yet another ASCII-based tunneling scheme. Why ever fix any problem when we can just pile workaround upon workaround upon workaround?

Because QR code scanners are very widespread already, can be understood by even basic cameras nowadays and some devices are hard to update or would need yet another self-invented thingy, which would make people rather more suspicious if done for something like the use case this initially had – codes for verifying that a person is tested, vaccinated or recovered OK on borders and the like.

I at least find it good that existing solutions still get optimizations, even and are enhanced, vs. just throwing everything away at the slightest issue and redo everything, the that churn just costs a lot of $€£ while never bringing out something mature, i.e., useful for the masses.

Re: The Base45 Data Encoding

#23

So, it’s using a 45-character alphabet which matches the QR code alphanumeric values table, which lets the QR code encoder switch to a more efficient mode that takes less space. I just tried rendering a QR code of the 692 characters of the introductory paragraph (with lines joined appropriately), and compared it with a QR code of the same text, uppercased and with out-of-range characters `,`, `[` and `]` changed to %…

[deleted]

Re: The Base45 Data Encoding

#24

The idea of this encoding is to store two bytes of data in three characters. To me it's not obvious why you need a base as high as 45 for that. Assuming you either want to store two bytes, or a trailing one, you have 256*256 + 256 combinations: 65792. Using three base45 characters, you can get up to 45^3=91125 combinations. It looks like base41 would have been sufficient. That way you can get rid of some of those spe…

[deleted]

Re: The Base45 Data Encoding

#25
post #19

Note that this encoding isn't of the same efficiency as QR binary mode, as it converts 3 bytes into 2 base45 characters. So it's more like 'base41 using the base45' charset. I'm still a bit sad that with this standard and the packages available now, the namespace of 'base45' is clobbered with this suboptimal implementation. It can best just be renamed to 'base41'. It's a good tradeoff for the DCC, but not for the res…

One could take 10 digits, 26 letters and 5 operands (+ - * / %) for Base41 encoding. 41 * 41 * 41 = 68921 is enough for 2 bytes (65536 combinatons).

Re: The Base45 Data Encoding

#26

A nice tidbit: this RFC has its roots in the EU Covid Certificate project. The encoding was designed to cut the size of the QR payload (which for DCC is a CBOR - binary encoded - object) :) The smaller the payload, the better and faster the scanning. Which is important for something that is designed to be used during border crossings and the like. We have a number of implementations here: https://github.com/ehn-dcc-d…

Interesting. The swiss system, which is supposedly compatible with the EU uses JSON + base64 [0].

Seems we also use RSA, and from a quick glance the EU seems to take any x509 certificate authority [1].

Does anyone know if there is a reason elliptic curves weren't been mandated, which should cause smaller signatures than RSA and thus a smaller payload?

[0] https://github.com/admin-ch/CovidCertificate-Apidoc/#respons...

[1] https://github.com/ehn-dcc-development/dgc-java/blob/main/cr...

Re: The Base45 Data Encoding

#27

The idea of this encoding is to store two bytes of data in three characters. To me it's not obvious why you need a base as high as 45 for that. Assuming you either want to store two bytes, or a trailing one, you have 256*256 + 256 combinations: 65792. Using three base45 characters, you can get up to 45^3=91125 combinations. It looks like base41 would have been sufficient. That way you can get rid of some of those spe…

+1

This would allow to avoid space, %, / and + to be more URL friendly, and so allow more usages.

Re: The Base45 Data Encoding

#28
post #25
post #19

Note that this encoding isn't of the same efficiency as QR binary mode, as it converts 3 bytes into 2 base45 characters. So it's more like 'base41 using the base45' charset. I'm still a bit sad that with this standard and the packages available now, the namespace of 'base45' is clobbered with this suboptimal implementation. It can best just be renamed to 'base41'. It's a good tradeoff for the DCC, but not for the res…

One could take 10 digits, 26 letters and 5 operands (+ - * / %) for Base41 encoding. 41 * 41 * 41 = 68921 is enough for 2 bytes (65536 combinatons).

/ and % don't play well with URLs. I would take + - * . $ instead.

Re: The Base45 Data Encoding

#29
post #9

So instead of extending QR codes, which are inherently binary, to efficiently handle binary payloads, we invent yet another ASCII-based tunneling scheme. Why ever fix any problem when we can just pile workaround upon workaround upon workaround?

Qrcode already has a binary mode. The problem is that qrcode software treats qrcode data as text and fucks up. You’re not going to get every software out there fixed. This does not extent qrcode at all, instead it defines a binary-to-text encoding designed to fit in qrcode’s existing alphanumeric mode, exactly like base32, base64 or base85 (or base36, base62, binhex, quopri) but fitting the specific constraints of th…

> You’re not going to get every software out there fixed.

You don't need every QR code software to be fixed anyway. Only the one which will use those QR codes which don't yet exist. These softwares will have to understand Base45 anyway.

If you wrote that QRcode is not extensible (I don't know if that's the case) I would have agreed.

Re: The Base45 Data Encoding

#30
post #26

A nice tidbit: this RFC has its roots in the EU Covid Certificate project. The encoding was designed to cut the size of the QR payload (which for DCC is a CBOR - binary encoded - object) :) The smaller the payload, the better and faster the scanning. Which is important for something that is designed to be used during border crossings and the like. We have a number of implementations here: https://github.com/ehn-dcc-d…

Interesting. The swiss system, which is supposedly compatible with the EU uses JSON + base64 [0]. Seems we also use RSA, and from a quick glance the EU seems to take any x509 certificate authority [1]. Does anyone know if there is a reason elliptic curves weren't been mandated, which should cause smaller signatures than RSA and thus a smaller payload? [0] https://github.com/admin-ch/CovidCertificate-Apidoc/#respons..…

base64 is just used to encode the PDF and PNG to send them over JSON (JSON does not support binary content). The data in the QR code is encoded in base45 as in the EU.
Post reply on HN