Re: base26 Encoder/Decoder

Herbert Kleebauer wrote:

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.
 

Thanks for your reply, much appreciated!

Well, the reason why I like this base26 implementation is I can use it
for the Diana Cryptosystem or the Dein Star straddling checkerboard,
when using foreign languages or transmitting small binary blobs.

The second reason, I can use this also for typing in small encrypted messages
more easily, when using Format Preserving Encryption (FPE), in an old feature
phone, for sending text messages (SMS), when grouping the string as five letter
groups, to avoid typos.

Example:

$ echo -n 'Hello sci.crypt! :-)' | base16
48656c6c6f207363692e637279707421203a2d29

$ echo -n 'Hello sci.crypt! :-)' | base32
JBSWY3DPEBZWG2JOMNZHS4DUEEQDULJJ

$ echo -n 'Hello sci.crypt! :-)' | cbase32
91JPRV3F41SP6T9ECDS7JW3M44G3MB99

$ echo -n 'Hello sci.crypt! :-)' | base26 | ug -g
GNUKB WRRLQ QCISN UJYEH SKYLR PJHKG YPTEA

Hope this makes sense!

--
Regards
Stefan