Re: base26 Encoder/Decoder

On 28.04.2024 13:32, Stefan Claas wrote:

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

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

I still don't understand it. In this example you have
a 20 byte String: Hello sci.crypt! :-)
The base16 (hex) conversion is trivial: you take a
single byte of the input string and replace it by
2 hex characters. No padding necessary, because the
chunk length is 1 byte and so the string length is
always a multiple of the chunk length.
But how does your base26 coding work. Take you four bytes
of the input string and then convert this 32 bit number
to base26 resulting in a 7 digit base26 number? There
are 5 of this 4 byte chunks which gives a total of 35
base26 digits. But how do you handle padding if the
input string length is not a multiple of 4?
Or do you treat the complete string as a single number
0x48656c6c6f207363692e637279707421203a2d29 and convert
this 160 bit number to a single base26 number? This would
also result in a 35 digit base26 number, but would
require long number arithmetic and consume a lot of
computing power (suppose the input string is 1 MByte or
even 1 GByte). In this case you don't have a problem
with padding but with leading zeroes.
But I still don't understand the advantage over base16.
If you only can use A-Z as transferable digits, you can
use an alternative to the standard hex encoding:
  0  A  or Q
  1  B  or R
  2  C  or S
  3  D  or T
  4  E  or U
  5  F  or V
  6  G  or W
  7  H  or X
  8  I  or Y
  9  J  or Z
10  K
11  L
12  M
13  N
14  O
15  P
Because there are two ways to encode 0-9, you
can use this to send a second data stream. If
A-J is used a 0 bit transferred and if Q-Z is used
a 1 bit is transferred on this second channel. You
can use this for example for a check sum or an
error correcting code.