google-code-export / camlistore

Automatically exported from code.google.com/p/camlistore
Apache License 2.0
0 stars 0 forks source link

Support SHA-3, base64 blobrefs #537

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Camlistore 0.9 should support something besides just SHA-1, like SHA-3. Should 
probably then also make those use base64 blobrefs, instead of hex.

Original issue reported on code.google.com by bradfitz on 21 Oct 2014 at 11:58

GoogleCodeExporter commented 9 years ago
For base64 blobrefs, it may be useful to look at RFC 6920 "Naming Things with 
Hashes", which defines a base64 hash for content-addressable.  For example:
ni:///sha-3;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk

It uses "base64url" which uses '_' and '-' instead of '/' and '+' so that the 
base64 can be easily put in a URL, for example if using it to fetch an image 
for a blog.

http://tools.ietf.org/html/rfc6920

Original comment by jef...@gmail.com on 3 Dec 2014 at 5:03

GoogleCodeExporter commented 9 years ago
Yeah, base64url was what I was imagining we'd do.

I don't plan to use the "ni:" scheme, though. We'll stick with Camlistore's 
blobref format, though. Moving away from that would be a lot more work, for 
little gain. We can also support "ni:///" in other places where necessary.

We need to decide which blobref prefix to use ("sha3-"?) and which SHA-3 output 
size to use.

And whether we put the output size into the blobref prefix or not. We could 
infer it from the length, but then we can't tell the difference between 
truncated blobref strings, if they get truncated at an unfortunate spot.  So we 
could go with e.g. "sha3_256-" which is kinda gross. Or "sha3-" for now 
(implying whatever we pick, e.g. 256), and add "sha3_512-" later if we need a 
different one.

Thoughts?

Original comment by bradfitz on 3 Dec 2014 at 5:14

GoogleCodeExporter commented 9 years ago
If we find a cute way to be implicit all along ("sha3s-" - s for short - for 
256, "sha3l-" - l for long - for 512?) I think it'd be ok, but starting 
implicit and switching later to precising the size seems inconsistent to me.

In any case, if I wanted to bikeshedd, I think we should stick with the 
notation on wikipedia when being explicit about the size: "sha3-256-" and 
"sha3-512-".

Original comment by mathieu....@gmail.com on 3 Dec 2014 at 5:43

GoogleCodeExporter commented 9 years ago
My only concern with "sha3-256-" is that it adds a hyphen in the middle of the 
blobref type, breaking our usual convention of /^(\w+)-(.+)$/.  I'd be okay 
with "sha3_256-", but is a bit uglier and not the normal spelling.

Original comment by bradfitz on 3 Dec 2014 at 5:53

GoogleCodeExporter commented 9 years ago
There are hits if you Google for "sha3256".

Original comment by jef...@gmail.com on 5 Dec 2014 at 3:32

GoogleCodeExporter commented 9 years ago
This issue has moved to https://camlistore.org/issue/537

Original comment by bradfitz on 14 Dec 2014 at 11:37