Base58 encoding would yield shorter and more robust share strings
wizkr opened this issue ยท 3 comments
Presently, each share is printed as hexadecimal coded ASCII, which yields longer than necessary strings. Since shares are often copied by hand, it would make sense to use an encoding scheme which yielded shorter strings. This would be easier to copy down, and less prone to human error/typos. Several better encoding schemes exist: base64, base58, base58check, ...
My vote would be base58, since it has removed ambiguous characters, to further aid human reading/writing. Base58check could be an additional option, for added robustness.
Here is an example of how the output looks today:
$ echo "My super important password." | ./ssss-split -t 3 -n 5
Generating shares using a (3,5) scheme with dynamic security level.
Enter the secret, at most 128 ASCII characters:
Using a 224 bit security level.
1-df89a2cc946bdd34a145e43e23049a2f3a2627549ab236c99597c2c7
2-8b2d44ece8c8999825beeff8aa2391b252e64d58a4d9af3203d434a0
3-6ff86a54b5c344b5af4f463e3907a06782650df6de5488de775f32a1
4-bcd14ae6e4cdbc735806cfcc750bb8e7ff359d44ae01aa360bf6d9e4
5-5804645eb9c6615ed2f7660ae62f89322fb6ddead48c8dda7f7ddff7
Here is what it would look like with base58 encoding:
$ echo "My super important password." | ./ssss-split -t 3 -n 5
Generating shares using a (3,5) scheme with dynamic security level.
Enter the secret, at most 128 ASCII characters:
Using a 224 bit security level.
1-2ts4hvvvbmS133TPpSvXqrEU8zogRkivqVuMR9J
2-2yuyxmRuJvJuvQnWNTaWVgw3ZP9taTupsNeCAXC
3-hUH51Uk7VBgyTRbY1ruNfCmuyBGJM4iR8Ccsh5
4-awYHzhnewrnPjZx4PSheMizN7yJWrhRxJD1VeT
5-2vu8DhkfH9REFJ1m5WfwVEE5BSyXKFhcdAaMLJc
Notice the base58 codes are much shorter and easier to copy. The base58 strings are approximately 33% shorter in length.
This could/should be made the default encoding scheme, but an option can be added for the legacy encoding scheme, for backwards compatibility.
Of course all of this is just my opinion, but I think there is a strong argument for base58 being more robust, and robustness is a key design goal of this tool.
I am happy to take on this work and submit a patch, if the concept is approved.
I'm hesitant to incorporate something that feels like a significant change, as I'm not really qualified to maintain/own a project like this. I kinda want to limit this repo to just being "simplify the build/install process for people who aren't the original maintainer." If you want to fork the repo and incorporate such a change, I'm happy to add a link in the README here suggesting it to interested parties.
Makes sense ๐