Naming Things with Hashes(tools.ietf.org)
tools.ietf.org
Naming Things with Hashes
http://tools.ietf.org/html/draft-farrell-decade-ni
7 comments
PGP had a nice wordlist for verifying key fingprints:
http://en.wikipedia.org/wiki/PGP_word_list
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:
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).
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
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).
[deleted]
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:
Also: "nih" sounds like a pun :-)
This would still be a valid URI without the unnecessary characters and without the confusion:
ni:sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
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... )
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
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
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.
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#...
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
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.
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'.
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'.
[deleted]
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."
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."
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.