Base-122 – A space efficient alternative to base-64
blog.kevinalbs.com
Base-122 – A space efficient alternative to base-64
1–10 of 71 posts
Re: Base-122 – A space efficient alternative to base-64
#2Interesting, but please add a license :)
Re: Base-122 – A space efficient alternative to base-64
#3tldr, no revolution, base64+gzip still far better than base122+gzip.
But the article worth reading.
Re: Base-122 – A space efficient alternative to base-64
#4My problem with base-122 is simply that it's not an even power of 2.
It's very easy to write a cache-timing-safe version of base{16,32,64} encoding for use in encoding/decoding cryptographic keys in configuration files. To wit: https://github.com/paragonie/constant_time_encoding
Base-122? Not sure if it's even possible.
Re: Base-122 – A space efficient alternative to base-64
#5A lot of people have experimented with a lot of different ways of encoding binary data as printable text. Wikipedia has a list of different encoding schemes[0].
The most efficient one is yEnc[1]. Still the simplest ones such as base64 or good old hex may actually work better once compression comes into the picture.
Re: Base-122 – A space efficient alternative to base-64
#6My problem with base-122 is simply that it's not an even power of 2. It's very easy to write a cache-timing-safe version of base{16,32,64} encoding for use in encoding/decoding cryptographic keys in configuration files. To wit: https://github.com/paragonie/constant_time_encoding Base-122? Not sure if it's even possible.
A number system can have any natural number as radix, so why not? https://en.m.wikipedia.org/wiki/Radix
From the posted article: "This leaves us with 122 legal one-byte UTF-8 characters to use"
Seems legit to me.
Re: Base-122 – A space efficient alternative to base-64
#7My problem with base-122 is simply that it's not an even power of 2. It's very easy to write a cache-timing-safe version of base{16,32,64} encoding for use in encoding/decoding cryptographic keys in configuration files. To wit: https://github.com/paragonie/constant_time_encoding Base-122? Not sure if it's even possible.
I think you are focusing on the wrong number.
Each byte of base64 produces 6 bits of data, so the boundary aligns at 32 bits. LCM(6,8) = (6•8)/2
Each byte of base122 produces 7 bits of data, so the byte boundary aligns at 56 bits. LCM(7,8) = (7•8)/1
Edit: Due to the variable length encoding, there is no guarantee of byte alignment.
Re: Base-122 – A space efficient alternative to base-64
#8The use of codepoints below 32 (space, start of what's usually considered "printable") makes me a bit hesitant. A lot of systems won't preserve those characters. Base85 is a more efficient alternative to base64, and doesn't use that lower range:
Re: Base-122 – A space efficient alternative to base-64
#9A lot of people have experimented with a lot of different ways of encoding binary data as printable text. Wikipedia has a list of different encoding schemes[0]. The most efficient one is yEnc[1]. Still the simplest ones such as base64 or good old hex may actually work better once compression comes into the picture. [0]: https://en.wikipedia.org/wiki/Binary-to-text_encoding [1]: https://en.wikipedia.org/wiki/YEnc
It's crucial to evaluate encoding space usage in the context of compression. For instance gzip(base16(data)) is often smaller than gzip(base64(data)) for practical data. Even though base64 is more efficient than base16, it breaks up data across byte boundaries which then makes gzip significantly less efficient.
Re: Base-122 – A space efficient alternative to base-64
#10tldr, no revolution, base64+gzip still far better than base122+gzip. But the article worth reading.
Aren't there security concerns using gzip and HTTPS? Could this be a space efficient alternative when gzip is disabled?