Comment by smsm42 | Hacker News Reader

Comment by smsm42 | Hacker News Reader

Parent Full thread

I'm not sure I like that much that there's a fixed table purporting to contain IDs for all hashes ever used in the universe. It sound both inflexible - each time somebody uses a new parameter or new hash modification, it has to be updated, and hard to use - you have to drag this table around in all code that uses the protocol and remember to update it all the time. And all seems in service of saving a couple of bytes - maybe there would be better to have more verbose, but more flexible scheme, that allows to relatively easily add and identify hashes and read them by many tools?

I have same reservations about variable-int thing - it would sometimes save 2-3 bytes, but makes processing with simple tools much harder as many tools make it easy to cleave arbitrary strings into fixes pieces without knowing string's specific content, but variable-length fields make it significantly harder. Is the gain really worth the complications?

I've seen the FAQ but I guess I am not sure I agree with the authors on the question that what they did is actually the best...

you have to drag this table around in all code that uses the protocol and remember to update it all the time

Won't some kind of table always be necessary unless the type contains actual bytecode implementing the hash algorithm?

For a few extra bytes you could have the ASCII name of the hash function. "sha256" is pretty clear, for example.

And then your code would still need a table mapping the string to the implementation.

Yes, but that's just one table - for implementations that are supported by code. I don't need the table to just understand what this hash is - only to verify it. And, if I want to add my private hash, I don't need to update shared tables and be worried some other hash would have the same ID as mine. I can just use reasonably unique string.

It still needs a table, but it doesn't need consensus on what those names mean.

If someone says "sha2", that doesn't mean bcrypt, after all!

But at least you could work out the mapping in your head, without having to refer to a numeric table.

yep, exactly :)

A mapping table from identifiers to hash implementations already exists in the RFCs and code for pgp and TLS.

And variable length ints are already a thing, also in crypto, in the form of bignums.

Oh, variable ints are surely a thing. You don't even have to go as far as crypto - if you're using UTF-8, you are using the same idea. Which also reveals its downsides once you need to parse utf-8 strings into parts and do operations like wrapping or splitting. That's why I wonder if they are really needed there. I mean, the space optimization is obvious, but I suspect it might be premature, unless you are storing really billions or trillions of hashes and need to squeeze out every single kilobyte out of it.

I'm right there with you on this. We were typing our comments at the same time, I think: https://news.ycombinator.com/item?id=13740113

Reply on news.ycombinator.com