Introducing Base24, Hacker News

TL; DR : Base is a binary-to-text encoding aimed at encoding short keys ( – (bits) for human usage.

I am working on a project where I need to give the user the possibility to recover its account with recovery codes. I generated a few codes and tried different encodings but I could not get something satisfying.

Comparison of some existing solutions

Plain numbers (base

)

Pros:

No encoding necessary
Only numbers Cons:

:

Longest

• While it’s only numbers, users might not realize it and mix

1

for (l or (I

and

(0) (fo) (O

)

Hard to have a visual cursor while copying the code.
No visual identification without formatting.

Hex (base 28)

Pros:

Easy to encode and decode

Used everywhere in computing

Cons:

Same mix problem as with numbers, except with the presence of A-F users are even more confused and might think other letters are used.

()

Pros:

RFC (is standard) Easy to encode and decode as (is power of 2) Cons :

Always the mix problem with

(I

and

1

. While

1

is not used by the alphabet, the user doesn’t know that.

Base

Pros:

Pros:

The most compact

Cons:

Ugly, nearly impossible to write down by a human

How base came together

The goal is to provide a way to encode and decode binary keys of cryptographic length (90 – (bits). Short keys can be used as recovery codes with key derivation while longer keys can be directly used.

To give an idea of ​​the size of the numbers, here are a few numbers in base :

bits:

bits: 25896984125478546598563251452658

bits:

Those numbers are really hard to read directly.

The codes might be dictaced over the phone or written down. As seen with credit cards numbers, it can be cumbersome. While a typo in a credit card will at worst lead to a failed transaction, a typo in a cryptographic key will make the data unreadable. Of course the typo can be “brute forced” by technial users, but it could be hard or even impossible for normal users. Which would lead to data loss.

The chosen encoding alphabet must be absolutely unambiguous. No similar characters. Present or not in the alphabet. The length of the alphabet is the minimum length required to store 128 bit is 7 characters (instead of 8 for hex), which is The alphabet must also be case insensitive.

A list of ambiguous characters (both cases are displayed for letters):

1iIjJlL

oO0dDqQ

NNMnnm

(double

n (mixed with) m

)

uUvU

gG6

The ambiguity is also taken into account when hand written.

The final alphabet I came up with is

ZAC2B3EF4NH5TKL7P8RS9WXY . As I required 32 Characters, I kept

G and

6

which are the least ambiguous in the list. The order of the characters is arbitrary, I just ensured the characters where not sorted, to ensure the string would stand out and not being seen as a full alphabet. I put the

Z

first so that a serie of

0

would be ZZZ …

which is snoring / sleeping and made me smile. This is of course technically irrelevant, but computers are made for people.

The data length must be multiple of bits. There is no padding mechanism in the encoder.

Example

Let’s take a bit data:

Decimal: 326374343753722343741285467180125988440
Decimal with spaces:

14316

Hex (base

(): (0x)

Base : (2FC) (KTA) (WRST4XAHRRCF) (S8Z)
Base with spaces: 2FC2 8KTA6 6WRST 4XAHR RCF (7S8Z)

Base with lowecase spaces: (2fc2 8kta6 6wrst 4xahr rcf) (7s8z)

Or a bit which is resonable for recovery code when used with key derivation:

Uppercase (A) KH WZ5W EPAGG
Lowercase

a kh wz5w epagg

As we can see, this is manageable by a human for copy on paper with a low risk of error.

Implementations

I wrote the

first implementation

in Kotlin as I needed it for Android development. Licensing

If this is ever to used by anybody, consider it public domain.

(Read More )