Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is 32bit murmur3 safe to use in IPFS-based URL Shortener? #305

Closed
lidel opened this issue Nov 5, 2017 · 4 comments
Closed

Is 32bit murmur3 safe to use in IPFS-based URL Shortener? #305

lidel opened this issue Nov 5, 2017 · 4 comments
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) kind/discussion Topical discussion; usually not changes to codebase

Comments

@lidel
Copy link
Member

lidel commented Nov 5, 2017

I've just released 2.0.15beta4 with a small experiment: URL Shortener.
It is located under right-click context-menu.

When executed against a page or an image, it creates a small static HTML page that when opened, redirects user to original, long URL. The redirect page is published to IPFS and a shareable public URL is copied to user's clipboard.

Would appreciate some feedback.

Default CIDs are bit long, so this experiment uses a non-cryptographic hash function suitable for general hash-based lookup: murmur3 (32bit version is supported by go-ipfs thanks to @tabrath).

Examples:

Question:

  • Is it safe to use murmur3 for URL Shortener?
@lidel lidel added kind/discussion Topical discussion; usually not changes to codebase help wanted Seeking public contribution on this issue labels Nov 5, 2017
@ghost
Copy link

ghost commented Nov 5, 2017

I don't know man, I feel like this really shouldn't live in the /ipfs namespace, since it removes the most important property of things within /ipfs: being able to cryptographically verify the contents.

Default CIDs are bit long, so this experiment uses a non-cryptographic hash function suitable for general hash-based lookup: murmur3 (32bit version is supported by go-ipfs thanks to @tabrath).

Wow, I hadn't noticed -- this is not good, for the reason above. We shouldn't allow non-cryptographic hashes in /ipfs or /ipns.

@lidel
Copy link
Member Author

lidel commented Nov 5, 2017

Yeah.. a lot of things here smell weird.

Been using "URL Shortener" a bit today and I am worried about the confusion between option to "get short url" and "upload to IPFS". In both cases user ends up with IPFS path, one is "native", one might redirect to "non-distributed internet".

I'll sleep on it, but I think this should be removed from browser extension.
Instead, a distributed web-app could serve the same purpose under own namespace.

@lidel lidel added the kind/bug A bug in existing code (including security flaws) label Nov 5, 2017
@Kubuxu
Copy link
Member

Kubuxu commented Nov 6, 2017

@lidel please don't publish this feature, insecure hashes will be blocked in future breaking this completely.

lidel added a commit that referenced this issue Nov 6, 2017
As noted in #305 this introduces confusing UX
and additionally short hashes produced by murmur3
are non-cryptographic and support for it in CIDs
will be removed / blocked in near future
@lidel
Copy link
Member Author

lidel commented Nov 6, 2017

The experiment is already removed 👌 Glad it at least helped to surface problems with murmur3.

I am closing this issue. Blocking murmur3 in /ipfs/ namespace is tracked in ipfs/kubo#4371

@lidel lidel closed this as completed Nov 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) kind/discussion Topical discussion; usually not changes to codebase
Projects
None yet
Development

No branches or pull requests

2 participants