Re: [Cbor] Use and development of draft-faltstrom-base45 (was: Re: CBOR in QRcodes)

Christian Amsüss <christian@amsuess.com> Fri, 25 June 2021 16:08 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C293A07AB for <cbor@ietfa.amsl.com>; Fri, 25 Jun 2021 09:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fnmUJMpJlId for <cbor@ietfa.amsl.com>; Fri, 25 Jun 2021 09:08:37 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140F33A07A2 for <cbor@ietf.org>; Fri, 25 Jun 2021 09:08:37 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 543644001D; Fri, 25 Jun 2021 18:08:34 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 86E51D7; Fri, 25 Jun 2021 18:08:33 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:90c8:39c3:8a99:101f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 472A87D; Fri, 25 Jun 2021 18:08:33 +0200 (CEST)
Received: (nullmailer pid 1401755 invoked by uid 1000); Fri, 25 Jun 2021 16:08:32 -0000
Date: Fri, 25 Jun 2021 18:08:32 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Doug Ewell <doug@ewellic.org>, cbor@ietf.org
Message-ID: <YNX/gD4ScCFnDmWW@hephaistos.amsuess.com>
References: <9704.1624378576@localhost> <YNN05Efh4/8Xyt63@hephaistos.amsuess.com> <000201d76914$53aa4890$fafed9b0$@ewellic.org> <YNWdchJRQRzm3I9j@hephaistos.amsuess.com> <25746.1624636305@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="L9kdnzZwE0IfNThN"
Content-Disposition: inline
In-Reply-To: <25746.1624636305@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/yz0M5rQ0tGrBLBI_TizEkqt46Ao>
Subject: Re: [Cbor] Use and development of draft-faltstrom-base45 (was: Re: CBOR in QRcodes)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2021 16:08:39 -0000

On Fri, Jun 25, 2021 at 11:51:45AM -0400, Michael Richardson wrote:
> I don't have enough caffeine in me to figure out how much more efficient
> base45 is over base32.  I think it's log(45)/log(32), right?

The efficiency of base45 on its own is pretty irrelevant, because it's
something that'd be only used inside an environment where these 45
characters are encoded in 5.5 bits of the QR code.

base45 does a 2-to-3 encoding, so one 8 bit of binary data gets spread
to 24/2=12 bit of ASCII base45 string, but those 1.5 characters are
encoded in 1.5*5.5 = 8.25 bit, so in the end it's a 3% loss.

(Same would be the case for 2-to-3 encodings possible with
base41,..base44).

> In places where base64 or base85 won't work, it seems to me that base32 is
> probably safer than base45.   As I wrote, I think that the limitation for
> QRcode entry has to do with forms on web pages or 3270 terminals, where the
> scanner is a bump-in-the-cord on the keyboard interface.  Whether it's a
> PS2/PS2 or a second USB input.

The RFC4648 base32 alphabet does work, but it's a 5-to-8 encoding, so
it'd give 1.6*6.6 bytes payload binary per byte QR-internal binary, so
it's 10% instead of 3% overhead.

Whether that really matters all that much is, as far as generic
recommendations for QR codes go, probably up for debate. (Even in the
health certificate use case there was discussion that if border
conditions were different, base32 would have been a good choice).

> I'm surprised that base45 includes space, + and / :-)

And the percent character; that's part of the trouble (but then again, 4
can be removed without loss of efficiency).

BR
Christian

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn