Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Herbert Kleebauer <klee@unibwm.de>
Newsgroups: sci.crypt
Subject: Re: base26 Encoder/Decoder
Date: Sun, 28 Apr 2024 12:50:21 +0200
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <v0l9lf$10knh$1@dont-email.me>
References: <uoekm1$3rhsc$1@i2pn2.org> <g74JN.751237$mUo.609280@fx08.ams4>
 <v0dtc5$276id$1@i2pn2.org> <v0dup1$276id$2@i2pn2.org>
 <7P6XN.610386$oD2.194358@fx11.ams4> <v0j5oi$2ddq4$1@i2pn2.org>
 <oknXN.41708$XrN3.19814@fx01.ams4> <v0l0e2$2ff66$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 28 Apr 2024 12:50:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="869158275ee9a96dce983a1ad2f127e4";
	logging-data="1069809"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188x716jktVPx+27KyNdHq4gHnxbTOIulU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:T7qGkDMD5/wRn4Yxnsy2ERx0aYM=
In-Reply-To: <v0l0e2$2ff66$1@i2pn2.org>
Content-Language: de-DE, en-US
Bytes: 2291

On 28.04.2024 10:12, Stefan Claas wrote:

> So, in the end people are free to choose which base26 approach they like to use,
> because there is no standard, like an RFC, available.

But base26 doesn't make much sense. How big are the chunks of the
data input stream you encode in base26? If you encode each byte,
you need 2 digits for the byte, which is the same as base16 (hex format).
The same is true for 2 and 3 byte chunks (4 and 6 digits). Starting
with 4 byte chunks you can save one digit (7 instead of 8 for hex).
The next step is at 7 byte chunks (12 instead of 14 digits for hex).
But this is also the biggest size which you can handle with 64 bit
arithmetic. Starting with 11 byte chunks you can save 3 digits (19
instead of 22 for hex), but this already requires long number
arithmetic.

So, if you can't use base32 at least, better stay at base16 (hex format)
instead of base26. There is only a small advantage in size, but a big
disadvantage in computing time and you have to cope with padding if the
message length is not a multiple of the chunk length.