Naming Things with Hashes | Hacker News Reader

Naming Things with Hashes

tools.ietf.org

42 pointsvr000m23 comments

And if you want it to be pronounceable, why not use Oren Tirosh's Mnemonic Encoder?

About 10 years ago, Oren Tirosh published "mnemonicode", which was a selection of 1600 words which were optimized to be (i) internationally recognizable, and (ii) have distinctive pronunciation that would survive a low-quality phone medium and/or a non-native speaker.

I can only find a copy in the wayback machine now:

http://web.archive.org/web/20051109230247/http://www.tothink...

http://web.archive.org/web/20051109233255/http://www.tothink...

But if we're adding a way to "name things", I think over-the-phone naming should also be considered.

PGP had a nice wordlist for verifying key fingprints:

http://en.wikipedia.org/wiki/PGP_word_list

There is a C source code in github, https://github.com/singpolyma/mnemonicode. I haven't tested it though to see if it's working.

For human-friendly URIs, I would've liked to see Doug Crockford's Base32 encoding (http://www.crockford.com/wrmg/base32.html) instead of hexadecimal. Case-insensitive, but still more compact than hex.

Another handy trick is to drop vowels, which only costs 6 characters (with y), and greatly reduces the chance that your url will include a noticeable profanity or other undesirable word.

The problem with Base32 encodings is that there are so many of them. (I say this as a fan who promoted Base32 in a number of uses, and wish the proliferation of encodings could have been avoided.)

For example, Crockford's is different from both of the variants defined in IETF RFC 4648 (http://tools.ietf.org/html/rfc4648#section-6). For comparison, the digits sets for 0-31 are:

    RFC4648-b32: ABCDEFGHIJKLMNOPQRSTUVWXYZ234567
  RFC4648-b32he: 0123456789ABCDEFGHIJKLMNOPQRSTUV
  Crockford-b32: 0123456789ABCDEFGHJKMNPQRSTVWXYZ

There are even others. Each had locally-reasonable reasons for their variation at the time.

I used the 1st row approach, in the SHA1 identifiers at Bitzi and in the original 'magnet:' proposal, because it had also been documented in an earlier IETF RFC for other purposes, and is perhaps best for anyplace where human sight-reading/handwriting could confuse certain digits. But the 2nd-row variant is easiest for encoding/decoding, and the 2nd/3rd row variants have some sorting benefits (the encoded versions sort in the same order as the raw binary versions).

I don't understand the need for "//" in the URI. The thing that follows it is usually an authority (hostname), not a name for an algorithm.

This would still be a valid URI without the unnecessary characters and without the confusion:

    ni:sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q

See: https://www.ietf.org/rfc/rfc2396.txt

Also: "nih" sounds like a pun :-)

"Authority The optional authority component may assist applications in accessing the object named by an ni URI." They give this example:

ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

( https://tools.ietf.org/html/draft-farrell-decade-ni-10#secti... )

I'm seeing the beginnings of a replacement for HTTP based on a distributed hash table.

You may be interested in this Google Tech Talk from 2006 - http://www.youtube.com/watch?v=oCZMoY3q2uM . I found it interesting at the time it came out.

That's Van Jacobsen introducing CCNx Content Centric Networking. One way I would summarise it is as a stripped down HTTP at Layer 3. Just think about all the client devices out there that don't actually need IP addresses or the management overhead going with them. After watching this I concluded that IPv6 is an IETF solution to The Wrong Problem (more! faster!). I can't understand why Google would prioritise SPDY over this, they could make Chrome do CCNx over IP to their DCs instead.

It's an outstanding talk, I've watched it 3 times now since I found it [0] on HN a few months ago. VJ is a visionary and a gentleman.

The FISS09 workshop presentation [1] is about 3 hours, well worth it for a deeper dive. His tour of the history of how packet switching emerged in a telephony circuit dominated industry is a fascinating case study on introducing fundamental change to a legacy incumbent system, as well as the early history of data networking.

0. http://news.ycombinator.com/item?id=3847968 1. https://www.ccnx.org/wiki/CCNx/CCNxPresentations

You mean like Freenet? :)

Correct me if i'm wrong, but don't UUIDs already provide all this (except for the human-friendly aspect)? Expanding past 128 bits should probably be included in the next version.

https://en.wikipedia.org/wiki/Universally_unique_identifier https://tools.ietf.org/html/rfc4122

You're wrong. UUIDs don't provide any guarantees about the target of the reference.

ie. Given a UUID, and a service endpoint which returns some data for a given UUID, the client has no way of ensuring that the data returned from the service is in fact what they asked for. A similar service operating on hash values would have the property that clients can run the same hash algorithm locally to ensure that the server isn't lying to them.

How is that different from UUID version 3 and 5, which both use hash values?

https://en.wikipedia.org/wiki/Universally_unique_identifier#...

My apologies. You're correct: I mistakenly equated UUID with UUID v4.

That said, the difference with this new proposal appear to include at least the following:

1) Support for untruncated hashes

2) More secure hash algorithms

3) Extensibility to new hash algorithms

4) URI compatibility

Also by my reading the UUID conventions are hashes of other names to make them fit the UUID format... not hashes of specific content.

Names of a namespace, yes, but standards were meant to be broken. It doesn't really matter what you based the hash on, it's up to the application(s), much like the type of UUID you choose.

The reason I like UUID better is (once you pick a version) it's simple. It already looks pretty readable and it's a well known widely-used standard. It would have been nice if the authors of this RFC had just expanded on UUID. People are also way too URI-obsessed; when are you going to pass this hashed URI to an application? IMHO an object reference should be just that and not involve application interfaces.

In terms of the hashing algorithms, (IIRC) unless you're using HMAC you're opening yourself to an (eventual) brute force and key reuse issue, or at the very least the potential for an implementer to ignore the need for a random salt and get either easy collisions or predictable table insertion. I would feel pretty nervous if the hashing algorithm was my SPF.

But unless you rigorously enforce the hash=name convention, you can't get its benefits. (Benefits like stability and implicit verification.) And shoehorning the hash into the constrained UUID format hides/confuses the conventions you're committing to.

If you name is a hash, and really needs to be a hash, that should be evident, not squeezed into the bitfields of a 'UUID'.

What is the practical application of this? As opposed to a generic link shortener? I mean how is a 32-bit hash better than just using bit.ly/Nx7ax1?

No third party required.

Avoid things like "Dearest Receiver, please view the transfer and customs documents at scam.ly/DEADBEEF to assist in transferring 3 gold bars from my late cousin's vault."

This seems like it could lead to (among other things) a non-third party scheme for link shortening.

The limiting factor there is primarily the domain name length, rather than the specific content reference, or at least the thing least easily changeable.

Reply on news.ycombinator.com