Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Base-122 – A space efficient alternative to base-64

blog.kevinalbs.com

Post reply on HN
Print view View original

21–30 of 71 posts

Re: Base-122 – A space efficient alternative to base-64

#21

Post by takeda »

dleslie wrote: post #20
bunderbunder wrote: post #18

Earlier quoted context omitted.

When would you gzip encoded data instead of encoding gzipped data? Doesn't gzip after encoding defeat the whole idea of encoding the data in a format that won't get mangled by systems that expect to be handling text?

When serving gzip-compressed pages to browsers that support it.

He meant that you typically use base64 when the medium you use (e.g. email) doesn't support binary data. When you compress base64 encoded data you get back binary output. If binary output is ok to transfer, then why would you use base64 in the first place? Why not just compress the raw data?

Re: Base-122 – A space efficient alternative to base-64

#22

Post by Drdrdrq »

zrm wrote: post #15
krschultz wrote: post #12

Earlier quoted context omitted.

I would be interested to learn more about those concerns. My "default" setup these days is HTTPS & gzip everything, but I can't say I've read any white papers on the security implications of that.

If the attacker knows or controls any part of the data then the compressed size leaks information about the unknown data because the compressed size will be smaller if the known data shares bytes with the unknown data.

Thanks for the explanation! Attack: https://en.m.wikipedia.org/wiki/BREACH_(security_exploit)

Re: Base-122 – A space efficient alternative to base-64

#23

Post by detaro »

takeda wrote: post #21
dleslie wrote: post #20

Earlier quoted context omitted.

When serving gzip-compressed pages to browsers that support it.

He meant that you typically use base64 when the medium you use (e.g. email) doesn't support binary data. When you compress base64 encoded data you get back binary output. If binary output is ok to transfer, then why would you use base64 in the first place? Why not just compress the raw data?

If your embedding encoded data in another file format which forces restrictions on it. The encoding in the article is very explicitly optimized to be embedded in HTML attributes, which have a limited character range. The full HTML document is later compressed for transport, over a protocol that a) is aware of the compression and b) can transport binary data.

Re: Base-122 – A space efficient alternative to base-64

#24

Post by Dylan16807 »

faragon wrote: post #16

Base85 is between base64 and base122, while using printable characters. Any statistics of compressed base85?

I don't have an easy way to try a test corpus but I fed this comment page into it.

  Raw size:     37409
  gzip(raw):    6170
  gzip(base16): 7482
  gzip(base64): 10675
  gzip(base85): 10549
So it works better than base64, and it has the advantage of working 4 bytes at a time rather than 3.

Also note that when you're feeding in binary data the gzip sizes for raw and base-xx data get a lot closer together.

Re: Base-122 – A space efficient alternative to base-64

#25

Post by [deleted] »

takeda wrote: post #21
dleslie wrote: post #20

Earlier quoted context omitted.

When serving gzip-compressed pages to browsers that support it.

He meant that you typically use base64 when the medium you use (e.g. email) doesn't support binary data. When you compress base64 encoded data you get back binary output. If binary output is ok to transfer, then why would you use base64 in the first place? Why not just compress the raw data?

[deleted]

Re: Base-122 – A space efficient alternative to base-64

#27

Post by xg15 »

It's an interesting technical exercise, but I don't think this is the right approach for optimizing HTML load times.

If the goal is to reduce latency for small images, wouldn't it make it more sense to extend data URIs so the same base64 string can be referenced in multiple places?

Actually, as HTTP2 can effectively return multiple resurces in the answer of one request, do we still need embedded images for latency reduction at all?

Re: Base-122 – A space efficient alternative to base-64

#28

Post by kobeya »

CiPHPerCoder wrote: post #4

My 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'm pretty sure that Bitcoin has dealt with this issue for its base58 encoding. It might be worth checking if their algorithm is generalizable to other radix sizes.

Re: Base-122 – A space efficient alternative to base-64

#29

Post by paulddraper »

xg15 wrote: post #27

It's an interesting technical exercise, but I don't think this is the right approach for optimizing HTML load times. If the goal is to reduce latency for small images, wouldn't it make it more sense to extend data URIs so the same base64 string can be referenced in multiple places? Actually, as HTTP2 can effectively return multiple resurces in the answer of one request, do we still need embedded images for latency re…

Compression takes care of exactly this.

Re: Base-122 – A space efficient alternative to base-64

#30

Post by wildfire »

Something that is isn't really discussed is that the need for base64 arose so that binary data could transit 7-bit email systems.

Base122 does not have that property - as far as I could tell.

Whilst we are all, basically, living in an 8-bit world; I suspect it will be sometime before people feel comfortable assuming that an 8-bit transport is viable over email.

[edit: spelling ]

Post reply on HN